Cloudflare patcht Systeme nach Kompromittierung von eMudhra-Zertifikatsschlüsseln

Am 19. Oktober 2026 stellte Cloudflare fest, dass die privaten Schlüssel für acht eMudhra-Zwischenzertifikate kompromittiert worden waren. Das Unternehmen begann sofort damit, seine Infrastruktur zu patchen, und veröffentlichte Updates für seine Client-Software, um potenzielle Traffic-Abfangaktionen zu verhindern. Dieser Vorfall betrifft weit verbreitete vertrauenswürdige Zertifizierungsstellen und erfordert Maßnahmen von Nutzern bestimmter Cloudflare-Dienste sowie selbst gehosteter Anwendungen.

Was ist passiert?

Die Kompromittierung betrifft schwache private Schlüssel, die mit acht von eMudhra ausgestellten Zwischenzertifikaten verknüpft sind. Da diese Schlüssel angreifbar sind, könnte ein Angreifer Zertifikate für jede beliebige Domain fälschen. Dies würde es ihm ermöglichen, sich als legitimer Server auszugeben, verschlüsselten Datenverkehr abzufangen oder Daten während der Übertragung zu manipulieren. Diese Zertifikate wurden von großen Browsern, Betriebssystemen und der eigenen Infrastruktur von Cloudflare als vertrauenswürdig eingestuft, was das potenzielle Ausmaß des Schadens breit und schwerwiegend macht.

Das Sicherheitsteam von Cloudflare entdeckte das Problem am 19. Oktober gegen 17:00 UTC. Sie priorisierten die Aktualisierung kritischer Dienste, die öffentliche Zertifikate zur Authentifizierung entfernter Endpunkte verwenden. Dazu gehörten Proxies, die mit Origin-Servern verbunden sind, sowie Anwendungen, die externe APIs aufrufen. Das Unternehmen aktualisierte auch gemeinsame Trust Stores und Basis-Images, um einen einheitlichen Pfad zur Abmilderung für Dienste bereitzustellen, die den Zertifikatsvertrauen von diesen Quellen erben. Zum Zeitpunkt der öffentlichen Offenlegung hat Cloudflare keine aktive Ausnutzung dieser Schwachstelle auf seinen Diensten festgestellt.

Um diese Schutzmaßnahmen zu aktivieren, führte Cloudflare Neuladungen, Neustarts und Image-Bereitstellungen über seine CDN-, Developer- und Zero-Trust-Produkte hinweg durch. Anwendungen mit gebündelten oder benutzerdefinierten Trust Stores erforderten separate Bewertungen und Updates. Das Unternehmen betont, dass diese Behebung Mängel bei der zertifikatsbasierten Authentifizierung adressiert, nicht jedoch Schwächen in den TLS-Verschlüsselungsalgorithmen selbst. Die Arbeit daran, alle internen Systeme vollständig zu schützen, läuft weiter.

Wichtige Details

• Acht private Schlüssel von eMudhra-Zwischenzertifikaten wurden aufgrund einer Schwäche kompromittiert.
• Angreifer können Zertifikate für jede Domain fälschen, um Datenverkehr abzufangen oder zu modifizieren.
• Nutzer von Cloudflare One Client müssen auf v2.5.6 (Android), v1.12.16 (iOS) oder die Desktop-Version 2026.8.2115.0 aktualisieren.
• Nutzer von Cloudflare Tunnel (cloudflared) müssen auf Version 2026.10.2 aktualisieren.
• Kunden, die Full (strict) oder Strict Mode für origin TLS verwenden, sollten ihre benutzerdefinierten Zertifikate überprüfen.
• Browser-Maintainer nutzten schnelle Widerrufsmethoden wie Chrome CRLSets, um das Problem rasch zu entschärfen.

Hintergrund

Secure Sockets Layer (SSL)- und Transport Layer Security (TLS)-Zertifikate sind digitale Dateien, die einen kryptografischen Schlüssel an die Details einer Organisation binden. Sie ermöglichen verschlüsselte Verbindungen zwischen Webservern und Browsern. Das Vertrauensmodell stützt sich darauf, dass Zertifizierungsstellen (CAs) wie eMudhra die Identität prüfen, bevor sie Zertifikate ausstellen. Zwischenzertifikate stehen zwischen dem Root-CA und dem End-Entity-Zertifikat und bilden eine Vertrauenskette. Wenn ein privater Schlüssel eines Zwischenzertifikats kompromittiert wird, bricht die Integrität dieser Kette. Angreifer können dann gültig aussehende Zertifikate für Domains ausstellen, die ihnen nicht gehören, und so die Warnungen der Browser umgehen.

