PHP Apocalypse

Am 21. Oktober 2026 veröffentlichte das PHP-Projekt um 16:00 Uhr MESZ (14:00 Uhr UTC) Notfall-Updates für zwei kritische Schwachstellen im Kern von PHP. Beide tragen die höchste Risikoeinstufung CVSS 4.0 9.2 und erlauben Remote Code Execution ohne Anmeldung. In der Szene laufen sie unter dem Namen php2shell. Noch bevor viele Server gepatcht waren, nahmen Behörden, Kliniken und Universitäten weltweit ihre Webseiten vom Netz. Kurz darauf wurde eine dritte, bis heute ungepatchte Schwachstelle bekannt. Dieser Beitrag erklärt, was dahintersteckt, wie Sie betroffene Systeme erkennen und was jetzt zu tun ist.

Die Schwachstellen im Detail

Alle drei Lücken sitzen in PHP selbst, nicht in einer Anwendung darüber. Eine verwundbare App ist nicht nötig. Schon eine schlichte Seite reicht, denn der fehlerhafte Code läuft, bevor der eigentliche Anwendungscode startet. Entdeckt hat die beiden ersten Lücken Wiz Research, unterstützt von KI-Modellen.

CVE-2026-109618 (RCE über Speichererschöpfung, GHSA-w8hw-w9fx-j79w). Gerät PHP bei der Verarbeitung einer Anfrage in eine Out-of-Memory-Situation, kann die Abarbeitung mitten in der Initialisierung abbrechen. Die internen Request-Daten sind dann nur teilweise angelegt. Beim Aufräumen behandelt PHP diese halbfertigen Daten als gültig. Das PHP-Team bestätigt vollständige RCE über HTTP gegen mod_php mit Standardkonfiguration.

CVE-2026-109619 (RCE über veralteten globalen Zustand, GHSA-6wmf-4rv5-p3rp). Hier überlebt anfragebezogener interner Zustand, nachdem der zugehörige Speicher bereits freigegeben wurde. Verarbeitet derselbe Worker-Prozess eine spätere Anfrage, greift er auf diesen veralteten Zustand zu, bevor er ihn zurücksetzt. Das Ergebnis ist eine Use-after-Free-Lücke. Sie erlaubt das Auslesen von Prozessspeicher und Codeausführung mit den Rechten des Web-Workers.

CVE-2026-115560 (Session Upload Progress). Diese Lücke machte das PHP-Projekt am 23. Oktober 2026 in einem informativen Hinweis publik. Betroffen ist nur eine ungewöhnliche Kombination. Die Anwendung muss session.serialize_handler in der Konfiguration auf php_binary oder php_serialize stehen haben und ihn zur Laufzeit per ini_set() auf php umstellen, bevor session_start() läuft. Zusätzlich muss Session-Upload-Progress aktiv sein. Wer den Serialize-Handler zur Laufzeit nie ändert, ist in der Regel nicht betroffen. Ein vollständiges Advisory und der Fix folgen mit dem nächsten regulären Release. Bis dahin lautet die Empfehlung session.upload_progress.enabled=0.

Betroffene und gefixte Versionen

Verwundbar ist praktisch jede PHP-Version der vergangenen rund zwanzig Jahre, von PHP 5.4 bis einschließlich 8.5.11. Das höchste Risiko tragen Installationen mit mod_php. Betroffen sind ebenso PHP-FPM, php-cgi, FrankenPHP und LiteSpeed.

Gefixt sind die beiden RCE-Lücken in folgenden Versionen:

• PHP 8.5.12
• PHP 8.4.27
• PHP 8.3.36
• PHP 8.2.35

PHP 8.6.0 RC4 enthält die Fixes ebenfalls, eignet sich aber nicht für den Produktivbetrieb. PHP 8.1 und älter erhalten vom PHP-Projekt keine offiziellen Releases mehr. Für 7.4, 8.0 und 8.1 gibt es minimale Source-Backports, einige Distributionen und LTS-Anbieter liefern eigene Patches. Wichtig dabei. Debian, Ubuntu und andere portieren Sicherheitsfixes oft zurück, ohne die Versionsnummer zu ändern. Die Nummer allein sagt dann nichts über den Patch-Stand. Prüfen Sie das Changelog des Pakets.

Warum die Lücke die halbe Web-Infrastruktur bedroht

PHP läuft auf rund 70 Prozent aller Webseiten. Wikipedia, Etsy, Tumblr und unzählige Content-Management-Systeme wie WordPress, Joomla, Drupal und MediaWiki bauen darauf. Eine Lücke im Kern trifft also nicht einzelne Anwendungen, sondern einen Grundbaustein des Webs.

