Brotli-Schwachstelle kann code execution über WordPress ermöglichen
Die als CVE-2026-111497 erfasste Brotli-Schwachstelle kann es einem nicht authentifizierten Angreifer ermöglichen, über WordPress Code auszuführen, wenn mehrere Bedingungen auf Server- und Websiteebene zusammentreffen. Google veröffentlichte die Schwachstelle am 22. Oktober 2026, einen Tag nachdem das Brotli-Projekt korrigierte Releases herausgegeben hatte. Sie hat einen CVSS v4.0-Wert von 9,2 von 10, eine standardisierte Schweregradbewertung, die sie als kritisch einstuft. Die Schwachstelle wird informell auch HTTP2Shell, Node2Shell und Brotli2Shell genannt, obwohl sie nicht das HTTP/2-Protokoll betrifft.
Brotli ist ein Komprimierungsformat und eine Softwarebibliothek, die die Größe von Webinhalten während der Übertragung reduziert. Brotli wird üblicherweise von einer Hosting-Plattform, einem Betriebssystem, einem container image, einem Webserver oder einer anderen Serverkomponente bereitgestellt, sodass der Name einem WordPress-Betreiber möglicherweise nie im Dashboard begegnet. Die Schwachstelle befindet sich weder in WordPress Core noch in einem Plugin oder Theme. Eine Aktualisierung dieser Komponenten ersetzt die betroffene Brotli-Bibliothek nicht.
CVE-2026-111497 ist ein out-of-bounds write. Das bedeutet, dass bösartig komprimierte Daten Brotli dazu bringen können, außerhalb des ihm zugewiesenen Speicherbereichs zu schreiben. Diese Beschädigung kann einen Prozess zum Absturz bringen, im Speicher enthaltene Informationen offenlegen oder remote code execution ermöglichen, also einem Angreifer erlauben, Befehle auszuführen, ohne physisch anwesend zu sein. Allein das Vorhandensein von Brotli auf einem Server belegt jedoch nicht, dass eine Website ausnutzbar ist. Vom Angreifer kontrollierte komprimierte Daten müssen über eine Website oder einen anderen öffentlich erreichbaren Dienst einen anfälligen Decoder erreichen.
Die ersten korrigierten Upstream-Releases sind Brotli 1.0.10 für die Versionen 1.0.3 bis 1.0.9, 1.1.1 für Version 1.1.0 und 1.2.1 für Version 1.2.0. Linux- und Hosting-Anbieter können eine Korrektur mittels backport einspielen, das heißt, sie fügen einem älteren Softwarepaket die Sicherheitskorrektur hinzu. Debian 13 korrigierte das Problem beispielsweise in libbrotli1 1.1.0-2+deb13u1, obwohl der Paketname weiterhin mit 1.1.0 beginnt. Administratoren müssen daher die vollständige Paketrevision mit dem Sicherheitshinweis des Anbieters vergleichen, anstatt sich auf die ersten drei Versionsnummern zu verlassen.
Das öffentliche WordPress proof of concept verwendet XML-RPC, eine WordPress-Schnittstelle, über die andere Systeme Websitefunktionen aufrufen können. Eine nicht authentifizierte Anfrage ruft pingback.ping unter xmlrpc.php auf und übermittelt eine vom Angreifer kontrollierte Webadresse. WordPress ruft diese Adresse ab, um zu prüfen, ob sie auf einen echten Beitrag verlinkt. Der Server des Angreifers antwortet anschließend mit speziell vorbereiteten Daten, die als mit Brotli komprimiert gekennzeichnet sind. Wenn Decoder, PHP build und memory layout zum payload passen, kann der Angreifer Code mit den Berechtigungen ausführen, die dem PHP-Prozess der Website zugewiesen sind.
Diese route setzt mehrere Bedingungen voraus. xmlrpc.php muss erreichbar sein, pingback.ping muss registriert sein, der Beitrag muss Pings akzeptieren, der Server muss die ausgehende Anfrage ausführen dürfen und der HTTP client der Website, also die Software zum Abrufen von Webinhalten, muss den betroffenen Decoder verwenden. Außerdem muss der veröffentlichte exploit genau zum PHP build, zur runtime environment und zum memory layout passen. XML-RPC ist lediglich der für diese Demonstration gewählte trigger und keine grundsätzliche Voraussetzung der Brotli-Schwachstelle. Andere Software könnte denselben Decoder zugänglich machen, während Plugins und Themes zusätzliche WordPress-routes schaffen könnten.
Wordfence Threat Intelligence reproduzierte code execution ohne Authentifizierung in isolierten container-Umgebungen, also paketierten Softwareumgebungen, mit WordPress 7.1.3 auf Debian 13.7, Apache 2.4.69, PHP 8.3.36, das innerhalb von Apache als mod_php ausgeführt wurde, sowie dem anfälligen Debian-Paket libbrotli1 1.1.0-2+b7. Die standardmäßige Speicher-Randomisierung des Betriebssystems war aktiviert. Nachdem ausschließlich Brotli auf das korrigierte Debian-Paket aktualisiert worden war, führte dieselbe Abfolge keinen Code mehr aus und der Server blieb funktionsfähig.
Dasselbe payload führte gegen PHP 8.3.35 keinen Code aus. In einer anfälligen WordPress-Umgebung brachte es stattdessen den PHP worker zum Absturz. Laut Wordfence zeigt dies, dass die PHP-Version allein das Ergebnis nicht bestimmt. Der genaue build und die runtime können darüber entscheiden, ob ein payload Code ausführt, einen Absturz verursacht oder keine Wirkung hat. Angreifer können WordPress, PHP, den Webserver, die Verfügbarkeit von XML-RPC und Teile des Verhaltens bei ausgehenden Anfragen aus der Ferne erkennen. Dies könnte ihnen helfen, payloads für häufig wiederverwendete server images auszuwählen. Gewöhnliche Webanfragen legen normalerweise weder den genauen kompilierten build noch das memory layout offen, die erforderlich wären, um dieses payload an einen beliebigen Server anzupassen. Wordfence hat eine solche Anpassung aus der Ferne nicht demonstriert.
Es gibt Hinweise auf aktive Angriffsversuche, doch die öffentlich dokumentierten Ergebnisse bleiben begrenzt. Die US-amerikanische Cybersecurity and Infrastructure Security Agency nahm CVE-2026-111497 am 27. Oktober 2026 in ihren Known Exploited Vulnerabilities-Katalog auf, ohne die betroffene Anwendung, das Opfer, die route oder das Ergebnis zu nennen. ELLIO erfasste einen Versuch, der auf einen offiziellen Node.js build abzielte, doch dieser führte bei 50 Wiederholungen gegen ein passendes anfälliges Ziel nicht zu Befehlszugriff. Previdian beobachtete bis zum 2. November weitere Versuche, wies jedoch darauf hin, dass sich anhand seiner Telemetrie nicht feststellen ließ, ob die Ziele anfällig waren oder die Angriffe erfolgreich verliefen. Check Point berichtete über automatisierte Scans und verdächtige payloads, jedoch über keine bestätigte Kompromittierung. Imperva und ELLIO erzielten unabhängig voneinander in kontrollierten Laborumgebungen code execution gegen anfällige Node.js builds.
Diese Tests zeigen, dass eine Ausnutzung außerhalb von WordPress möglich ist, dokumentieren jedoch keinen Sicherheitsvorfall in einer Produktivumgebung. Mit Stand vom 2. November 2026 fand Wordfence keinen unabhängig überprüfbaren öffentlichen Bericht über eine erfolgreiche Kompromittierung einer Produktivumgebung oder über eine Kompromittierung durch die WordPress-XML-RPC-route. Der begrenzte öffentliche Eintrag von CISA bedeutet, dass dieses Fehlen von Berichten kein Beleg dafür ist, dass eine Ausnutzung niemals erfolgreich war.
Eine unter Werkzeuge und Website-Zustand angezeigte WordPress-Version kann nicht beantworten, ob der Server geschützt ist. Kunden von Managed Hosting sollten nachfragen, ob jeder von ihrer Website verwendete Brotli-Decoder die Korrektur für CVE-2026-111497 enthält und ob alle betroffenen Dienste neu gestartet oder erneut bereitgestellt wurden. Die nicht authentifizierte XML-RPC-Funktion system.listMethods kann anzeigen, ob pingback.ping registriert ist. Diese sichere Prüfung belegt jedoch lediglich, dass die Methode vorhanden ist, und nicht, dass eine Ausnutzung möglich ist. Das Deaktivieren künftiger Pingbacks unter Einstellungen und Diskussion ändert möglicherweise nichts an älteren Beiträgen, die ihre bisherigen Einstellungen beibehalten können.
Die Option Disable XML-RPC authentication von Wordfence deaktiviert nicht authentifizierte Pingbacks nicht. Der ähnlich benannte WordPress-Filter xmlrpc_enabled gilt ebenfalls nur für Methoden, die eine Authentifizierung erfordern, und deaktiviert pingback.ping nicht. Änderungen am Verhalten von XML-RPC oder Pingbacks können legitime Integrationen beeinträchtigen und blockieren lediglich die demonstrierte WordPress-route. Sie reparieren Brotli nicht.
Administratoren selbst verwalteter Systeme sollten das Update ihres Betriebssystem- oder Plattformanbieters installieren, die vollständige Paketrevision überprüfen und Apache, PHP-FPM, das PHP als separaten Dienst ausführt, sowie alle anderen Prozesse neu starten, die die alte Bibliothek geladen haben.