Schwachstellen in GoAhead TLS akzeptieren stillschweigend widerrufene Zertifikate und schwächen die Verschlüsselung

EmbedThis hat am 12. Oktober 2026 die Version 6.1.1 von GoAhead veröffentlicht, um kritische Sicherheitsmängel in dem weit verbreiteten eingebetteten Webserver zu beheben. Das Update korrigiert Probleme, die es widerrufenen Client-Zertifikaten ermöglichten, die Authentifizierung zu passieren, und die Verschlüsselung in bestimmten TLS-Builds schwächten. Dies betrifft potenziell Hunderte Millionen IoT-Geräte.

Was ist passiert?

Die primäre Schwachstelle, identifiziert als CVE-2026-115881 mit einer vom Anbieter eingestuften Schweregradbewertung von 9,1, betrifft GoAhead-Builds, die das OpenSSL-Backend mit aktiviertem gegenseitigem TLS (mutual TLS) verwenden. In diesen Konfigurationen lädt der Server beim Start eine Liste widerrufener Zertifikate (Certificate Revocation List), setzt diese jedoch nicht durch. Folglich werden Clients, die widerrufene Zertifikate vorlegen – etwa von gestohlenen oder ausgemusterten Geräten –, stillschweigend als gültig akzeptiert. Dieser Fehler besteht in den Versionen 3.4.5 bis 6.1.0, wenn die vom Betreiber konfigurierten Einstellungen ein Bündel vertrauenswürdiger Zertifizierungsstellen, eine Issuer-Prüfung und eine Widerrufsliste enthalten.

Der Forscher Sébastien Féry von FoxIO legte dieses Problem zusammen mit zwei weiteren TLS-bezogenen Problemen am 26. Oktober 2026 offen. Während der Fix bereits am 2. August 2026 an Gerätehersteller geliefert wurde, erfolgte die öffentliche Offenlegung erst im Oktober. EmbedThis gibt an, dass keine aktive Ausnutzung gemeldet wurde, obwohl das Timing der koordinierten Veröffentlichung darauf hindeutet, dass zum Zeitpunkt der Publikation keine bekannten Angriffe stattfanden.

Zwei zusätzliche Schwachstellen wurden im selben Release behoben. Eine betrifft Builds, die ältere LibreSSL-Versionen (3.2.x sowie 3.3.2–3.3.6) verwenden; sie ermöglicht es, dass Zertifikatsketten, die das Limit von zehn Zertifikaten überschreiten, die Validierung umgehen, wenn die Issuer-Prüfung deaktiviert ist. Die andere beeinträchtigt Mbed-TLS-Builds (Versionen 4.0.2 bis 6.1.0), bei denen ein Kodierungsfehler dazu führt, dass der Server einen Ein-Byte-Diffie-Hellman-Wert anstelle des beabsichtigten 2048-Bit-Werts sendet. Diese Schwäche ermöglicht es passiven Beobachtern, Sitzungen zu entschlüsseln, wenn der Client den fehlerhaften Schlüsselaustausch akzeptiert.

Wie funktioniert es?

Der OpenSSL-Fehler resultiert aus einem Logikfehler, bei dem die Widerrufsliste zwar in den Speicher geladen, aber während des Handshake-Prozesses nie aktiv konsultiert wird. Der Server meldet beim Start keine Fehler, was Betreibern ein falsches Sicherheitsgefühl vermittelt. Wenn ein Client ein Zertifikat vorlegt, validiert der Server dessen Signatur gegen die vertrauenswürdige Autorität, überspringt jedoch den Schritt, bei dem geprüft wird, ob die spezifische Seriennummer des Zertifikats auf der Widerrufsliste steht. Dies erlaubt jedem Zertifikat, das von einer vertrauenswürdigen Autorität signiert wurde, Zugriff zu gewähren, unabhängig von seinem Widerrufsstatus.

Das Mbed-TLS-Problem beinhaltet einen Tippfehler im Code, der Finite-Field-Diffie-Hellman-Schlüsselaustausche behandelt. Anstatt eines robusten öffentlichen Werts mit 2048 Bit sendet der Server nur ein einzelnes Byte. Mainstream-Clients wie moderne Browser, Java und Go lehnen diesen kleinen Wert ab und brechen die Verbindung ab. Eingebettete oder benutzerdefinierte Clients ohne Mindestgrößenprüfungen können ihn jedoch akzeptieren und so einen schwachen Sitzungsschlüssel etablieren, den ein Lauscher leicht berechnen kann. Diese Schwachstelle betrifft weder TLS 1.3 noch ECDHE-Sitzungen.

