Kompromittierte Zertifizierungsstelle eMudhra und die Folgen für WordPress und Magento

Stand 12. November 2026.

Beim Zertifikatsanbieter eMudhra wurde die Kompromittierung privater Schlüssel mehrerer Zwischenzertifikate nachgewiesen. Software, die diesen Zertifikatsketten weiterhin vertraut, kann dadurch gefälschte HTTPS-Gegenstellen akzeptieren. Das ist auch für Unternehmen relevant, deren WordPress-Website oder Magento-Shop selbst ein Zertifikat eines anderen Anbieters verwendet.

Für Betreiber steht insbesondere die Kommunikation mit externen Diensten im Mittelpunkt. Zahlungsabwicklung, Backups oder Schnittstellen können auf unterschiedliche Zertifikatslisten zurückgreifen. Wir empfehlen deshalb eine gezielte Prüfung durch Hosting und technische Betreuung.

Quelle: Mozilla-Vorfallsbericht, abgerufen am 12.11.2026.

Das Wichtigste für Entscheider und Entscheiderinnen

Quellen: Mozilla-Vorfallsbericht und Disclosure-Seite, jeweils abgerufen am 12.11.2026. Die vorgeschlagenen Prüfaufträge sind unsere Handlungsempfehlung.

Was bei eMudhra passiert ist

Bei HTTPS prüft die verbindungsaufbauende Software das Zertifikat der Gegenstelle. Dafür verwendet sie vertrauenswürdige Zertifizierungsstellen als Grundlage. Ein Server kann diese Prüfung beispielsweise durchführen, bevor er Daten an eine externe API übermittelt.

Am 17. Oktober 2026 wurde die Kontrolle über private Schlüssel von acht eMudhra-Zwischenzertifikaten nachgewiesen. Sechs betreffen TLS, zwei die Signierung von Software. Laut dem später veröffentlichten Vorfallsbericht führte ein Fehler bei der Verarbeitung des Schlüsselmaterials zu rekonstruierbaren privaten Schlüsseln der betroffenen ECDSA-Zwischenzertifikate.

Der Bericht nennt außerdem acht zusätzliche RSA-Zwischenzertifikate, die am 7. November wegen Betriebseinstellung widerrufen wurden. Bei diesen beschreibt eMudhra Probleme beim Umgang mit dem Schlüsselmaterial. Das ist von der nachgewiesenen Rekonstruierbarkeit der ursprünglichen acht ECDSA-Schlüssel zu unterscheiden.

Quellen: Microsoft zur Einordnung der acht Schlüssel und vollständiger Vorfallsbericht in Kommentar 82, jeweils abgerufen am 12.11.2026.

Die betroffenen Zwischenzertifikate wurden widerrufen. Browserhersteller haben zusätzliche Sperren verteilt. Bei Software mit eigener Zertifikatsliste oder fehlender Verarbeitung von Widerrufsinformationen kann jedoch eine gesonderte Aktualisierung erforderlich sein.

Quelle: Disclosure-Seite zum eMudhra-Vorfall, abgerufen am 12.11.2026.

Welche Geschäftsprozesse betroffen sein können

Ein Angreifer könnte mit dem betroffenen Schlüsselmaterial einen fremden Dienst nachahmen. Um eine bestehende Verbindung abzufangen, muss er zusätzlich den Datenverkehr umleiten oder sich in dessen Übertragungsweg befinden. Ob der Angriff gelingt, hängt auch von weiteren Prüfungen des jeweiligen Clients ab.

Quelle: Disclosure-Seite mit technischen Erläuterungen, abgerufen am 12.11.2026.

Für WordPress und Magento ergeben sich daraus beispielsweise folgende zu prüfende Bereiche:

Diese Beispiele sind eine Übertragung des Angriffswegs auf typische Integrationen. Sie sind keine Meldungen über nachgewiesene Angriffe auf die genannten Systeme.

Was bei WordPress geprüft werden sollte

