Folgen Ein schwerwiegender Infrastrukturvorfall mit öffentlichen Schlüsseln hat Notfall-Sicherheitsmaßnahmen in Browsern, Programmiersprachenökosystemen, Zertifikatspeichern und Softwarepaketen ausgelöst. Private Schlüssel, die mit acht Zwischenzertifikaten der eMudhra-Zertifizierungsstelle verbunden sind, wurden kompromittiert, was potenziell unbefugten Parteien ermöglicht, Zertifikate auszustellen, die für gefährdete Clients vertrauenswürdig erscheinen könnten.
Der Vorfall betrifft sechs TLS-Zwischenzertifikate, die für domainvalidierte, organisationsvalidierte und erweiterte Validierungszertifikate verwendet werden, sowie zwei Codesignatur-Zwischenzertifikate. Da ein Zwischenzertifikat einer vertrauenswürdigen Root-Zertifizierungsstelle Zertifikate ausstellen kann, stellt der Besitz seines privaten Schlüssels ein erheblich größeres Risiko dar als die Kompromittierung eines gewöhnlichen Website-Zertifikats. Ein Angreifer könnte potenziell gefälschte Zertifikate erstellen, die Vertrauen von der betroffenen Kette erben.
Das Go-Projekt reagierte, indem es CVE-2026-111943 einführte, das Fälle adressiert, in denen Go-Anwendungen weiterhin Zertifikatsketten vertrauen könnten, die die kompromittierten Zwischenzertifikate enthalten. Go 1.26.10 und 1.27.3 fügen der Bibliothek crypto/x509 eine Denyliste hinzu, die dazu führt, dass die Zertifikatsüberprüfung fehlschlägt, wenn einer der bekannten, nicht vertrauenswürdigen Zwischenschlüssel in einer Kette erscheint.
Sicherheitsteams, die nach Erkennungsgelegenheiten für CVE-2026-111943 suchen, sollten über die herkömmliche Telemetrie zur Ausnutzung von Schwachstellen hinausblicken. Bei diesem Vorfall geht es in erster Linie um Zertifikatvertrauen, daher sollten Verteidiger TLS-Zertifikatsketten, unerwartete Zertifikataussteller, Validierungsfehler bei Zertifikaten, verdächtige verschlüsselte Sitzungen und Software überwachen, die ihr eigenes Zertifikatsbündel beibehält, anstatt auf schnell aktualisierte Browser-Widerrufsmechanismen zu setzen.
Die AI-native Detection Intelligence Platform von SOC Prime ermöglicht es Sicherheitsteams, die Sichtbarkeit auf aufkommende Bedrohungen zu verbessern, indem kontinuierlich aktualisierte Erkennungsinhalte in verschiedenen SIEM-, EDR- und Data-Lake-Technologien genutzt werden. Klicken Erkundung von Erkennungen um relevante Erkennungsinhalte und Jagdlogik für aufkommende Angriffsverhalten zu erhalten.
Sicherheitsfachleute können auch Prime Architect nutzen, um aktuelle Bedrohungsinformationen und Indikatoren in Jagdanfragen und Erkennungslogik zu verwandeln, um Teams bei der Erkennung von Expositionen im Zusammenhang mit CVE-2026-111943 und der Untersuchung verdächtiger Zertifikatsaktivitäten in ihren Umgebungen zu unterstützen.
Analyse von CVE-2026-111943
Der Vorfall begann am 17. Oktober 2026, als ein Sicherheitsforscher eine kryptografische Schwäche identifizierte, die acht Zwischenzertifikate betraf, die von eMudhra unter ihrer emSign-Zertifizierungsinfrastruktur betrieben werden. Der Forscher demonstrierte den Besitz der entsprechenden privaten Schlüssel, indem er für alle acht Zertifikate gültig signierte Bestätigungen an Browser-Root-Programme und eMudhra einreichte.
Mozilla bestätigte anschließend die Kompromittierung und berichtete, was besonders wichtig ist, dass seine Ingenieure in der Lage waren, die betroffenen privaten Schlüssel unabhängig wiederherzustellen, ohne Details zur Methode des Forschers zu erhalten. Mozilla kam zu dem Schluss, dass der zugrunde liegende Schlüsselgenerierungsprozess fehlerhaft und einfach auszunutzen war.
Die betroffenen Zertifizierungsstellen umfassten:
- EM DV TLS CA – G3B
- EM DV TLS CA – G3C
- EM OV TLS CA – G3B
- EM OV TLS CA – G3C
- EM EV TLS CA – G3B
- EM EV TLS CA – G3C
- EM OV CS CA – G3B
- EM OV CS CA – G3C
Die ersten sechs sind TLS-Zwischenzertifikate, die in Zertifikatsketten, die zur Authentifizierung von Websites verwendet werden, beteiligt sein können. Die verbleibenden zwei sind Codesignatur-Zwischenzertifikate. Die G3B-Zertifikate wurden mit eMudhra BV in den Niederlanden assoziiert, während die G3C-Zertifikate mit eMudhra Inc. in den Vereinigten Staaten verbunden waren.
Die Sicherheitsimplikationen sind erheblich. Jeder, der in der Lage ist, einen Zwischen-CA-Privatschlüssel abzuleiten oder anderweitig zu erhalten, könnte potenziell Zertifikate unterhalb dieses Zwischenzertifikats ausstellen, ohne den legitimen Zertifizierungsvorgang durchlaufen zu müssen. Im TLS-Kontext könnten gefälschte Zertifikate verwendet werden, um Domänen zu imitieren, wenn ein Angreifer auch in der Lage wäre, die Verbindung eines Opfers abzufangen oder umzuleiten.
Mozilla bemerkte, dass ein solcher Angreifer potenziell Websites imitieren und Datenverkehr lesen oder ändern könnte, wenn er in der Lage ist, die Verbindung abzufangen. Dies macht das Thema besonders relevant für Szenarien wie Angreifer in der Mitte, kompromittierte Netzwerk-Infrastruktur, bösartige Proxies oder Manipulation von DNS und Routing.
Verfügbare Beweise zeigen jedoch keinen weitverbreiteten Missbrauch gefälschter TLS-Zertifikate vor der defensiven Reaktion. Laut den von The Hacker News zitierten Erkenntnissen des Chrome Root Programms war in den Certificate Transparency Logs kein TLS-Zertifikat zu sehen, das zu den sechs betroffenen Website-Zwischenzertifikaten verkettet war, bevor Chrome die Schlüssel blockiert hat. Da Chrome und andere Browser, die eine CT-Protokollierung erfordern, normalerweise ein nicht protokolliertes, öffentlich vertrauenswürdiges Zertifikat ablehnen würden, schränkte dies die Möglichkeiten für unerkannte öffentliche TLS-Missbräuche durch diese Clients erheblich ein.
Chrome erhielt den Bericht am 17. Oktober um 18:05 UTC und stellte bis 19:45 UTC eine CRLSet-Blockierung für die sechs TLS-Zwischenzertifikate bereit. Mozilla erhielt den Bericht später am Abend und verteilte bis 22:59 UTC einen OneCRL-Block an Standard-Firefox-Konfigurationen. Firefox-Nutzer, die Remote-Einstellungen erhalten, erhielten daher Schutz, ohne den Browser manuell aktualisieren oder neu starten zu müssen.
Die PoC-Situation von CVE-2026-111943 ist ungewöhnlich, da es sich nicht um eine herkömmliche Speicherbeschädigungs- oder Remote-Code-Ausführungs-Schwachstelle mit Exploit-Code handelt. Stattdessen lieferte der Forscher kryptografischen Beweis für die Kontrolle über alle acht privaten Schlüssel, und Mozilla reproduzierte unabhängig die Schlüsselwiederherstellung, wodurch effektiv nachgewiesen wurde, dass der kryptografische Fehler ausnutzbar ist.
Die CVE selbst wurde vom Go-Projekt zugeteilt. Sie beschreibt ein engeres Problem, das die Zertifikatsvalidierung in der Go-Standardbibliothek betrifft. Auf den meisten Plattformen verlässt sich Go auf Systemzertifikatspeicher. Aber Systeme, deren relevante Vertrauenseinstellungen nicht rechtzeitig aktualisiert werden, könnten weiterhin Ketten durch Zwischenzertifikate akzeptieren, die nicht mehr vertrauenswürdig sind.
Um diese Lücke zu schließen, hat das Go-Projekt eine explizite Denyliste zu crypto/x509 hinzugefügt. Die aktualisierte Verifikationslogik gibt einen Fehler zurück, wann immer eine Zertifikatskette einen der kompromittierten Zwischenzertifikatschlüssel enthält.
CVE-2026-111943 betrifft Go-Standardbibliotheksversionen vor 1.26.10 und den Go 1.27-Zweig vor Version 1.27.3. Anwendungen, die mit betroffenen Versionen gebaut wurden, müssen daher möglicherweise mit einer gepatchten Go-Version neu kompiliert werden, um den neuen Schutz zu erhalten.
Die Details zu CVE-2026-111943 sind besonders wichtig für Anwendungsbesitzer, da die browserseitige Behebung nicht automatisch jedes Programm schützt, das eine TLS-Validierung durchführt. Viele Anwendungen verwenden sprachspezifische oder eingebettete Zertifikatspeicher und nutzen möglicherweise nicht die Browser-Widerrufssysteme wie Chrome CRLSet oder Mozilla OneCRL.
The Hacker News berichtet, dass diese Unterscheidung Updates in mehreren Ökosystemen ausgelöst hat. Go fügte explizite Blockaden hinzu, Mozilla aktualisierte NSS, das Zertifikatsbündel von Python’s certifi entfernte das betroffene Root, und das Rust webpki-roots Ökosystem veröffentlichte ein Update. RustSec identifiziert separat Version 1.0.10 oder neuer als gepatcht für das betroffene web PKI Root-Paket.
Die IOCs von CVE-2026-111943 sind daher in erster Linie zertifikatsbezogen und nicht traditionelle Malware-Indikatoren wie IP-Adressen, Domänen oder Dateihashes. Organisationen sollten sich auf die acht betroffenen Zwischenzertifikate und die von Go und anderen Anbietern verwendeten Public-Key-Hashes konzentrieren, um diese Schlüssel ausdrücklich zu blockieren. Telemetriedaten zu Zertifikatsketten, die eines dieser Zwischenzertifikate enthalten, sollten als nicht vertrauenswürdig behandelt und untersucht werden.
Abschwächung von CVE-2026-111943
Die wichtigste Behebung für Go-Umgebungen ist, auf Go 1.26.10, Go 1.27.3 oder eine spätere unterstützte Version zu aktualisieren und Anwendungen, die von Go’s TLS-Zertifikatsüberprüfung abhängen, neu zu kompilieren. Einfaches Upgrade des Go-Toolchains auf einem Entwicklungsserver ändert bereits kompilierte Binärdateien nicht rückwirkend; betroffene Anwendungen müssen mit der gepatchten Standardbibliothek neu gebaut und bereitgestellt werden.
Organisationen sollten auch Anwendungen inventarisieren, die unabhängige CA-Speicher oder Zertifikatsbündel beibehalten. Browser wie Chrome und Firefox reagierten schnell über zentrale Widerrufsmechanismen, aber Befehlszeilendienstprogramme, Serveranwendungen, Container, Agenten, eingebettete Geräte und Sprach-Runtimes könnten von unterschiedlichen Zertifikatsquellen abhängen.
Firefox-Nutzer mit normalen Konfigurationen erhielten den OneCRL-Block automatisch am 17. Oktober. Mozilla veröffentlichte zusätzlich Firefox 158.0.1, Firefox ESR 115.43.1 und Firefox ESR 153.5.1, um die aktualisierte Blockliste Benutzern bereitzustellen, deren Richtlinien oder Netzwerkumgebungen die ordnungsgemäße Funktion der Remote-Einstellungen verhinderten. Mozilla veröffentlichte auch NSS 3.131.1 mit Änderungen am vertrauenswürdigen Zertifikatsatz.
Sicherheitsteams sollten:
- Go-Anwendungen aktualisieren und betroffene Binärdateien neu kompilieren.
- System-CA-Bündel und sprachspezifische Vertrauensspeicher aktualisieren.
- Sicherstellen, dass Browser- und Betriebssystemzertifikats-Widerrufsmechanismen funktionieren.
- Die acht kompromittierten Zwischenzertifikatschlüssel blockieren oder nicht vertrauen.
- Interne Anwendungen mit eingebetteten oder statisch gepackten Zertifikatspeichern identifizieren.
- TLS-Telemetrie auf Zertifikatsketten mit den betroffenen Zwischenzertifikaten untersuchen.
- Legitime Zertifikate neu ausstellen, wenn bestehende Dienste von Zertifikatsketten abhängen, die jetzt nicht mehr vertraut werden.
- Kritische Dienste nach Root-Store-Updates testen, da das Entfernen eines CA-Roots auch legale Dienste unterbrechen kann, die zuvor darauf verketteten.
Teams sollten auch besonderes Augenmerk auf langlebige Software-Appliances, Container, interne Entwickler-Tools und nicht unterstützte Software legen. Diese Systeme könnten alten Zertifikatsbündeln weiterhin vertrauen, lange nachdem Mainstream-Browser eine kompromittierte CA blockiert haben.
Das Entfernen eines Root-Zertifikats kann betriebliche Konsequenzen haben. Legitime Zertifikate, die durch dieses Root verkettet sind, können auch aufhören, validiert zu werden, selbst wenn diese einzelnen Zertifikate nie kompromittiert wurden. Aus diesem Grund sollten Organisationen schnelles Missvertrauen mit Abhängigkeitsanalyse und Zertifikatsersatz verbinden, anstatt anzunehmen, dass die Entfernung des Vertrauensspeichers keine Verfügbarkeitsauswirkungen hat.
SOC-Teams können ihre Abwehrhaltung stärken, indem sie Zertifikatsvalidierungsfehler, TLS-Abfangtelemetrie, ungewöhnliche DNS-Aktivitäten, unerwartetes Proxyverhalten und Änderungen der Zertifikataussteller korrelieren. Ein Angreifer würde im Allgemeinen einen Mechanismus benötigen, um Datenverkehr umzuleiten oder abzufangen, bevor ein gefälschtes TLS-Zertifikat nützlich wird, daher sollten Zertifikatsanomalien zusammen mit Netzwerkebenen-Beweisen untersucht werden.
FAQ
Was ist CVE-2026-111943 und wie funktioniert es?
CVE-2026-111943 ist ein Sicherheitsproblem, das vom Go-Projekt im crypto/x509-Zertifikatsüberprüfungspaket verfolgt wird, nachdem acht private Schlüssel der eMudhra-Zwischen-CA kompromittiert wurden. Die kompromittierten Schlüssel könnten potenziell verwendet werden, um Zertifikate zu erstellen, die durch betroffene Zwischenzertifikate verkettet sind. Go-Anwendungen, die auf Zertifikatspeicher angewiesen sind, die diese Zwischenzertifikate noch nicht entfernt oder widerrufen haben, könnten solche Ketten weiterhin akzeptieren. Go adressierte das Risiko, indem es eine explizite Denyliste hinzufügte, die dazu führt, dass die Zertifikatsverifikation fehlschlägt, wann immer einer der bekannten kompromittierten Zwischenzertifikatschlüssel angetroffen wird.
Wann wurde CVE-2026-111943 erstmals entdeckt?
Die zugrunde liegende Kompromittierung des eMudhra-Schlüssels wurde am 17. Oktober 2026 identifiziert. Laut Mozillas Vorfallzeitachse entdeckte der Forscher Wayne den kryptografischen Bruch an diesem Nachmittag und meldete das Problem zusammen mit dem Beweis der Kontrolle über private Schlüssel an die Browser-Root-Programme und eMudhra. Chrome und Mozilla überprüften die Ergebnisse innerhalb von Stunden und begannen mit der Blockierung der betroffenen Zwischenzertifikate. CVE-2026-111943 wurde anschließend vom Go-Projekt als Teil seiner Reaktion auf das verbleibende Zertifikatsvertrauensrisiko veröffentlicht.
Welche Auswirkungen hat CVE-2026-111943 auf Systeme?
Das Hauptproblem besteht darin, dass Zertifikatsketten, die kompromittierte Zwischen-CA-Schlüssel beinhalten, fälschlicherweise vertraut werden. Für TLS könnte der Besitz eines private Schlüssels einer Zwischen-CA potenziell die Ausstellung gefälschter Zertifikate für Websites ermöglichen, die ein Angreifer nicht kontrolliert. Wenn der Angreifer in der Lage ist, Netzwerkverkehr abzufangen oder umzuleiten und die Software des Opfers die betroffene Zertifikatskette weiterhin vertraut, könnte dies die Imitation von Websites erleichtern und möglicherweise verschlüsselte Kommunikation beobachtet oder verändert werden. Die Kompromittierung umfasste auch zwei Codesignatur-Zwischenschlüssel, sodass sich die Besorgnis über Website-Authentifizierung hinaus auf Software-Vertrauensekosysteme erstreckte, die Ketten durch diese Zwischenzertifikate akzeptieren.
Kann mich CVE-2026-111943 im Jahr 2026 noch betreffen?
Ja. Die Exposition bleibt für Software möglich, die noch keine aktualisierten Informationen zum Zertifikatsverzicht erhalten hat. Standard-Installationen von Chrome und Firefox erhielten schnellen Schutz, aber Go-Anwendungen, die mit anfälligen Versionen der Standardbibliothek kompiliert wurden, Anwendungen mit veralteten unabhängigen CA-Bündeln, nicht unterstützte Software, eingebettete Systeme oder Umgebungen, in denen Zertifikatswiderrufsmechanismen deaktiviert sind, könnten weiterhin den kompromittierten Zertifikatspfaden vertrauen. Organisationen sollten daher nicht davon ausgehen, dass das Aktualisieren ihrer Webbrowser allein das Risiko beseitigt.
Wie kann ich mich vor CVE-2026-111943 schützen?
Aktualisieren Sie auf Go 1.26.10, Go 1.27.3 oder neuer und kompilieren Sie betroffene Go-Anwendungen neu. Aktualisieren Sie Betriebssystem- und Anwendungsspeicher für Vertrauenszertifikate, Browserversionen, sprachspezifische Zertifikatsbündel und andere Software, die TLS-Überprüfung durchführt. Organisationen sollten auch überprüfen, dass den acht kompromittierten Zwischenzertifikaten nicht mehr vertraut wird, Zertifikatsketten-Telemetrie auf ihre Anwesenheit untersuchen und Anwendungen identifizieren, die statische oder eingebettete CA-Bündel enthalten. Wenn legitime Dienste derzeit von Ketten abhängen, die von den Notfall-Misstrauensmaßnahmen betroffen sind, ersetzen Sie diese Zertifikate durch Ketten, die in nicht betroffenen Zertifizierungsstellen verankert sind.