Wichtige Details

• CVE-2026-115881: Bewertet mit 9,1; betrifft OpenSSL-Builds 3.4.5–6.1.0 mit konfiguriertem mutual TLS und Widerrufslisten; widerrufene Zertifikate werden akzeptiert.
• CVE-2026-115884: Bewertet mit 7,4; betrifft LibreSSL 3.2.x und 3.3.2–3.3.6 Builds; ermöglicht überlange Zertifikatsketten, wenn die Issuer-Prüfung deaktiviert ist.
• Mbed-TLS-Schwachstelle: Bewertet mit 5,9; betrifft Versionen 4.0.2–6.1.0; sendet 1-Byte-Diffie-Hellman-Werte, was die Entschlüsselung von Sitzungen durch passive Beobachter ermöglicht.
• Verfügbarkeit des Fixes: GoAhead 6.1.1 löst alle Probleme; Gerätebesitzer müssen warten, bis Hersteller Firmware-Updates liefern, die diese Version enthalten.
• Zusätzlicher Fix: Version 6.1.1 patcht auch einen Login-Umgehungsvorgang, der Zugriff mit jedem Passwort ermöglicht, wenn der Benutzername bekannt ist und im Blowfish-Format gespeichert wird.
• Erkennung: FoxIO bietet Fingerprints für das Tool JA4Scan an, um GoAhead-Backends zu identifizieren, wobei dies den Build-Typ statt einer bestätigten Verwundbarkeit kennzeichnet.

Warum ist das wichtig?

Für Ingenieure, die IoT-Infrastrukturen verwalten, unterstreicht dieser Vorfall die Intransparenz der Lieferketten für eingebettete Software. GoAhead läuft auf Routern, Druckern und industriellen Steuerungen großer Anbieter wie HP, Siemens und D-Link. Da das TLS-Backend und die Einstellungen in die Firmware kompiliert sind, können Gerätebesitzer ihre Gefährdung nicht ohne tiefgehende Inspektion oder Bestätigung durch den Anbieter feststellen. Die Verzögerung zwischen der Bereitstellung des Fixes für Hersteller im August und der öffentlichen Offenlegung im Oktober verdeutlicht den langsamen Patch-Zyklus, der für eingebettete Geräte typisch ist und Systeme über längere Zeiträume verwundbar lässt.

Das stille Scheitern der Widerrufsprüfung ist besonders gefährlich für Umgebungen, die sich auf mutual TLS zur Geräteauthentifizierung verlassen. Betreiber, die Widerrufslisten explizit konfigurieren, um die Sicherheit des Geräte-Lebenszyklus zu managen, werden in die Irre geführt und glauben, ihre Kontrollen seien aktiv. Dies untergräbt das Vertrauen in zertifikatsbasierte Authentifizierungsmechanismen, die oft die primäre Verteidigungslinie für headless Geräte ohne traditionelle Benutzeroberflächen darstellen. Das Vorhandensein einer Login-Umgehung im selben Release verschärft das Risiko weiter und deutet darauf hin, dass mehrere Verteidigungsebenen gleichzeitig kompromittiert sein könnten.

Was Sie tun können

• Identifizieren Sie Geräte in Ihrer Umgebung, die GoAhead ausführen, und kontaktieren Sie die Hersteller, um zu bestätigen, ob sie Firmware basierend auf Version 6.1.1 ausgeliefert haben.
• Wenn Sie den Firmware-Erstellungsprozess kontrollieren, aktualisieren Sie sofort auf GoAhead 6.1.1 und erstellen Sie Ihre Images neu.
• Deaktivieren Sie bei Mbed-TLS-Builds Finite-Field-DHE-Suiten oder wechseln Sie als Zwischenmaßnahme zum OpenSSL-Backend, bevor Sie aktualisieren.
• Aktivieren Sie bei LibreSSL-Builds die Issuer-Prüfung mit einem vertrauenswürdigen CA-Bundle oder aktualisieren Sie nach Möglichkeit auf LibreSSL 4.x.
• Beenden Sie nach dem Upgrade alle aktiven Sitzungen, starten Sie den Server neu und rotieren Sie alle Passwörter, die im Blowfish-Format gespeichert sind.
• Verwenden Sie Tools wie JA4Scan, um GoAhead-Instanzen zu fingerprinten und zu bestimmen, welches TLS-Backend sie verwenden, um die Priorisierung der Sanierungsmaßnahmen zu unterstützen.