Eine einzige Anfrage ohne Anmeldung genügt, um einen PHP-Prozess auf dem Server abstürzen zu lassen. Der Weg führt über die Pingback-Funktion von WordPress zur kritischen Sicherheitslücke in Googles Kompressionsbibliothek Brotli. Ein Update von WordPress behebt den Fehler nicht, das Sicherheitsupdate gehört auf den Server.
Ein Klick · kostenlosDr. Web bei Google bevorzugenMarkieren Sie drweb.de als bevorzugte Quelle. Dann sehen Sie unsere Artikel öfter unter den Top-Meldungen.Jetzt hinzufügenInhalt 5 Abschnitte
Patchstack-Forscher Kursat Cetin hat am Freitag beschrieben, wie Angreifer die Lücke CVE-2026-111497 über eine WordPress-Standardinstallation auslösen.[1] Bisher galt die Sicherheitslücke vor allem als Problem von Node.js, Python-Paketen und Bun, über das Dr. Web am 24. Oktober berichtet hat. Seit dem 27. Oktober führt die US-Cybersicherheitsbehörde CISA CVE-2026-111497 im Katalog aktiv ausgenutzter Sicherheitslücken.[3]
Das Wichtigste in Kürze
- WordPress bringt Brotli nicht selbst mit, nutzt für Abrufe aus dem Netz aber die Brotli-Bibliothek des Betriebssystems. Betroffen sind die Versionen 1.0.3 bis 1.2.0.
- Über die Pingback-Funktion lässt sich ohne Konto ein PHP-Prozess zum Absturz bringen. Dass sich über WordPress Schadcode ausführen lässt, hat bisher niemand öffentlich nachgewiesen.
- Abhilfe schafft nur das Sicherheitsupdate des Systempakets, unter Debian und Ubuntu mit unveränderter Versionsnummer.
Welchen Weg nimmt der Angriff durch WordPress?
Ein Angreifer schickt über die XML-RPC-Schnittstelle einen Pingback und gibt als Absender eine Adresse auf seinem eigenen Server an. WordPress ruft diese Adresse ab, der fremde Server antwortet mit manipulierten Brotli-Daten. Schon beim Entpacken schreibt die Brotli-Bibliothek über das Ende ihres Speicherbereichs hinaus, noch bevor WordPress die Antwort zu sehen bekommt. Eine frische Installation erfüllt alle Voraussetzungen, denn XML-RPC und Pingbacks sind ab Werk eingeschaltet.[1]
Nachgewiesen ist bisher der Absturz. In einer am 27. Oktober veröffentlichten Demonstration stürzte ein PHP-Prozess nach einem einzigen Aufruf ab oder lief mit weniger als 100 Byte Daten dauerhaft unter voller Prozessorlast. Nach Einschätzung von Patchstack genügen einige Hundert solcher Aufrufe, um eine Website lahmzulegen. Google bewertet die Lücke auf der Bewertungsskala CVSS 4.0 mit 9,2 von 10 Punkten, die US-Schwachstellendatenbank NVD nach CVSS 3.1 mit 9,8.[2]
Warum hilft kein WordPress-Update?
Der Fehler sitzt eine Ebene tiefer. Für jeden Abruf aus dem Netz nutzt WordPress die Bibliothek libcurl und weist sie an, komprimierte Antworten jeder Art zuzulassen und selbst zu entpacken.[1] Plugins, die eine vom Besucher eingegebene Adresse abrufen, greifen auf dieselbe Bibliothek zurück. Eine vorgeschaltete Firewall sieht in der Anfrage nichts Verdächtiges, denn die schädlichen Daten kommen erst mit der Antwort.
Google hat am 21. Oktober die abgesicherten Versionen Brotli 1.0.10, 1.1.1 und 1.2.1 veröffentlicht. Debian und Ubuntu haben die Fehlerbehebung in ihre älteren Pakete übernommen, ohne die Versionsnummer von Brotli zu ändern. Ein aktualisiertes Debian 13 meldet deshalb weiter Brotli 1.1.0. Entscheidend ist die Paketversion, unter Debian 13 etwa 1.1.0-2+deb13u1.[4] Das offizielle Docker-Image wordpress:latest enthielt laut Patchstack am Freitag noch die verwundbare Bibliothek.
An dieser Paketversion erkennen Sie das Sicherheitsupdate
| System | Sicherheitsupdate ab |
|---|---|
| Debian 13 | 1.1.0-2+deb13u1 |
| Debian 12 | 1.0.9-2+deb12u1 |
| Ubuntu 24.04 LTS | 1.1.0-2ubuntu0.1 |
| Ubuntu 22.04 LTS | 1.0.9-2ubuntu0.1 |
| Brotli selbst gebaut | 1.0.10, 1.1.1 oder 1.2.1 |
Debian und Ubuntu melden nach dem Update weiter die alte Brotli-Version, maßgeblich ist die Paketversion von libbrotli1. Stand: Lücke öffentlich bekannt, Update verfügbar, laut CISA aktiv ausgenutzt; über WordPress ist bisher nur der Absturz nachgewiesen.
Der Fall folgt einem Muster dieses Herbstes: Die Lücke steckt nicht im Content-Management-System, sondern in der Software darunter. Bei PHP2Shell lag der Fehler in der Skriptsprache, bei den kritischen Lücken in Nginx im Webserver. Erst in dieser Woche schloss WordPress zudem eine Sicherheitslücke im eigenen Update-Ablauf.
Diesmal liegt das Update nicht im WordPress-Dashboard, sondern beim Hoster. Ein Anruf dort schützt mehr als jedes Sicherheits-Plugin.
Markus Seyfferth, Chefredakteur Dr. Web
Was sollten Website-Betreiber jetzt tun?
- Systempaket prüfen lassen: Auf Shared Hosting aktualisiert der Hoster die Bibliothek. Fragen Sie nach, ob das Paket libbrotli1 die korrigierte Fassung hat. Auf eigenen Servern spielen Sie die Sicherheitsupdates ein und starten PHP und Webserver neu, damit laufende Prozesse die neue Bibliothek laden.
- Pingbacks abschalten: Bis zum Update entfernen Sie die Pingback-Funktion mit wenigen Zeilen Code oder sperren die Datei xmlrpc.php am Webserver. Der verbreitete Schalter zum Abschalten von XML-RPC sperrt laut Patchstack nur Funktionen mit Anmeldung.
- Jetpack beachten: Jetpack braucht die XML-RPC-Schnittstelle für die Verbindung zu WordPress.com.[5] Für Jetpack-Nutzer ist das gezielte Entfernen der Pingback-Funktion deshalb der bessere Weg als die Sperre der Datei.
- Entpacken abschalten: Ein Codeschnipsel von Patchstack schaltet das automatische Entpacken in WordPress ab und sichert so auch Plugins und Feeds.
Unternehmen, die über ihre Website personenbezogene Daten verarbeiten, verpflichtet Art. 32 DSGVO zu Sicherheitsmaßnahmen nach dem Stand der Technik.[6] Ein seit Tagen verfügbares Sicherheitsupdate gehört in der Regel dazu. Vor jedem Eingriff lohnt ein Backup, Werkzeuge zeigt der Vergleich der Backup-Plugins für WordPress. Welche Anbieter Systempakete selbst aktuell halten, steht im WordPress-Hosting-Vergleich.
FAQ: Kritische Brotli-Sicherheitslücke: WordPress-Websites über Pingbacks angreifbar
Ist meine WordPress-Website von der Brotli-Sicherheitslücke betroffen?
Betroffen ist jede WordPress-Website auf einem Server mit Brotli 1.0.3 bis 1.2.0 ohne Sicherheitsupdate, denn WordPress nutzt die Brotli-Bibliothek des Betriebssystems. Ob das Paket aktualisiert ist, zeigt die Paketversion, unter Debian 13 etwa 1.1.0-2+deb13u1. Bei Shared Hosting gibt der Hoster Auskunft.
Schützt ein Sicherheits-Plugin, das XML-RPC abschaltet?
Nicht immer. Viele Plugins nutzen laut Patchstack einen Schalter, der nur Funktionen mit Anmeldung sperrt. Die Pingback-Funktion bleibt dann erreichbar. Geschlossen ist dieser Weg erst, wenn die Pingback-Funktion entfernt oder die Datei xmlrpc.php am Webserver gesperrt ist.
Können Angreifer über die Lücke Schadcode auf WordPress-Servern ausführen?
Öffentlich nachgewiesen ist für WordPress bisher nur der Absturz von PHP-Prozessen, damit lässt sich eine Website lahmlegen. Für Node.js und Bun kennt Patchstack funktionierende Angriffe mit Codeausführung, für typische PHP-Server noch keinen öffentlichen.
Quellen
6 Quellen anzeigenQuellen ausblenden
- PatchstackWordPress doesn’t ship Brotli. It’s still exposed to CVE-2026-111497
- NVDCVE-2026-111497 Detail, abgerufen am 30. Oktober 2026
- CISAKnown Exploited Vulnerabilities Catalog, Eintrag vom 27. Oktober 2026
- Debian Security TrackerCVE-2026-111497, dazu Ubuntu Security: CVE-2026-111497, abgerufen am 30. Oktober 2026
- JetpackKnown issues
- EUR-LexVerordnung (EU) 2016/679 (DSGVO), Art. 32
Mehr Newshunger?
- HTTP2Shell: Lücke in Googles Brotli trifft Node.js, Python und weitere Software
- WordPress-Kern: Über 18.500 Angriffsversuche auf die Sicherheitslücke im Update
- Enable Media Replace: Behobene Sicherheitslücke stand über drei Jahre wieder offen
- Gravity Forms: Kritische Sicherheitslücke trifft Formulare, die Beiträge anlegen
- WordPress 7.1.4 schließt 22 Sicherheitslücken, eine davon im Update selbst
- WordPress Admin: 10 Essentials, die größere Pannen verhindern
