PHP2Shell: Kritische PHP-Lücke trifft Millionen Webserver

Am Nachmittag des 21. Oktober 2026 hat das PHP-Team Sicherheitsupdates veröffentlicht, die zwei kritische Schwachstellen im Sprachkern schließen. Unter dem gemeinsamen Namen PHP2Shell tragen sie die Kennungen CVE-2026-109618 und CVE-2026-109619, beide mit 9,2 von 10 möglichen Punkten bewertet (1). Nachgewiesen ist, dass Angreifer darüber ohne Anmeldung eigenen Code mit den Rechten des Webserver-Prozesses ausführen können. Betroffen sind nach Angaben der Entdecker alle Versionen seit PHP 5.4, praktisch also die PHP-Installationen der vergangenen zwei Jahrzehnte (2).

Weil Details vorab durchsickerten, zog das PHP-Team die Veröffentlichung um einen Tag vor, und der Branche blieb weniger Vorlauf als bei einer koordinierten Offenlegung üblich. Das BSI stuft die Lage in seiner Cybersicherheitswarnung mit Kritikalität 3 von 4 ein und rät, Server im Zweifel vom Netz zu trennen, solange das Update aussteht (3).

Ein Proof-of-Concept ist öffentlich, und gerade das Update verschärft die Lage: Wer alten und neuen Code vergleicht, kann ablesen, wo die Fehler sitzen. Das Sicherheitsunternehmen Sansec warnte deshalb vor automatisierten Massenangriffen schon kurz nach Erscheinen der Patches, das BSI hält eine breite Ausnutzung binnen weniger Stunden für wahrscheinlich. Mittlerweile melden mehrere Sicherheitsfirmen Angriffsversuche, darunter watchTowr, Cloudflare und Patchstack; erfolgreiche Kompromittierungen sind bislang nur vereinzelt berichtet.

Wer am Mittwochnachmittag öffentliche Webseiten in Deutschland aufrief, stieß vielerorts auf Wartungshinweise oder Fehlermeldungen. Beim Bund nahm das ITZBund mehrere Internetauftritte vom Netz, darunter Seiten der Bundesregierung und des Robert Koch-Instituts. Die Landesregierungen von Baden-Württemberg, Hessen und Thüringen schalteten ihre Angebote ganz oder teilweise ab, ebenso Städte wie Mainz und Dresden und nach Medienberichten die Berliner Charité. Auch in Finnland und Österreich gingen Seiten vom Netz.

Hinter den Ausfällen steckte nach bisherigem Stand kein Angriff, sondern eine Vorsichtsmaßnahme: Die Betreiber kappten die Verbindung selbst, um die Stunden bis zum Update ohne Angriffsfläche zu überstehen. Wer im Netz lediglich surft, muss nichts unternehmen; die Lücke steckt auf den Servern, Smartphones und PCs sind nicht betroffen. PHP läuft nach Branchenschätzungen hinter rund zwei Dritteln aller aktiven Websites. Selten war ein Stück Infrastruktur so sichtbar wie in dem Moment, in dem es fehlte.

Die erste Schwachstelle betrifft die Behandlung von Speicherfehlern: Nach einem Out-of-Memory-Fehler verarbeitet PHP beim Aufräumen interne Anfragedaten, die nur teilweise initialisiert sind. Die zweite setzt am Übergang zwischen zwei Anfragen an: Verweise auf bereits freigegebenen Speicher können eine Anfrage überleben und von einer späteren im selben Worker-Prozess erneut verwendet werden. Wie zuverlässig sich beides ausnutzen lässt, hängt laut den Entwicklern von Build, Erweiterungen und Betriebsbedingungen ab.

Gefährdet sind laut PHP-Team alle Installationen, die Webanfragen verarbeiten, also PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed, unter Linux wie unter Windows. Das höchste Risiko sieht das Team bei mod_php, wo eine Anfrage ohne Anmeldung den Angriff auslösen kann, noch bevor überhaupt Anwendungscode läuft. Ein aktuelles WordPress oder ein gepflegtes Framework schützt deshalb nicht, die Lücke liegt eine Ebene tiefer. Auf die Prüfliste gehören außerdem NAS-Systeme, Router und Firewalls, deren Verwaltungsoberfläche auf PHP läuft.

Vollständig schließen lassen sich die Lücken nur mit einem Update. Beim PHP-Projekt selbst tragen die korrigierten Versionen die Nummern PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Linux-Distributionen liefern eigene Pakete aus, die gepatcht sein können, ohne diese Versionsnummer zu tragen. Ob ein Server geschützt ist, verrät deshalb erst der Abgleich von php -v mit dem Sicherheitshinweis des jeweiligen Anbieters, etwa bei Debian, Ubuntu oder Red Hat. Für 7.4, 8.0 und 8.1 gibt es nur noch minimale Quellcode-Korrekturen. Wer dort noch arbeitet, sollte jetzt wechseln, sinnvollerweise mindestens auf PHP 8.3, das bis Ende 2027 Sicherheitsupdates erhält. PHP 8.2 erreicht bereits am 31. Dezember sein Supportende. Selten war das bekannte Ablaufdatum einer PHP-Version so greifbar wie in dieser Woche.

Bei der verbreiteten Serververwaltung Plesk stehen die korrigierten Builds für Linux bereit, für ältere Versionen und Windows sind sie noch in Arbeit. Leicht zu übersehen ist dabei, dass die Verwaltungsoberfläche von Plesk auf einer eigenen PHP-Engine läuft und einen gesonderten Hotfix braucht.

Wo ein Update nicht sofort möglich ist, empfiehlt das BSI zuerst, eine vorübergehende Trennung vom Internet zu erwägen. Erst wenn auch das ausscheidet, kommen die Workarounds zum Zug, die das PHP-Team als Notbehelf veröffentlicht hat, und zwar vollständig, weil Angreifer einzelne Maßnahmen umgehen können:

Die vollständige Liste mit weiteren Einstellungen steht in der Warnung des BSI. Jede dieser Maßnahmen hat ihren Preis: Neustarts unterbrechen laufende Anfragen, knappe Größenlimits brechen Uploads und umfangreiche Formulare. Keine davon ersetzt das Update. Auch die Regeln von Web Application Firewalls wie Cloudflare oder Bunny Shield bleiben laut BSI ein Provisorium.

Wer seine Internetpräsenz bei einem Hoster betreibt, sollte dort nachfragen, wann die Updates eingespielt werden. Bei Docker-Containern müssen die laufenden Container durch neue ersetzt werden, etwa mit docker compose pull && docker compose up -d. Anwendungen und Geräte, die eine eigene PHP-Laufzeit mitbringen, brauchen eine gesonderte Prüfung; das niederländische NCSC sammelt betroffene Produkte in einer laufend ergänzten Liste. Auch PHP im internen Netz gehört dazu, denn wer auf anderem Weg eingedrungen ist, kann sich über eine ungepatchte Installation dauerhaft festsetzen.

Mit der Veröffentlichung beginnt für Betreiber die eigentliche Arbeit.
Abgeschlossen ist sie erst, wenn die korrigierte PHP-Version nachweislich läuft.