Brotli-Lücke: Wordfence bestätigt im Labor Codeausführung über WordPress-Pingbacks

Wordfence hat am 2. November 2026 berichtet, dass sich die Brotli-Lücke CVE-2026-111497 über eine normale WordPress-Funktion ausnutzen lässt. Im eigenen Labor führte ein öffentlicher Proof of Concept über die unauthentifizierte XML-RPC-Methode pingback.ping Code auf dem Server aus. Die Lücke steckt nicht in WordPress, sondern in der Kompressionsbibliothek Brotli, die Betriebssystem, Hoster oder Container-Image mitbringen.

Betroffen sind WordPress-Seiten auf Servern mit ungepatchter Brotli-Bibliothek, wenn XML-RPC erreichbar ist und Pingbacks angenommen werden. Ein Update von WordPress, Plugins oder Themes behebt das Problem nicht. Wer den Server selbst betreibt, sollte das Brotli-Update umgehend einspielen und die Dienste neu starten; Kunden von Managed Hosting sollten beim Anbieter nachfragen.

Was ist passiert?

Die Brotli-Entwickler haben die Lücke am 21. Oktober 2026 mit Version 1.2.1 geschlossen, die CVE folgte laut Wordfence am 22. Oktober. Es handelt sich um einen Schreibzugriff außerhalb des vorgesehenen Speichers im Decoder: Ein präparierter Brotli-Datenstrom kann Speicher beschädigen, Speicherinhalte offenlegen, den Prozess abstürzen lassen oder Code ausführen. S-EDV hat über die Lücke und ihre Folgen für Python, Envoy und Istio bereits berichtet. Neu ist der belegte Weg über WordPress.

Der Ablauf laut Wordfence: Ein Angreifer ruft ohne Anmeldung pingback.ping in xmlrpc.php auf und nennt eine eigene URL als Quelle. WordPress ruft diese URL ab, um den Pingback zu prüfen. Der Server des Angreifers antwortet mit einem als Brotli komprimierten, präparierten Inhalt, den der verwundbare Decoder verarbeitet. Passt der Exploit zur Umgebung, läuft Code mit den Rechten des PHP-Prozesses.

Wer ist betroffen?

Verwundbar sind die Brotli-Versionen 1.0.3 bis 1.2.0. Korrigiert sind 1.0.10, 1.1.1 und 1.2.1. Distributionen portieren den Fix oft zurück, ohne die Hauptversion zu ändern: Debian 13 behebt die Lücke im Paket 1.1.0-2+deb13u1, Debian 12 in 1.0.9-2+deb12u1. Entscheidend ist also die vollständige Paketrevision, nicht die Versionsnummer.

Für den gezeigten Angriff müssen mehrere Bedingungen zusammenkommen: XML-RPC ist erreichbar, pingback.ping ist registriert, der Zielbeitrag nimmt Pings an, der Server darf ausgehende Anfragen stellen, und der HTTP-Client nutzt den verwundbaren Decoder. Die Einstellung für Pingbacks unter Einstellungen, Diskussion gilt nur für neue Beiträge, ältere behalten ihre Einstellung.

Wie kritisch ist das?

Die Lücke hat einen CVSS-v4.0-Wert von 9.2. Die US-Behörde CISA führt sie seit dem 27. Oktober 2026 im Katalog aktiv ausgenutzter Lücken, nennt aber weder betroffene Anwendung noch Angriffsweg. Mehrere Sicherheitsfirmen beobachten Angriffsversuche. Wordfence fand bis zum 2. November aber keinen öffentlich belegten erfolgreichen Angriff auf ein Produktivsystem, auch nicht über WordPress, und betont, dass das fehlende Belege nicht ausschließt. Der öffentliche Exploit ist zudem nicht universell: Er lief in der vorgesehenen Zielumgebung mit PHP 8.3.36, gegen PHP 8.3.35 scheiterte er und brachte in einem Fall den PHP-Worker zum Absturz. Wordfence hält gezielte Angriffe auf Seiten mit gleichem Server-Image dennoch für plausibel und stuft das Update als dringend ein.

Was sollten Admins jetzt tun?

• Inventar: alle Server, Container und Images mit WordPress erfassen, auch Staging und Altsysteme.
• Patchstand: die Brotli-Paketrevision mit der Sicherheitsmeldung der Distribution vergleichen, danach Apache, PHP-FPM und alle Prozesse neu starten, die die alte Bibliothek geladen haben.
• Container: Images aus einer aktualisierten Basis neu bauen und ausrollen. Ein Neustart des bestehenden Containers tauscht die Dateien nicht aus.
• Managed Hosting: beim Anbieter bestätigen lassen, dass jede genutzte Brotli-Kopie gepatcht und die Dienste neu gestartet sind.
• Logs sichern und prüfen: auffällige pingback.ping-Aufrufe, ungewöhnliche ausgehende Verbindungen sowie Abstürze und Neustarts von PHP oder Webserver. Diese Spuren beweisen allein nichts, ihr Fehlen schließt einen Angriff aber auch nicht aus.
• Übergangsweise Pingbacks sperren, wenn keine Integration sie braucht. Das schließt nur den gezeigten Weg und ersetzt das Update nicht. Laut Wordfence schaltet die Option „Disable XML-RPC authentication“ unauthentifizierte Pingbacks nicht ab, ebenso wenig der Filter xmlrpc_enabled.

Einordnung für Unternehmen

Der Fall zeigt eine Lücke im üblichen WordPress-Wartungsprozess: Das Dashboard meldet alles als aktuell, während eine Bibliothek darunter verwundbar bleibt. Wer WordPress-Seiten verantwortet, braucht deshalb auch die Updates des Betriebssystems und der Images im Blick. Bei einem Kompromittierungsverdacht erst das System isolieren und untersuchen, danach Datenbankzugänge, API-Schlüssel und WordPress-Salts erneuern.

In eigener Sache

Wer Updates, Backups und Firewall seiner WordPress-Seite nicht selbst im Blick behalten will, findet bei S-EDV eine laufende WordPress-Wartung, die neue Sicherheitsupdates innerhalb von 48 Stunden einspielt.

Passende Anleitungen auf S-EDV

• XML-RPC in WordPress deaktivieren oder einschränken: Webserver-Sperre, Filter und Pingbacks
• Gehackte WordPress-Seite erkennen: Anzeichen prüfen und erste Schritte
• Brotli-Lücke CVE-2026-111497 trifft auch Python, Envoy und Istio

Quellen

• Wordfence: Analyse zu HTTP2Shell und WordPress (2. November 2026)
• Brotli: Sicherheitsrelease 1.2.1
• Debian: Sicherheitstracker zu CVE-2026-111497
• CISA: Eintrag im KEV-Katalog