// COMPUTERBASE — CYBERSECURITY
Sicherheitsvorfall bei Mudhra: Kompromittierte Schlüssel erlaubt Fälschen von Zertifikaten
Acht Intermediate-Zertifikate von eMudhra verwendeten private EC-384-Schlüssel mit nur 8 Bit Entropie, einer davon hatte sogar den Wert 4. Dadurch konnten TLS-Zertifikate für beliebige Domains erstellt werden. Browser haben die Zertifikate gesperrt, Administratoren anderer Systeme sollten ihre Trust Stores kontrollieren.
Mozilla und Chrome erhielten am 17. Oktober gegen 18 Uhr deutscher Zeit Kenntnis von dem Vorfall. Wie Heise berichtet, wurden die privaten Schlüssel entgegen ersten Annahmen offenbar nicht gestohlen, stattdessen hatte eMudhra für acht Intermediate-Zertifikate extrem schwache Werte erzeugt. Bei EC-384 repräsentieren die privaten Schlüssel eine Position auf einer elliptischen Kurve, in diesem Fall lagen sämtliche Werte jedoch lediglich zwischen 0 und 255. Sicherheitsforscher konnten die Schlüssel daher trivial bestimmen und anschließend eigene Zertifikate signieren.
Welche Konsequenzen das haben kann, demonstriert der Sicherheitsforscher „q3k“ mit q3k.google.com. Ein bei Hetzner betriebener Server präsentiert für die Domain ein am 20. Oktober ausgestelltes Zertifikat. Für einen unbemerkten Angriff auf Endanwender genügt ein solches Zertifikat allein allerdings nicht: Ein Angreifer müsste zusätzlich beispielsweise die Kontrolle über DNS oder das IP-Routing des Opfers erlangen, um dessen Verbindung auf den eigenen Server umzuleiten. Für die Web-PKI ist die Möglichkeit, Zertifikate für beliebige Domains auszustellen, dennoch ein gravierender Sicherheitsvorfall.
Die Browserhersteller reagierten binnen kurzer Zeit: Mozilla nahm die betroffenen Zertifikate schon am 17. Oktober und damit knapp drei Stunden nach der Meldung in OneCRL auf; am 20. Oktober entfernte das Unternehmen zusätzlich die zugehörigen Root-Zertifikate aus der Vertrauensliste. Firefox, Safari und Chrome blockierten den Demonstrator ebenfalls bereits mit einer Sicherheitswarnung. Der Reverse-Proxy-Anbieter Cloudflare wurde am 19. Oktober 2026 gegen 17:00 Uhr UTC auf die Vorfälle aufmerksam und ging zunächst ebenfalls von kompromittierten Schlüsseln aus. Daraufhin aktualisierte das Unternehmen zentrale Trust Stores und Basis-Images sowie Dienste, die Zertifikate für die Authentifizierung externer Systeme einsetzen. Anwendungen mit eigenen oder integrierten Trust Stores erforderten eine separate Untersuchung.
Je nach eigener TLS-Konfiguration sieht Cloudflare weiteren Handlungsbedarf. Kunden sollten sowohl Trust Stores und hochgeladene CAs für Mutual TLS als auch eigene Origin-Zertifikate bei „Full (strict)“ oder „Strict“ überprüfen. Bei Cloudflare Containers einschließlich Sandboxes müssen zudem Images und Abhängigkeiten auf betroffene Trust Stores kontrolliert werden. Verbindungen über HTTPS-Egress-Interception sind bereits geschützt, da Cloudflare in diesem Fall selbst die Zertifikatsprüfung übernimmt.
Besondere Aufmerksamkeit benötigen Systeme und Anwendungen, die eigene oder noch nicht aktualisierte CA-Speicher einsetzen. Der Vorfall wird unter CVE-2026-111943 geführt; unter anderem Go, Python-certifi und NetBSD haben bereits darauf reagiert. Administratoren unixoider Systeme sollten kontrollieren, ob aktualisierte CA-Zertifikatspakete verfügbar sind. Fehlen entsprechende Updates noch, lässt sich den betroffenen eMudhra-Roots vorübergehend auch selbst das Vertrauen entziehen. Für Debian und NetBSD stehen dafür entsprechende manuelle Verfahren zur Verfügung.
Neben den unmittelbaren technischen Folgen rücken die Sicherheitsprozesse bei eMudhra und der von BDO durchgeführte WebTrust-Audit in den Fokus. Zertifizierungsstellen müssen die Baseline Requirements des CA/Browser Forums erfüllen, die unter anderem genau solche Fehler bei Erzeugung und Verwaltung kryptografischer Schlüssel verhindern sollen. Dass gleich acht CA-Zertifikate mit trivial zu ermittelnden privaten Schlüsseln erstellt wurden, hätte bei einer gründlichen Prüfung der technischen und organisatorischen Prozesse auffallen müssen.
Wir danken Community-Mitglied aid0nex für den Hinwe