WordPress verwendet für seine HTTP-API standardmäßig eine mitgelieferte Zertifikatsdatei. Die offizielle Dokumentation nennt dafür wp-includes/certificates/ca-bundle.crt. Ein Update des Servers aktualisiert diese mitgelieferte Datei nicht automatisch.

Quelle: WordPress-Dokumentation zur HTTP-API, abgerufen am 12.11.2026.

WordPress 7.1.4 vom 28. Oktober 2026 enthält laut Hersteller bereits eine Aktualisierung der Stammzertifikate wegen des eMudhra-Widerrufs. Die Korrekturen wurden auch für ältere betroffene Versionszweige bereitgestellt. Betreiber sollten den installierten Sicherheitsstand konkret prüfen lassen.

Quelle: Offizielle Versionsinformationen zu WordPress 7.1.4, abgerufen am 12.11.2026.

Der Sansec-Leitfaden nennt beim Abruf noch keinen behobenen WordPress-Release. Diese Angabe ist durch die neuere Herstellerinformation überholt. Für WordPress selbst sollte ein passendes Herstellerupdate gegenüber einem vorübergehenden manuellen Dateiaustausch bevorzugt werden.

Zusätzlich sind Plugins und mitgelieferte Bibliotheken mit eigenen Zertifikatslisten zu prüfen. Deren Zustand lässt sich aus der WordPress-Version allein nicht ableiten.

Technische Anleitung: WordPress aktualisieren. Hinweise zu separat mitgelieferten Listen: Sansec-Leitfaden. Beide abgerufen am 12.11.2026.

Was bei Magento und Adobe Commerce geprüft werden sollte

Bei Magento sollte die technische Betreuung insbesondere die installierten Composer-Abhängigkeiten und die von Erweiterungen mitgelieferten Bibliotheken untersuchen. Dazu können auch Bibliotheken für Zahlungsdienste gehören. Sansec beschreibt die Maßnahmen nach der jeweils gefundenen Zertifikatsdatei.

Technische Anleitung: Sansec mit Maßnahmen nach Datei und Bibliothek, abgerufen am 12.11.2026.

Ein dokumentiertes Beispiel ist composer/ca-bundle. Die Releases 1.4.16 und 1.6.0 enthalten Korrekturen zum eMudhra-Vorfall. Ob das Paket installiert ist und welche Version eingesetzt wird, muss am konkreten Projekt geprüft werden.

Quelle: Offizielle Releases von composer/ca-bundle, abgerufen am 12.11.2026.

Für die dauerhafte Behebung muss auch die Paketverwaltung berücksichtigt werden. Composer installiert bei vorhandener Lockdatei die dort festgelegten Versionen. Eine erneute Installation führt deshalb nicht automatisch zu korrigierten Abhängigkeiten. Wir empfehlen, erforderliche Änderungen im regulären Entwicklungs- und Bereitstellungsprozess umzusetzen und die betroffenen Shopfunktionen zu testen.

Technischer Hintergrund: Composer-Dokumentation zu Installation und Aktualisierung, abgerufen am 12.11.2026.

Wann das eigene Website-Zertifikat geprüft werden muss

Die Vertrauenslisten für ausgehende Verbindungen und das Zertifikat der eigenen Website erfüllen unterschiedliche Aufgaben. Beide Bereiche können im Zusammenhang mit dem Vorfall Prüfbedarf haben.

Microsoft kündigte am 11. November an, ab dem 16. November 2026 auch die verbleibenden eMudhra-Stammzertifikate aus seinen Vertrauenslisten zu entfernen. Der Zeitpunkt der Umsetzung hängt vom jeweiligen Produkt und dessen Aktualisierung ab.

Unternehmen sollten daher klären, ob ihre Website oder angebundene Dienste eine betroffene Zertifikatskette verwenden. Gegebenenfalls wird ein Ersatz oder eine alternative vertrauenswürdige Kette benötigt, um Verbindungsabbrüche zu vermeiden. Ein pauschaler Austausch aller Website-Zertifikate lässt sich daraus nicht ableiten.