Der Suchdienst Censys verfolgt die Ausbreitung seit dem 21. Oktober 2026. Mit Stand 25. Oktober 2026 hatte Censys 42,2 Millionen PHP-Dienste auf einer verwundbaren Version gesehen. 32,4 Millionen standen beim letzten Scan noch auf einer betroffenen Fassung. Von den Diensten, die ihre Version überhaupt verraten, waren 75,4 Prozent verwundbar. Rund 57 Prozent aller erfassten PHP-Dienste nennen ihre Version gar nicht und tauchen in dieser Statistik nicht auf. Die Dunkelziffer liegt also höher.

Besonders deutlich wird das Altlastenproblem an der häufigsten gemeldeten Version. Mit 15,6 Prozent führt PHP 7.4.33 die Liste an, eine seit Langem abgekündigte Version ohne offiziellen Fix. Dahinter folgen weitere End-of-Life-Stände wie 8.1.34, 5.6.40 und 5.2.6. Viele dieser Server wird nie jemand patchen.

Dazu kommt ein Faktor, der die Lage verschärft. Das Zeitfenster zwischen Veröffentlichung und ersten Angriffen schrumpft, weil Angreifer KI-Modelle einsetzen, um einen veröffentlichten Patch zu analysieren und daraus einen Exploit zu bauen. Der Sicherheitsforscher LiveOverflow brachte es am 24. Oktober 2026 auf den Punkt. Wer einen funktionierenden Basis-Exploit hat, ist von der Anpassung an die nächste Zielversion nur noch eine Eingabeaufforderung entfernt. Auch die Entdeckung selbst ist ein Beispiel dafür. Die Lücken lagen über ein Jahrzehnt unentdeckt im Code und wurden erst mit KI-Unterstützung gefunden.

Der 21. Oktober 2026: Webserver gehen weltweit vom Netz

Mit der Veröffentlichung um 16:00 Uhr MESZ empfahlen das BSI in Deutschland und die US-Behörde CISA, betroffene Seiten vorsorglich abzuschalten, solange keine Patches verfügbar sind. Viele Betreiber taten genau das. Das Abschalten war in den meisten Fällen eine Vorsichtsmaßnahme und kein Beleg für einen erfolgreichen Angriff.

In Deutschland nahm die Charité ihre Seiten komplett offline. Teile von berlin.de wurden deaktiviert, die Freie Universität Berlin schränkte ihre IT-Dienste ein, die Internetwache der Berliner Polizei war nicht erreichbar. Behördenseiten in Bayern und Niedersachsen fielen aus, ebenso Angebote der Städte Mainz, München und Dresden. International traf es unter anderem die Niederlande mit dem Identitätsdienst DigiD, dem Portal MijnOverheid und dem Hafen Rotterdam, dazu Regierungsdienste in Finnland, Frankreich und Tschechien sowie technische Dienste der Wikimedia Foundation. In Florida setzte der Dienstleister VR Systems Wahl-Informationsdienste aus, mitten in der Frühphase der US-Wahl. Das Ausmaß war so groß, dass das Ereignis in Deutschland bis in die Tagesschau reichte.

Vincent Schmalbach verglich die Lage mit früheren Großereignissen wie Heartbleed und Shellshock. Das vorsorgliche Abschalten könnte angesichts der aktuellen Flut KI-gestützt gefundener Schwachstellen zu einer gängigeren Verteidigungsmaßnahme werden.

Wie gefährlich ist die Lücke wirklich?

Hier gehen die Einschätzungen auseinander, und das ist für die Risikobewertung wichtig. Der Sicherheitsforscher Marcus Hutchins (MalwareTechBlog) wies am 23. Oktober 2026 darauf hin, dass sich die Lücke in der Praxis schwer ausnutzen lässt. Ein funktionierender Exploit muss auf die jeweilige PHP-Version, das Speicherlayout und das Worker-Verhalten des Ziels zugeschnitten sein. Die meisten der kursierenden Exploits auf GitHub und in sozialen Netzwerken funktionieren nicht. Viele sind mit KI zusammengeschrieben und verwechseln die Lücke mit einer alten Technik namens Session Poisoning, die mit den aktuellen CVEs nichts zu tun hat. Hutchins betont zugleich mit Nachdruck, dass ein Update zwingend ist. Die Lücke sei kein Spaß.

