PHP2Shell: Kritische Lücken im PHP-Kern. Jetzt patchen.

Update-Box: Stand 23.10.2026. Neu seit der ersten Fassung: aktive Ausnutzung, BSI-Warnung, gefixte Versionsnummern, Hinweise zur Erkennung. Wir aktualisieren diesen Beitrag laufend.

Das Wichtigste in Kürze

Zwei Lücken im PHP-Kern: CVE-2026-109618 und CVE-2026-109619, beide CVSS 9.2.
Folgen: Codeausführung ohne Login und Auslesen von Speicherinhalten wie Passwörtern, Tokens und API-Keys.
Die Lücken werden aktiv ausgenutzt. Der erste bekannte Angriffsversuch stammt vom 17.10.
Gefixt in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter gibt es kein offizielles Update.
Das BSI rät: sofort patchen, notfalls den Webserver vom Netz nehmen.

Was ist passiert?

Wiz Research hat mehrere Speicherfehler im Kern von PHP gefunden. Bricht PHP eine Anfrage wegen eines Speicherfehlers ab, bleibt ein beschädigter interner Zustand zurück, den eine spätere Anfrage wiederverwenden kann. Wiz hat damit Codeausführung ohne Login auf aktuellen Installationen von WordPress, Drupal und Joomla demonstriert. Die Anwendung spielt dabei keine Rolle: Die Anfrage wird verarbeitet, bevor eure Anwendung überhaupt läuft.

Der zeitliche Ablauf zeigt, wie eng es geworden ist:

Datum	Was passiert ist
17.10.	Amazon beobachtet einen ersten Angriffsversuch in seinen Honeypots, vier Tage vor der Veröffentlichung.
21.10., früh	Details sind durchgesickert, erste Proof-of-Concept-Exploits tauchen auf. Weitere Angriffsversuche folgen.
21.10., 16 Uhr	PHP veröffentlicht die Updates, Wiz die Details. Das BSI gibt eine Warnung der Stufe 3/Orange heraus.
21. und 22.10.	Mehrere Sicherheitsfirmen, darunter Amazon und watchTowr, melden Ausnutzung in der Breite.

Wer ist betroffen?

Jede Organisation, die PHP auf aus dem Internet erreichbaren Systemen betreibt, egal in welcher Form: PHP-FPM, Apache mit mod_php, php-cgi, LiteSpeed oder FrankenPHP. Typisch sind:

Websites und Shops auf WordPress, Drupal, Joomla, TYPO3 oder anderen PHP-basierten Systemen
Kundenportale, Intranets und interne Tools auf PHP-Basis
Gehostete Websites, bei denen der Hoster PHP bereitstellt

Welche Versionen sind sicher?

PHP-Version	Status	Was zu tun ist
8.5	unterstützt	auf 8.5.12 aktualisieren
8.4	unterstützt	auf 8.4.27 aktualisieren
8.3	unterstützt	auf 8.3.36 aktualisieren
8.2	unterstützt	auf 8.2.35 aktualisieren
8.1, 8.0, 7.4	End of Life	kein offizielles Release, nur minimale Source-Patches
7.3 und älter	End of Life	kein Fix von PHP

Wichtig: Linux-Distributionen liefern den Fix teils unter eigenen Versionsnummern. Prüft deshalb die Hinweise eures Distributors.

Was ihr jetzt tun solltet

PHP aktualisieren und danach PHP-FPM bzw. den Webserver neu starten. Sonst läuft weiter der alte Interpreter.
Die richtige Version prüfen. php -v zeigt die Version auf der Kommandozeile. Die Version, die eure Website ausliefert, kann eine andere sein.
Hoster fragen. Bei gehosteten Websites aktiv nachhaken, ob das Update eingespielt und PHP neu gestartet wurde.
Zeit kaufen, wo nötig. WAF-Regeln, etwa von Cloudflare, Akamai oder AWS, senken das Risiko, ersetzen aber das Update nicht. Auch die kursierende Konfig-Änderung session.upload_progress.enabled=0 schützt nicht vollständig.
Secrets rotieren. Für Systeme, die vor dem Patch aus dem Internet erreichbar waren: Passwörter, Tokens und API-Keys erneuern.

Wenn ihr PHP 8.1 oder älter betreibt

Das ist der eigentliche Haken. Viele gewachsene Anwendungen laufen noch auf 7.4, 8.0 oder 8.1, und ein Upgrade auf 8.2 bricht oft Code, Abhängigkeiten und Treiber. Das ist kein Projekt für heute Nachmittag. Trotzdem gilt:

Backport prüfen: Liefert euer Linux-Distributor einen eigenen Fix für eure Version?
Exposition senken: Wenn nicht, die Anwendung vom Netz nehmen oder den Zugriff hart einschränken, zum Beispiel nur über VPN oder einen Reverse Proxy mit strengen Limits. Genau das rät auch das BSI.
Upgrade jetzt einplanen: Jede weitere Lücke in PHP trifft diese Systeme wieder ohne Fix.

Woran ihr einen Angriff erkennt

Hinweise aus unserer Detection-Praxis:

Ab dem 17.10. suchen, nicht ab dem Patch-Datum. Ein Angriff kann vor dem Patch stattgefunden haben.
Prozesse statt Signaturen: Payloads sind klein und variieren, bei mod_php läuft alles, bevor die Anwendung startet. Verlässlicher sind Webserver-Prozesse (Apache, php-fpm, lsphp), die eine Shell oder Tools wie curl und wget starten.
Speicherfehler: Memory-Limit-Fehler an Endpunkten, die sonst nie ans Limit kommen, und gehäufte HTTP-500-Antworten.
Session-Cookies: Ungewöhnlich große oder fehlerhafte PHPSESSID-Werte in Antworten. Eine der Lücken gibt darüber Speicherinhalte heraus, ohne Spuren auf dem Server. Deshalb: Secrets auch dann rotieren, wenn die Suche sauber ist.
Telemetrie prüfen: In vielen Umgebungen landen Prozessdaten von Webservern und PHP-Fehlerlogs gar nicht im SIEM. Dann lässt sich ein Angriff im Nachhinein kaum nachweisen.

Einordnung

Der fehlerhafte Code steckt seit über zehn Jahren in PHP. Ihn auszunutzen war lange zu aufwendig. Wiz hat die Lücke mithilfe von KI-Modellen gefunden und funktionierende Exploits in kurzer Zeit gebaut. Das können Angreifer jetzt auch. Unser Fazit: „Es gibt noch keinen öffentlichen Exploit“ taugt immer weniger als Grund, ein Update aufzuschieben.

Wo genau steckt PHP bei euch?

Das ist oft die schwierigste Frage, gerade in Cloud-Umgebungen mit vielen Containern und VMs. Gemeinsam mit Wiz, dem Team, das PHP2Shell entdeckt hat, bieten wir euch einen kostenlosen Schnellcheck an. Wiz scannt eure Cloud-Umgebung (AWS, Azure, GCP) ohne Installation und zeigt in wenigen Minuten alle betroffenen PHP-Workloads und welche davon aus dem Internet erreichbar sind. Dafür reicht ein Lesezugriff. Bei der Absicherung unterstützen wir euch direkt.

Interesse oder Fragen? Meldet euch.

Quellen