Quelle und weiterführende Hinweise: Microsoft-Mitteilung einschließlich Update vom 11. November, abgerufen am 12.11.2026.

Was Unternehmen jetzt beauftragen sollten

Wir empfehlen eine gemeinsame Prüfung durch Hosting und technische Betreuung. Die genaue Zuständigkeit richtet sich nach dem jeweiligen Vertrag.

Die PHP-Konfiguration verdient dabei besondere Aufmerksamkeit. Sie kann festlegen, welche CA-Datei beziehungsweise welches Zertifikatsverzeichnis für bestimmte Verbindungen verwendet wird. Wir empfehlen, die tatsächlich genutzten Einstellungen zu dokumentieren.

Technischer Hintergrund: PHP-Dokumentation zur OpenSSL-Konfiguration, abgerufen am 12.11.2026.

Wie sich die Behebung nachweisen lässt

Die Prüfung sollte an den tatsächlich verwendeten Clients und Zertifikatslisten erfolgen. Ein erfolgreicher Browsercheck ist kein Nachweis für einen serverseitigen PHP-Aufruf. Ein fehlgeschlagener Verbindungsversuch muss ebenfalls fachlich eingeordnet werden, weil beispielsweise ein Netzwerkfehler dieselbe äußerlich sichtbare Folge haben kann.

Testmöglichkeiten und Erläuterungen: Disclosure-Seite, abgerufen am 12.11.2026.

Sansec beschreibt Prüfungen einzelner Zertifikatsdateien und weist auf das mögliche Überschreiben manueller Korrekturen hin.

Technische Anleitung: Sansec unter „Testing a fix“ und „Replacing a bundle file“, abgerufen am 12.11.2026.

Was über tatsächliche Angriffe bekannt ist

Zu tatsächlich über diesen Angriffsweg kompromittierten WordPress- oder Magento-Installationen liegen bisher wohl keine gesicherten Informationen vor. Die Disclosure-Seite erklärt, dass unklar ist, ob Angreifer die Schwäche gegen Clients außerhalb des Browserumfelds ausgenutzt haben.

Quelle: Disclosure-Seite zum Kenntnisstand, abgerufen am 12.11.2026.

Häufige Fragen von Website- und Shopbetreibern

Kann mein Shop trotz eines Zertifikats eines anderen Anbieters betroffen sein?

Ja. Für ausgehende Verbindungen ist entscheidend, welchen Zertifikatsketten die verbindungsaufbauende Software vertraut. Der Aussteller des eigenen Website-Zertifikats beantwortet diese Frage nicht.

Reicht ein Update von WordPress oder Magento?

Das lässt sich nur am konkreten Projekt beurteilen. Zusätzlich müssen gegebenenfalls separat mitgelieferte Zertifikatslisten von Erweiterungen und die Systemumgebung berücksichtigt werden.

Welche Bestätigung sollte die technische Betreuung liefern?

Wir empfehlen eine kurze Abschlussmeldung mit den geprüften Systemen und Komponenten, vorgenommenen Änderungen, Testergebnissen sowie verbleibenden offenen Punkten.

Weitere Informationen zu Magento Betreuung durch KonVis

Weitere Informationen zu WordPress Betreuung durch KonVis

Weiterführende Quellen und technische Anleitungen

Alle folgenden Quellen wurden am 12.11.2026 abgerufen.

• Sansec-Leitfaden zu kompromittierten Zertifizierungsstellen
• Disclosure-Seite zum eMudhra-Vorfall
• Mozilla-Vorfallsbericht
• Vollständiger Vorfallsbericht in Kommentar 82
• Microsoft-Mitteilung mit aktuellem Umstellungsplan
• WordPress 7.1.4 mit Angaben zur Zertifikatsaktualisierung
• WordPress aktualisieren
• WordPress-HTTP-API und Zertifikatsdatei
• Offizielle Releases von composer/ca-bundle
• Composer-Dokumentation zu Installation und Aktualisierung
• PHP-Konfiguration für OpenSSL
• curl-Dokumentation zur Zertifikatsprüfung