Am 26. Oktober verdichten sich zwei Risiken rund um weit verbreitete Webtechnik. Für die kritischen PHP-Lücken gibt es jetzt einen öffentlich nachvollziehbaren Beleg, dass Angreifer tatsächlich eigenen Code ausgeführt haben. Gleichzeitig stellt das PHP-Projekt neue Windows-Builds bereit, weil eine ebenfalls gefährliche Lücke in der mitgelieferten Brotli-Datenkompression bisher noch offen war.
Redaktionsstand: 26. Oktober 2026, 17:55 Uhr, Europe/Berlin. Die zugrunde liegenden PHP2Shell-Lücken und die Brotli-Lücke wurden schon früher veröffentlicht. Neu sind heute der belastbare Angriffsbeleg und die aktualisierten PHP-Windows-Pakete.
PHP2Shell: Aus Angriffsversuchen wurde bestätigte Codeausführung
Am 21. Oktober hatte PHP Notfallupdates gegen CVE-2026-109618 und CVE-2026-109619 veröffentlicht. Damals gab es bereits Scans und Angriffsversuche, aber noch keinen belastbaren öffentlichen Nachweis für eine erfolgreiche Übernahme.
Das hat sich geändert. Ein
am 26. Oktober ergänzter technischer Bericht
dokumentiert, wie Angreifer gegen ein absichtlich verwundbares Testsystem
eigenen Code ausführten. Betroffen war dort Apache mit mod_php und PHP
8.4.26. Die Forscher konnten Netzwerkverkehr, Speicherinhalte und gestartete
Prozesse miteinander verbinden. Damit geht der Nachweis deutlich über einen
Absturz oder einen bloßen Scan hinaus.
Der Bericht ist trotzdem kein Beleg dafür, dass jede verwundbare Website gleich leicht übernommen werden kann. Die erfolgreiche Angriffskette lief in einer für den Test günstigen Konfiguration. Sie zeigt aber, dass ein funktionierender Angriff praktisch möglich ist. Die Frage lautet deshalb nicht mehr, ob Betreiber auf einen besseren Beweis warten sollten.
Internetfähige PHP-Systeme müssen aktualisiert sein. Korrigiert sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Nach dem Update müssen Webserver und PHP-Prozesse neu gestartet werden. Bei Hosting-Angeboten sollten Kunden eine Bestätigung des Anbieters einholen, statt nur die Version der Website-Software zu prüfen.
Zusätzlich ist eine Einbruchsprüfung nötig. Ein Update beendet nicht nachträglich bereits gestartete Programme. CISA empfiehlt unter anderem, auf PHP-Prozesse zu achten, die Kommandozeilenprogramme starten oder Dateien aus dem Internet nachladen. Die Behörde stellt dafür auch eine Erkennungsregel und weitere Hinweise bereit. Unsere ausführliche Einordnung der ursprünglichen Lücken steht im PHP2Shell-Beitrag.
Brotli: Neue PHP-Windows-Builds schließen eine zweite Lücke
Das PHP-Projekt hat am 26. Oktober aktualisierte Windows-Builds veröffentlicht. Die Versionen 8.5.12-1, 8.4.27-1, 8.3.36-1 und 8.2.35-1 enthalten Brotli 1.2.1 und schließen damit CVE-2026-111497. Brotli komprimiert Daten, damit sie schneller übertragen werden. Präparierte komprimierte Daten können bei verwundbaren Decodern jedoch Speicher außerhalb des vorgesehenen Bereichs verändern.
In den PHP-Windows-Paketen ist der verwundbare Decoder über die cURL-Erweiterung erreichbar, wenn eine Anwendung die automatische Dekompression von HTTP-Antworten eingeschaltet hat. Diese Funktion ist laut PHP nicht standardmäßig aktiv. Das begrenzt die Zahl der unmittelbar gefährdeten Anwendungen, ist aber keine Entwarnung für Systeme, die solche Antworten verarbeiten.
Wichtig ist die Versionsendung „-1“: Ein am 21. Oktober installiertes PHP-Notfallupdate gegen PHP2Shell ist unter Windows nicht automatisch auch der heute veröffentlichte Brotli-Neubau. Betreiber sollten deshalb die tatsächlich eingesetzte Binärdatei prüfen und betroffene Pakete erneut aktualisieren.
Die Brotli-Lücke betrifft nicht nur PHP. Node.js, .NET, Python-Pakete und andere Programme können eigene Kopien der Bibliothek mitbringen. Ein Update der Betriebssystembibliothek repariert solche eingebetteten Kopien nicht zwangsläufig. Unternehmen sollten daher Laufzeiten, Container und Anwendungsabhängigkeiten getrennt erfassen. Das Blockieren komprimierter eingehender Anfragen kann das Risiko vorübergehend senken, schützt aber nicht vor einer schädlichen komprimierten Antwort, die ein Server selbst abruft.
Was jetzt Priorität hat
Für Betreiber sind heute drei Nachweise entscheidend: eine korrigierte PHP-Version, neu gestartete Prozesse und eine Prüfung auf verdächtige Aktivitäten vor dem Update. Unter Windows kommt die Kontrolle hinzu, ob der neue PHP-Build mit der Endung „-1“ installiert ist. Für normale Nutzer ergibt sich aus diesen Meldungen kein pauschaler Passwortwechsel. Sie sind vor allem ein Arbeitsauftrag an Hostinganbieter, Administratoren und Entwicklungsteams.
Quellen
- PHP2Shell exploitation observed: packet-to-process RCE evidence — 0x4D31 / GitHub
- PHP2Shell security flaws now successfully exploited in the wild — BleepingComputer
- Critical vulnerabilities in PHP require immediate patching — CISA
- Updated PHP Windows builds for Brotli security fix — PHP
- Brotli 1.2.1 release — Google / GitHub