Das PHP-Projekt hat die angekündigten Notfall-Updates gegen PHP2Shell veröffentlicht. Erste Exploit-Versuche gab es bereits vorher. Mehrere Organisationen in Deutschland hatten ihre Websites vorsorglich abgeschaltet.
Das halbe Web in Gefahr?
PHP2Shell: Die Notfall-Patches für PHP sind da
Die PHP Foundation hat am Mittwochnachmittag Sicherheitsupdates für zwei kritische Schwachstellen veröffentlicht, die unter dem Namen PHP2Shell bekannt geworden sind. Die Updates erschienen noch vor dem angekündigten Termin um 14 Uhr UTC, also kurz vor 16 Uhr deutscher Zeit. Die Lücken sind als CVE-2026-109618 und CVE-2026-109619 erfasst und erreichen jeweils einen CVSS-v4.0-Score von 9,2.
Behoben sind die Fehler in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für die nicht mehr regulär gepflegten Zweige PHP 7.4, 8.0 und 8.1 stellt das Projekt minimale Backports als Quellcode-Patches bereit. Die neuen Versionen stehen auf der Downloadseite von php.net bereit, Windows-Binärdateien unter windows.php.net. Die offizielle Ankündigung samt Sicherheitshinweis findet sich im Newsarchiv von php.net, technische Details in den Github-Advisories GHSA-w8hw-w9fx-j79w und GHSA-6wmf-4rv5-p3rp. Die meisten Admins erhalten die Updates über ihre Distribution oder ihren Hoster, siehe unten.
Codeausführung ohne Anmeldung bestätigt
Mit dem Release hat das PHP-Projekt die Details offengelegt, die es zuvor zurückgehalten hatte. CVE-2026-109618 betrifft eine Speicherkorruption bei Out-of-Memory-Zuständen, CVE-2026-109619 einen veralteten globalen Zustand. Beide stecken in der Speicherverwaltung und Fehlerbehandlung, also in Teilen von PHP, die praktisch jede Anfrage durchläuft. Für beide ist Remote Code Execution ohne Authentifizierung auf Apache mit mod_php nachgewiesen.
Die Befürchtungen von CERT-EU und dem Australian Cyber Security Centre (ACSC) haben sich damit weitgehend bestätigt. Die Lücken reichen bis PHP 5.4 zurück. Gefährdet ist laut den Maintainern jede Installation, die Webanfragen verarbeitet, ob über PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder Litespeed. Zusätzlich lässt sich Prozessspeicher auslesen, in dem Passwörter, API-Schlüssel und andere Geheimnisse liegen können.
CERT-EU empfiehlt nachdrücklich, PHP-basierte Anwendungen zu identifizieren und Vorkehrungen zu treffen, um Patches zu installieren, sobald korrigierte Versionen verfügbar sind. Ist eine sofortige Behebung nicht möglich, sollten Organisationen in Erwägung ziehen, Anwendungen mit Internetanbindung von öffentlichen Netzwerken zu isolieren, bis ein Patch installiert werden kann.
Wer nicht sofort aktualisieren kann, findet beim PHP-Projekt zwar Gegenmaßnahmen. Diese verkleinern aber nur die Angriffsfläche für einzelne Angriffswege und machen ein System ausdrücklich nicht sicher. Die Empfehlung von CERT-EU, ungepatchte Anwendungen vom Internet zu trennen oder offline zu nehmen, bleibt daher für alle aktuell, die das Update nicht umgehend einspielen können.
Angriffe liefen schon vor dem Patch
Die Hoffnung, Admins hätten nach dem Release noch etwas Zeit, hat sich zerschlagen. Bereits vor den Updates kursierten Proof-of-Concept-Exploits. Cloudflare-CTO Dane Knecht hatte schon früh am Tag auf X von ersten Angriffen berichtet. Auch Patchstack und Vega beobachteten Exploit-Versuche, letztere auf Basis eines öffentlichen PoC. Das Unternehmen Hadrian meldete wenige Stunden vor dem Release großflächige Angriffe, die überwiegend den Session-Upload-Progress-Mechanismus von PHP ausnutzten.
Watchtowr registrierte erste Angriffsversuche auf seine Sensoren etwa zeitgleich mit dem Erscheinen der Patches. Erfolgreiche Einbrüche hat das Unternehmen nach eigenen Angaben noch nicht gesehen, rechnet aber damit, dass sich das bald ändert. Die Firewall-Regeln, die Cloudflare laufend anpasst, bezeichnete Knecht ausdrücklich nur als Übergangslösung.
Dass Angreifer so schnell zur Stelle waren, liegt auch an einer verunglückten Offenlegung. Ursprünglich war die Veröffentlichung für Donnerstag, den 22. Oktober, geplant. Nachdem am Dienstag Informationen durchgesickert waren, zog das PHP-Projekt den Termin vor. Zudem war versehentlich ein Video mit einem funktionierenden Exploit erschienen, das die Entwicklung weiterer PoCs beschleunigte. Der Anbieter Chainguard veröffentlichte außerdem sechs Stunden vor dem Release Images mit dem vorab erhaltenen Fix, was die PHP Foundation scharf kritisiert: Angreifer konnten den Patch so in Binärform analysieren.
Ein großer Teil des Webs betroffen
Die Tragweite ist enorm. PHP läuft unter Content-Management-Systemen wie WordPress, Drupal und Joomla, unter Magento-Shops, Shared-Hosting-Plattformen und Control Panels, wie Huntress betont. Dazu kommt Software, die gar nicht offenlegt, dass sie intern PHP nutzt. Weil die Fehler im Interpreter selbst stecken, sind Anwendungen auch dann verwundbar, wenn ihr eigener Code sicher ist. Der Hoster GoDaddy nennt als mögliche Folgen Datendiebstahl, verunstaltete Websites und die vollständige Übernahme von Servern.
Für WordPress-Betreiber gilt, worauf Wordfence hinweist: Die automatischen Updates von WordPress aktualisieren PHP nicht. Wer eine WordPress-Seite betreibt, muss klären, ob der Hoster oder die eigene IT für das PHP-Update zuständig ist, und das gegebenenfalls aktiv nachfragen.
Websites vorsorglich offline
Zahlreiche Organisationen hatten im Laufe des Tages die Notbremse gezogen. Die Stadt Mainz schaltete ihr Portal mainz.de und weitere Dienste vorsorglich ab. Die Berliner Charité nahm ihre Website, die Seiten des Berlin Institute of Health und weitere angebundene Angebote unter Verweis auf eine weltweite Sicherheitslücke vom Netz. Die Ruhr-Universität Bochum sperrt ihre Webseiten seit 12.30 Uhr bis voraussichtlich Donnerstagmittag für Zugriffe von außen, intern und per VPN bleiben sie erreichbar. Auch der Rechnungsdienst Easybill, die Wiki-Plattform wiki.gg und der Verlag Choice of Games waren vorübergehend nicht erreichbar. Wann die Angebote nach dem Einspielen der Patches wieder online gehen, ist offen.
Was Admins jetzt tun sollten
Betreiber sollten umgehend auf die gepatchten Versionen aktualisieren und sicherstellen, dass die neue Version tatsächlich auf allen Servern läuft, die Webanfragen beantworten. Wer PHP über die Paketverwaltung seiner Distribution oder über Container-Images bezieht, muss dort auf aktualisierte Pakete achten. Weil Angriffe bereits vor dem Release liefen, empfiehlt es sich zudem, Systeme auf Spuren einer Kompromittierung zu prüfen und Zugangsdaten sowie API-Schlüssel zu rotieren, die im Speicher gelegen haben könnten. Für die Zweige 7.4 bis 8.1 sind die Backports nur eine Notlösung, langfristig hilft nur der Umstieg auf PHP 8.2 oder neuer.
(red)