Dass eine Ausnutzung grundsätzlich möglich ist, steht außer Frage. Wiz Research entwickelte eigene Exploits und zeigte unauthentifizierte RCE gegen aktuelle Container-Images von WordPress, Drupal und Joomla. John Hultquist von der Google Threat Intelligence Group bestätigte am 23. Oktober 2026, dass validierte Proof-of-Concepts gegen Standard-Installationen von mod_php Code ausführen können, gegen PHP-FPM dagegen nicht. Eine breite Ausnutzung in freier Wildbahn war zu diesem Zeitpunkt nicht bestätigt, eine Ausnutzung in begrenztem Umfang aber nicht ausgeschlossen.

Erste reale Angriffe und Angriffsversuche gab es dennoch. Cloudflare-Chef Matthew Prince berichtete am 22. Oktober 2026 von Tausenden Ausnutzungsversuchen im Cloudflare-Netz schon in den zehn Stunden vor der offiziellen Veröffentlichung. In den 45 Minuten nach der Ankündigung stiegen sie auf Zehntausende, binnen zwei Stunden auf Hunderttausende und danach auf Millionen. Amazon gab an, Ausnutzung bereits vier Tage vor der Offenlegung im eigenen MadPot-Sensornetz gesehen zu haben, und sprach von breiter Ausnutzung. Die Zahlen zeigen vor allem Angriffsversuche, nicht erfolgreiche Übernahmen. Dass so viele Versuche vor der Veröffentlichung liefen, deutet auf einen vorzeitigen Leak der Informationen hin.

Eine Randnotiz zur Vorsicht bei Lageberichten: Palo Alto Networks (Unit 42) meldete zunächst eine Post-Compromise-Aktivität bei einer europäischen Behörde, zog diese Zuordnung zu php2shell am 25. Oktober 2026 aber wieder zurück. Der Erstzugang ließ sich nicht mit diesen CVEs in Verbindung bringen.

Patch-Fortschritt

Die gute Nachricht: Die Welt patcht. Censys zählte bis zum 25. Oktober 2026 rund 9,8 Millionen Dienste, die von einer verwundbaren auf eine gefixte Version wechselten. Die Updates kamen schnell. Debian, Ubuntu, Fedora, Red Hat, SUSE, Gentoo und Slackware lieferten bereits am Abend des 21. Oktober 2026 Pakete. Nach Zweigen betrachtet ist der neueste am weitesten. Von den PHP-8.5-Diensten waren 74,4 Prozent gefixt, bei 8.4 waren es 63,4 Prozent, bei 8.3 und 8.2 jeweils knapp die Hälfte. Ein Nachzieheffekt bleibt. Ein gepatchter Dienst erscheint erst als sicher, wenn er erneut gescannt wurde, die Statistik hinkt der Realität also einige Tage hinterher.

Verwundbare PHP-Versionen erkennen

Der erste Schritt ist eine Inventur. Erfassen Sie jede PHP-Installation, auch eingebettete in Appliances, NAS-Geräten, Routern, Control Panels und Docker-Images. Vergessen Sie Bastelserver und Raspberry-Pi-Geräte nicht, auf denen PHP oft als Abhängigkeit anderer Software läuft. Internetseitig erreichbare Hosts kommen zuerst dran.

Für die Suche von außen helfen mehrere Werkzeuge:

Shodan. Suchabfragen über den von PHP gesendeten Header grenzen betroffene Hosts ein, etwa:

http.component:"php"
"X-Powered-By: PHP"
"X-Powered-By: PHP/7.4.33"
"X-Powered-By: PHP/7.4"
"X-Powered-By: PHP/8."
"X-Powered-By: PHP/8.1" country:"xx"
http.component:"php" http.component_version:"7.4"

Ersetzen Sie xx durch das gewünschte Länderkürzel.

nmap. Der Sicherheitsforscher Florian Roth veröffentlichte am 21. Oktober 2026 eine Abfrage, die gängige und alternative Web-Ports prüft und die HTTP-Header nach der PHP-Version absucht:

nmap -sT -sV --version-light -T4 --max-retries 1 --open \
-p 80,81,443,8000-8010,8080-8090,8181,8443,8880,8888,9000,9001,9080,9090,9443 \
--script http-headers --script-timeout 10s \
--script-args 'http-headers.path=/index.php,http-headers.useget=true' 

Achten Sie auf X-Powered-By: PHP/.... Das ist eine schnelle Bestandsprüfung. Versteckte Installationen können durchrutschen, und ein Versionsbanner belegt noch keine Verwundbarkeit.

