Vor einer Woche haben wir über die Lücke im Kompressionsverfahren Brotli geschrieben: ein Baustein in vielen Programmen, der auf drei Wegen korrigiert werden muss. Seit dem 27. Oktober führt die US-Behörde CISA sie als ausgenutzt. Die Frist, die sie US-Behörden setzt, ist der 10. November.
Inzwischen hat die Sicherheitsfirma Patchstack beschrieben, wie die Lücke eine Website trifft, die Brotli gar nicht enthält: WordPress.
Der Weg über die Antwort
WordPress ruft regelmässig selbst fremde Adressen ab. Es prüft Links, holt Vorschauen für eingebettete Inhalte, liest Feeds. Dafür nutzt es eine Bibliothek des Betriebssystems, und die entpackt Brotli-komprimierte Antworten automatisch, bevor WordPress sie überhaupt sieht.
Wer also einen eigenen Server aufsetzt, der präparierte Antworten liefert, und WordPress dazu bringt, diesen Server abzufragen, trifft die verwundbare Stelle. Der einfachste Weg dorthin ist laut Patchstack eine alte Funktion namens Pingback: Sie ist über die Datei xmlrpc.php erreichbar, braucht keine Anmeldung und ist bei WordPress standardmässig eingeschaltet. Dazu kommen Plugins, die Adressen von Besuchern abrufen.
Das hat zwei Folgen, die man nicht erwartet:
Ein WordPress-Update hilft nicht. Der Fehler steckt nicht in WordPress, sondern in der Bibliothek auf dem Server. Korrigieren muss ihn, wer den Server betreibt.
Eine Web-Firewall sieht wenig. Die Anfrage an die Website ist harmlos. Gefährlich ist die Antwort, die WordPress danach selbst abholt.
Was wir bei uns gefunden haben
Wir haben am 4. November auf zwei unserer Server nachgesehen.
Die Bibliothek ist korrigiert. Auf beiden Servern ist die neue Fassung installiert, auf dem einen seit dem Morgen des 27. Oktober.
Aber nicht überall in Betrieb. Auf diesem Server liefen noch zwölf Programme mit der alten Kopie, darunter die PHP-Prozesse für drei PHP-Versionen, über die Websites ausgeliefert werden, und die Verwaltungsoberfläche des Servers. Alle gehörten zu Diensten, die vor dem Update gestartet worden waren, die ältesten am 21. Oktober. Ein laufendes Programm lädt eine Bibliothek beim Start und behält sie, bis es neu gestartet wird. Die Datei auf der Platte war neu, im Speicher lief die alte.
Wir hatten im ersten Brotli-Beitrag selbst geschrieben: «Nach Updates an Laufzeitumgebungen die betroffenen Dienste neu starten. Sonst ist das Update installiert, aber nicht wirksam.» Bei uns war es genau so. Wir haben die betroffenen Dienste am 4. November neu geladen, seither läuft kein Programm mehr mit der alten Kopie.
Der Pingback war geschlossen. Von den 31 WordPress-Websites auf diesem Server gab keine einzige die Pingback-Funktion preis. Bei 28 ist xmlrpc.php gesperrt, die übrigen antworteten nicht oder mit «nicht gefunden». Der bequemste Weg zur Lücke war bei uns also zu. Andere Wege über Plugins schliesst das nicht aus.
Es ist dasselbe Muster wie beim Linux-Kern vor drei Tagen: Die Korrektur war da, sie lief nur nicht.
Was jetzt zu tun ist
Beim Hoster nachfragen. Wer seine WordPress-Website bei einem Anbieter betreibt, kann die Bibliothek nicht selbst aktualisieren. Die Frage lautet: Ist libbrotli gegen CVE-2026-111497 korrigiert, und wurden PHP und Webserver danach neu gestartet? Die zweite Hälfte der Frage ist die wichtigere.
Wer selbst betreibt: Das Paket libbrotli1 aktualisieren und danach PHP-FPM und den Webserver neu starten. Ob noch ein Programm die alte Kopie benutzt, zeigt auf Linux eine Suche nach gelöschten Bibliotheken im Speicher, Programme wie needrestart erledigen das bequemer.
Pingback abschalten. Kaum eine Website braucht ihn noch. Viele Sicherheits-Plugins und Verwaltungswerkzeuge für WordPress sperren xmlrpc.php mit einem Klick. Wer die Datei für eine App oder einen Dienst braucht, kann gezielt nur die Pingback-Funktion abschalten.
Container nicht vergessen. Wer WordPress in Docker betreibt, bekommt die Korrektur mit dem Betriebssystem des Servers nicht automatisch. Das Abbild muss neu gebaut werden.