Trust Stores sind Datenbanken, die von Betriebssystemen und Browsern gepflegt werden und auflisten, welche CAs vertrauenswürdig sind. Wenn ein Server ein Zertifikat präsentiert, prüft der Client dieses gegen den Store. In diesem Vorfall lag die Schwachstelle in der Schlüsselgenerierung oder -verwaltung durch die CA, nicht im TLS-Protokoll selbst. Die Behebung umfasst das Entfernen kompromittierter Zertifikate aus den Trust Stores oder das Aktualisieren der Software, um sie abzulehnen. Für selbst gehostete Umgebungen bedeutet dies oft, dass Systempakete oder Anwendungsabhängigkeiten, die ihre eigenen Vertrauenslisten verwalten, manuell aktualisiert werden müssen.

Warum ist das wichtig?

Für Teams, die ihre eigene Software betreiben, verdeutlicht dieser Vorfall die Fragilität der Web Public Key Infrastructure (WebPKI). Im Gegensatz zu Browser-Nutzern, die automatische Updates erhalten, verlassen sich selbst gehostete Anwendungen möglicherweise auf statische Trust Stores oder veraltete Systempakete. Wenn Ihre Anwendung ein SDK nutzt, das die Verifizierung an das Betriebssystem delegiert, kann ein System-Update ausreichen. Wenn Ihre Anwendung jedoch ihren eigenen Trust Store bündelt oder eine spezifische HTTP-Bibliothek verwendet, müssen Sie diese Abhängigkeiten direkt aktualisieren. Versäumen Sie dies, bleiben Ihre Dienste anfällig für Man-in-the-Middle-Angriffe.

Entwickler müssen unter die Oberfläche ihres Software-Stacks schauen. Das Aktualisieren eines High-Level-SDKs ändert möglicherweise nicht die zugrunde liegende Richtlinie zur Zertifikatsverifizierung, wenn die HTTP-Bibliothek oder Laufzeitumgebung unverändert bleibt. Nach dem Anwenden der Patches könnten Sie Zertifikatsfehler in Logs oder Dashboards sehen. Es ist entscheidend, die Verifizierung nicht zu deaktivieren, um diese Fehler zu unterdrücken. Doing so removes the authentication protection the updates are designed to restore. Validating the fix requires testing the actual TLS path used by the application, not just a browser check.

Dieses Ereignis unterstreicht auch die Notwendigkeit einer robusten Überwachung der Gültigkeit von Zertifikaten und des Vertrauensstatus. Während Browser das Vertrauen global über Mechanismen wie CRLSets widerrufen können, fehlt individuellen Servern und Anwendungen diese zentrale Kontrolle. Teams müssen ihre Vertrauenskonfigurationen proaktiv verwalten und auf Anomalien überwachen. Sich nur auf Standardeinstellungen des Systems ohne regelmäßige Audits zu verlassen, kann Lücken hinterlassen, wenn eine CA kompromittiert wird. Automatisierte Tools, die den Status von Zertifikaten und Änderungen an Trust Stores verfolgen, sind für die Aufrechterhaltung der Sicherheitslage in selbst gehosteten Umgebungen unerlässlich.

Was Sie tun können

• Aktualisieren Sie Cloudflare One Client und WARP Apps sofort auf die für Ihre Plattform angegebenen Versionen.
• Aktualisieren Sie Cloudflare Tunnel (cloudflared) auf Version 2026.10.2 und stellen Sie Container-Images neu bereit.
• Überprüfen und aktualisieren Sie Mutual-TLS-Trust Stores, wenn Sie kundenseitig konfigurierte TLS-Client-Authentifizierung nutzen.
• Prüfen Sie die Konfiguration Ihrer Origin-Server auf Full (strict) oder Strict Mode und ersetzen Sie nicht mehr vertrauenswürdige Zertifikate.
• Auditieren Sie Anwendungsabhängigkeiten auf gepatchte Pakete, die von Dennis Jackson (Mozilla) aufgelistet werden, und bauen Sie Images neu.
• Verifizieren Sie die Fixes, indem Sie den tatsächlichen TLS-Verifizierungspfad der Anwendung testen, nicht nur die Browser-Konnektivität.