Spezialisierte Scanner. Mehrere Werkzeuge prüfen gezielt auf php2shell:

• Assetnote php2shell-scanner (CLI, github.com/assetnote/php2shell-scanner). Sendet präparierte Multipart-Anfragen und wertet Speicherfehler, leere HTTP-500-Antworten oder Worker-Abstürze als Signal. Das ist ein aktiver Test, der absichtlich Speicherfehler auslöst. Er kann das Ziel beeinträchtigen und erzeugt Fehlalarme. Setzen Sie ihn nur mit Berechtigung ein, vorzugsweise in einer Testumgebung.
• aancw php2shell-scanner (CLI, github.com/aancw/php2shell-scanner). Vergleicht die Version gegen die Fixreleases und kann im URL-Modus, über SSH oder lokal prüfen. Der Standardtest ist gutartig und schickt keinen Exploit-Code.
• ProjectDiscovery Nuclei-Template (CLI). Prüfung über die Nuclei-Template-Sammlung. Ob ein offizielles Template vorliegt, prüfen Sie vor dem Einsatz direkt im ProjectDiscovery-Repository.
• SOCRadar php2shell Checker (online, socradar.io/free-tools/php2shell-checker). Liest die Version aus den Headern und gleicht sie gegen die Fixreleases ab. Versucht keine Ausnutzung.
• php2shell.site (online, Open Source, github.com/AbelLykens/php2shell-checker). Liest Header und Session-Cookie, schickt sieben harmlose Anfragen und bewertet im Browser.
• Syhunt php2shell-protection (Test-Kit). Prüft, ob eine Server-Regel Multipart-Anfragen wie vorgesehen abweist.

Lassen Sie sich von einer unbekannten gemeldeten Version nicht täuschen. Verrät PHP seine Version nicht, lässt sich ein sicherer Fall von einem verwundbaren nicht unterscheiden. Prüfen Sie kritische Befunde immer gegen die installierte Version und mögliche Backports des Herstellers.

Indikatoren für einen Angriff

Der Sicherheitsforscher Costin Raiu hat typische Spuren zusammengetragen. In den Logs zeigt sich oft eine kurze Abfolge. Zuerst eine Multipart-POST-Anfrage mit HTTP 500, kurz darauf eine weitere Multipart-POST mit HTTP 200. Der aussagekräftigste Eintrag im error.log lautet:

PHP Fatal error: Allowed memory size of 134217728 bytes exhausted
(tried to allocate 1048576 bytes) in Unknown on line 0

Weitere Hinweise sind Worker-Abstürze mit SIGSEGV (Exit-Signal 11), FastCGI-Abbrüche hinter dem Reverse Proxy sowie erreichte Worker-Grenzen (MaxRequestWorkers). Diese Meldungen deuten eher auf fehlgeschlagene Versuche hin. Ein erfolgreicher Angriff muss nicht abstürzen und hinterlässt möglicherweise keine solche Spur.

Der stärkste Hinweis auf eine erfolgreiche Übernahme sind untypische Kindprozesse eines PHP-Workers. Startet php-fpm, httpd, apache2 oder frankenphp plötzlich sh, bash, curl, wget, nc, python oder certutil.exe, ist das ein Alarmsignal. Ebenso Reconnaissance-Befehle direkt vom Webserver wie whoami, id oder uname -a.

An konkreten Netzwerk-Indikatoren nannte Raiu die honeypot-aktive IP 196.189.236[.]67 sowie eine von Amazon veröffentlichte Liste. Dazu zählen 103.216.220[.]92, 31.223.184[.]166, 37.19.200[.]5, 134.209.159[.]64, 103.114.163[.]188 und 95.217.98[.]37. Team Cymru pflegt zudem eine Liste von über 1000 an breiter Ausnutzung beteiligten IP-Adressen, die sich befristet in der Firewall sperren lässt. Prüfen Sie auf Hinweise eines Einbruchs rückwirkend ab etwa 15:00 Uhr UTC am 20. Oktober 2026 und sichern Sie vorher die Logs.

Maßnahmen

Die einzige vollständige Behebung ist das Update. Alles andere sind Übergangsmaßnahmen, die ein System nicht sicher machen.

Patchen und neu starten

Aktualisieren Sie auf PHP 8.5.12, 8.4.27, 8.3.36 oder 8.2.35, zuerst auf internetseitig erreichbaren Systemen. Entscheidend ist der zweite Schritt. Starten Sie danach alle PHP-Dienste neu. Ein aktualisiertes Paket auf der Platte wirkt nicht, solange der alte Prozess im Speicher weiterläuft. Starten Sie auch alle langlebigen PHP-Prozesse neu, etwa Queue-Worker und Scheduler. Bei PHP als Apache-Modul starten Sie Apache neu, bei Docker ziehen Sie das Basis-Image neu und bauen den Container.

Übergangsmaßnahmen gegen CVE-2026-109618

• memory_limit = -1 setzen, am besten über php_admin_value im FPM-Pool oder in der Apache-Konfiguration. Keine nachgelagerte Einstellung darf wieder ein endliches Limit setzen.
• post_max_size senken, auf 8M ohne Datei-Uploads oder 32M mit Uploads. upload_max_filesize muss darunter liegen.
• Größen- und Feldlimits am Webserver oder Proxy erzwingen.
• Als Verfügbarkeitsgrenze Container- oder cgroup-Limits nutzen. Verwenden Sie RLIMIT_AS oder RLIMIT_DATA nicht, da sie genau den verwundbaren Allokationsfehler auslösen können.

Übergangsmaßnahmen gegen CVE-2026-109619 und CVE-2026-115560

• session.upload_progress.enabled = 0 setzen und alle Worker neu starten. Die Einstellung gehört in die php.ini, den FPM-Pool oder die Serverkonfiguration, die vor dem Request-Parsing greift. ini_set() oder eine .user.ini greifen zu spät. Dieselbe Einstellung deckt beide CVEs ab. Wer sie bereits gesetzt hat, muss für CVE-2026-115560 nichts weiter tun.
• Nur auf PHP 8.5 zusätzlich fatal_error_backtraces = 0 setzen und die Worker neu starten. Das blockiert den bekannten Pfad über Fatal-Error-Backtraces.

Multipart-Anfragen am Webserver blockieren

Als weiterer Notbehelf lassen sich Multipart-Anfragen vor PHP abweisen, zum Beispiel per Regel in nginx, Apache, Caddy oder an der WAF. Das gilt für alle HTTP-Methoden, nicht nur POST, und gehört in jeden Server-Block, der an PHP weiterleitet. Diese Maßnahme hat Nebenwirkungen. Datei-Uploads funktionieren nicht mehr, und auch manche Formulare ohne Dateifeld senden Multipart und fallen aus. Entfernen Sie den Block nach dem Patch und testen Sie Ihre Formulare.

Was nicht schützt

Mehrere naheliegende Maßnahmen laufen ins Leere, weil der verwundbare Code vor dem Anwendungscode greift. Ein Wartungsmodus, Sicherheits-Plugins, Login-Prüfungen und auto_prepend_file-Konstruktionen helfen nicht. file_uploads = Off, kleine Upload-Limits und disable_functions schützen nicht, da PHP den Multipart-Body trotzdem parst. Eine WAF hilft nur, wenn der Server nicht direkt erreichbar ist. Fehler mit display_errors zu unterdrücken bringt ebenfalls nichts.

Bei Verdacht auf Kompromittierung

Isolieren Sie das System und sichern Sie die Web- und PHP-Logs, bevor Sie Prozesse neu starten. Ein Neustart zerstört flüchtige Speicherdaten, die für eine Analyse wertvoll sind. Suchen Sie nach neuen oder geänderten Dateien im Webroot, nach Webshells, neuen Cronjobs, geplanten Tasks, neuen SSH-Schlüsseln und neuen Konten. Rotieren Sie alle Secrets, auf die der PHP-Benutzer zugreifen konnte, darunter Datenbankpasswörter, API-Schlüssel und App-Keys.

Fazit

php2shell trifft einen Grundbaustein des Webs und betrifft damit fast jeden, der eine Webseite betreibt. Die gute Nachricht ist, dass eine zuverlässige Ausnutzung schwieriger ist, als die erste Panik vermuten ließ, und dass viele kursierende Exploits nicht funktionieren. Die schlechte Nachricht ist, dass funktionierende Exploits existieren, dass Angriffsversuche millionenfach laufen und dass KI die Zeit bis zum fertigen Exploit weiter verkürzt. Für Verantwortliche in der Informationssicherheit bleibt die Reihenfolge klar. Es gilt, den Bestand zu erfassen, internetseitige Systeme zuerst zu patchen, danach jeden PHP-Dienst neu zu starten und erst dann die Übergangsmaßnahmen wieder abzubauen. Wer veraltete PHP-Versionen ohne Fix betreibt, sollte sie vom Netz trennen oder hinter eine WAF stellen, bis ein Upgrade möglich ist.