php2shell: was über die kritischen PHP-Lücken feststeht

Stand: 21. Oktober 2026, 9 Uhr deutscher Zeit. Das Security-Release ist zu diesem Zeitpunkt noch nicht erschienen.

Update 21. Oktober, 20:30 Uhr: Das Release ist erschienen. Was seitdem feststeht, steht am Ende des Artikels.

Heute um 14:00 UTC, also 16:00 Uhr deutscher Zeit, veröffentlicht das PHP-Team ein Security-Release für zwei kritische Schwachstellen. Beide sind mit CVSS v4.0 9.2 bewertet. Unter dem Namen „php2shell“ kursieren seit gestern Screenshots, Behauptungen und Vermutungen.

Vieles davon ist nicht belegt. Dieser Artikel trennt, was die Primärquellen sagen, von dem, was einzelne Personen behaupten. Und er beschreibt, was ich bis zum Release vorbereite, damit das Update heute Nachmittag eine Sache von Minuten ist.

Was offiziell feststeht

Am 20. Oktober um 19:33 UTC hat das PHP-Sicherheitsteam auf der Mailingliste php.announce und auf php.net eine Vorabmeldung veröffentlicht. Sie sagt genau fünf Dinge:

• Ein Security-Release behebt zwei kritische Schwachstellen, beide mit CVSS v4.0 9.2 bewertet.
• Es erscheint am Mittwoch, 21. Oktober 2026, um 14:00 UTC.
• Alle PHP-Nutzer sollen sich jetzt vorbereiten, um sofort aktualisieren zu können.
• Das Team behält sich vor, früher zu veröffentlichen, falls Details öffentlich werden oder aktive Ausnutzung beobachtet wird.
• Alle Details, die betroffenen und die behobenen Versionen werden erst mit dem Release veröffentlicht.

Die CVE-Nummern stehen nicht in dieser Meldung. Sie stammen aus dem Advisory 2026-018 von CERT-EU, dem Cyber-Notfallteam der EU-Institutionen: CVE-2026-109618 und CVE-2026-109619. CERT-EU schreibt ausdrücklich, dass keine technischen Details vorliegen. Die Bewertung von 9.2 deute auf eine möglicherweise ohne Anmeldung ausnutzbare Codeausführung aus der Ferne hin. Betroffen sein könnten alle Versionen ab PHP 5; als Beleg dafür nennt CERT-EU einen Beitrag auf Mastodon, keine Angabe des PHP-Teams.

Die Empfehlung von CERT-EU: PHP-Anwendungen identifizieren, sofortiges Patchen vorbereiten und, wo das nicht möglich ist, aus dem Internet erreichbare Anwendungen vom öffentlichen Netz trennen, bis der Fix eingespielt ist.

Wie es zum Leak kam

Die Lücken standen unter Embargo. Die Reihenfolge, soweit sie sich aus den Quellen belegen lässt, alle Zeiten in UTC:

Der Donnerstag wäre der 22. Oktober gewesen, 11 Uhr Ostküstenzeit entspricht 15:00 UTC. Das Release kommt damit 25 Stunden vor dem Termin, den watchTowr nennt.

Was behauptet, aber nicht bestätigt ist

Drei Angaben tauchen in fast jedem Bericht auf. Keine davon hat das PHP-Team bestätigt.

Ein fertiges Exploit-Werkzeug. Laut Sansec ist zusammen mit den Informationen ein Screenshot eines Werkzeugs namens „PHP2Shell“ aufgetaucht, das einer Gruppe namens Calif.IO zugeschrieben wird. Sein Banner behauptet, es funktioniere gegen jede PHP-Version ab 5.4.0. Das ist die Aussage eines Banners, keine Versionsliste.

Die Ursache im Session-Upload-Fortschritt. Ein Nutzer mit dem Namen J4ck3LSyN behauptet auf X, beide Lücken nachgebaut und getestet zu haben. Nach seiner Darstellung handelt es sich um zwei Heap-Use-after-free-Fehler im Handler für session.upload_progress, in der Funktion php_session_rfc1867_callback in ext/session/session.c. Belege dafür hat er nicht veröffentlicht.

Massenangriffe in Minuten. Sansec erwartet Massenangriffe innerhalb von 15 Minuten nach dem Release. Das ist eine Erwartung, keine Beobachtung. Sie ist plausibel, weil Angreifer aus einem veröffentlichten Patch rekonstruieren können, was er schließt.

Warum kein Framework-Update hilft

Die Lücken liegen nach allen bisherigen Angaben im PHP-Interpreter selbst, nicht in einer Bibliothek. Das ändert, wer handeln muss.

Ein composer update schließt sie nicht, und ein aktuelles Laravel, Symfony oder WordPress auch nicht. Sansec formuliert es für Shopsysteme deutlich: Der Fix muss auf Infrastrukturebene passieren, durch ein Update von PHP auf dem Server. Auch die eigene Anwendungs-Firewall von Sansec, Shield, greift nach deren Einschätzung zu spät, weil der Angriff PHP trifft, bevor der Code des Shops läuft.

Wer seine Server oder Container selbst betreibt, ist also heute selbst dran. Wer PHP beim Hoster bezieht, muss dort nachfragen.

Welche PHP-Versionen einen Fix erwarten können

Welche Versionen betroffen und welche behoben sind, steht erst im Release. Fest steht, welche Zweige das PHP-Projekt heute noch mit Sicherheitsupdates versorgt:

Die rechte Spalte ist wichtig: Wer heute Vormittag auf einer dieser Versionen steht, ist auf dem neuesten Stand und trotzdem nicht geschützt. Nach dem Release zählt nur noch die Versionsnummer, die in der offiziellen Meldung steht.

PHP 8.1 und älter bekommen vom PHP-Projekt keine Sicherheitsupdates mehr. Ob es für diese Versionen einen Fix gibt, hängt an Ihrer Linux-Distribution oder Ihrem Anbieter, sofern sie zurückportierte Pakete pflegen. Das sollten Sie heute erfragen, nicht morgen.

PHP 8.2 fällt Ende Dezember aus dieser Liste. Wer dort steht, bekommt heute noch einen Fix, beim nächsten Mal nicht mehr: PHP 8.2 endet am 31. Dezember.

Was ich bis 16 Uhr vorbereite

Bis zum Release lässt sich nichts patchen. Aber fast alles, was den Patch heute Nachmittag langsam macht, lässt sich jetzt erledigen.

1. Jede PHP-Installation finden. Nicht im Repository, sondern auf jeder Umgebung: Webserver, Worker, Cron-Server, CI-Runner, Container-Images. Die Version der Kommandozeile muss nicht die von PHP-FPM sein, beide prüfen.

php -v
php-fpm -v   # je nach Distribution z. B. php-fpm8.4 -v
grep -rn "^FROM php:" --include=Dockerfile* .

2. Den Weg zum Update klären. Bei offiziellen Docker-Images heißt Patchen: neues Basis-Image ziehen, neu bauen, ausrollen. Ein Tag wie php:8.4-fpm zeigt erst dann auf die neue Version, wenn die Maintainer das Image neu gebaut haben. Bei Systempaketen kommt der Fix über die Paketquelle, bei Managed Hosting über den Anbieter. Für jede Umgebung sollte heute Mittag feststehen, wer das Update auslöst.

3. Die Pipeline prüfen, solange es ruhig ist. Läuft der Build gerade grün? Kann jemand heute Nachmittag ausrollen und hat die Rechte dafür? Ein roter Build, der seit Tagen liegen bleibt, ist heute das eigentliche Risiko.

4. Den Hoster fragen. Wann spielt er das Release ein, und was passiert mit PHP-Versionen, die das PHP-Projekt nicht mehr pflegt?

5. Einen Plan für das, was nicht rechtzeitig gepatcht werden kann. CERT-EU empfiehlt dafür, aus dem Internet erreichbare Anwendungen vom öffentlichen Netz zu trennen, bis der Fix eingespielt ist. Das ist unbequem, aber es ist die Empfehlung, die vorliegt.

Eine Übergangsmaßnahme, die auf einer unbestätigten Annahme beruht. Falls die Behauptung zum Session-Upload-Fortschritt stimmt, schließt das Abschalten dieser Funktion den Angriffsweg. Ob sie stimmt, weiß heute niemand außerhalb des PHP-Teams. Die Einstellung ist laut PHP-Handbuch standardmäßig aktiv und lässt sich in der php.ini, in der Pool-Konfiguration von PHP-FPM oder per .user.ini setzen, nicht aber per ini_set():

session.upload_progress.enabled = Off

Danach PHP-FPM neu laden. Kosten hat das nur, wenn Ihre Anwendung den Fortschritt eines Uploads über die Session abfragt. Prüfen Sie die Wirkung über den Webserver, denn php -i auf der Kommandozeile zeigt die Konfiguration der CLI. Diese Maßnahme ersetzt das Update nicht, sie überbrückt höchstens die Stunden bis dahin.

Nach dem Release: die offizielle Meldung lesen, die behobenen Versionen mit der eigenen Liste abgleichen, aktualisieren, auf jeder Umgebung die Version erneut prüfen. Und in den Tagen danach im Blick behalten, ob PHP-Prozesse Programme starten, die dort nichts zu suchen haben, etwa eine Shell oder curl. Ein Gesamtbild dazu, wo ein altes PHP-System sonst noch offen ist, steht in Zehn Lücken, die in jedem alten PHP-System stecken.

Häufige Fragen

Mein Framework und alle Pakete sind aktuell. Bin ich sicher? Nein, nicht deswegen. Entscheidend ist die PHP-Version auf dem Server, nicht der Stand Ihres Codes.

Ich nutze PHP 7.4. Was jetzt? Das PHP-Projekt pflegt 7.4 seit Ende 2022 nicht mehr. Fragen Sie Ihre Distribution oder Ihren Anbieter nach einem zurückportierten Fix, und planen Sie den Umstieg auf einen gepflegten Zweig, statt auf den nächsten Fall zu warten. Was dieser Sprung auslöst, steht in PHP 7.4 auf PHP 8.4.

Gibt es schon Angriffe? Das PHP-Team hat sich vorbehalten, bei beobachteter Ausnutzung früher zu veröffentlichen. Bis zum Stand dieses Artikels hat es das nicht getan.

Was ist mit CVSS v4.0 9.2 gemeint? Eine Bewertung der Schwere auf einer Skala bis 10. Werte ab 9.0 gelten als kritisch. Was genau dahinter steckt, veröffentlicht das PHP-Team erst mit dem Release.

Quellen

• PHP: Upcoming Critical PHP Security Release (php.net, 20.10.2026)
• Dieselbe Meldung auf der Mailingliste php.announce
• CERT-EU: Security Advisory 2026-018, Critical Vulnerabilities in PHP
• Sansec: Critical PHP RCE, CVE-2026-109618 and CVE-2026-109619
• Kevin Beaumont auf Mastodon
• watchTowr auf X
• J4ck3LSyN auf X (unbestätigte Behauptung)
• php.net: Supported Versions
• PHP-Handbuch: Laufzeit-Konfiguration der Sessions

Wer seine Versionen nicht nur heute, sondern laufend im Blick haben will, braucht ein Patch-Management, das nicht erst bei einem Leak anspringt.

Heute zählt nicht, wie gut Ihr Code ist. Heute zählt, wie schnell Sie PHP austauschen können.

Update: was seit dem Release feststeht

Stand: 21. Oktober 2026, 20:30 Uhr deutscher Zeit. Alle Zeiten in UTC.

Die behobenen Versionen

Das PHP-Team hat PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Die beiden Advisories auf GitHub tragen den Zeitstempel 13:34. Betroffen ist laut Advisory jede Version unterhalb dieser vier. Für PHP 7.4, 8.0 und 8.1 hat das Sicherheitsteam minimale Backports als Quellcode bereitgestellt, offizielle Releases gibt es für diese Zweige nicht.

Was die Lücken sind

Beide sind mit CVSS v4.0 9.2 bewertet, Vektor AV:N/AC:H/AT:P/PR:N/UI:N: über das Netz, ohne Anmeldung und ohne Mitwirkung eines Nutzers, mit hoher Angriffskomplexität. Betroffen sind laut php.net alle PHP-Installationen, die Webanfragen bedienen: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Team bei mod_php, weil dort eine einzige Anfrage ohne Anmeldung den Angriff auslöst, bevor Anwendungscode läuft. Beide Advisories nennen das Update als einzige vollständige Abhilfe.

Was aus den Behauptungen geworden ist

• Session-Upload-Fortschritt: teilweise bestätigt. Das Advisory zu CVE-2026-109619 nennt Wege über den Session-Lebenszyklus, und php.net empfiehlt als Übergang session.upload_progress.enabled=0. Die konkrete Funktion, die J4ck3LSyN genannt hat, steht in keiner offiziellen Quelle.
• Alle Versionen ab 5.4.0: nicht bestätigt. Fest steht: Das PHP-Team hat Backports bis 7.4 veröffentlicht, und Ubuntu hat über Ubuntu Pro korrigierte Pakete bis hinunter zu PHP 5.5.9 (Ubuntu 14.04) ausgeliefert.
• CVSS 10.0: falsch. Laut PHP Foundation kursierten die CVE-Nummern ab etwa 15:00 am 20. Oktober mit einer falschen Bewertung von 10.0 und einer falschen Release-Zeit. Die offizielle Bewertung ist 9.2.
• Massenangriffe in 15 Minuten: nicht belegt. Siehe den nächsten Abschnitt.

Angriffe

Das PHP-Sicherheitsteam hat nach eigener Angabe unter den geleakten Proof-of-Concepts zum Zeitpunkt des Releases keinen funktionierenden Exploit gefunden. Ein bestätigter Einbruch in einen konkreten Server ist bis zum Stand dieses Updates nicht berichtet. Im KEV-Katalog der CISA, Stand 14:04, stehen beide CVEs nicht.

Wie das Embargo gebrochen wurde

Die PHP Foundation hat den Ablauf am Tag des Releases veröffentlicht:

• Erste Hinweise auf das Speicherproblem fand ein Core-Entwickler 2024 während eines Audits durch Quarkslab. Einen konkreten Angriffsweg fand man damals nicht.
• Am 11. August 2026 meldeten Calif und OpenAI unabhängig voneinander eine Codeausführung mit derselben Ursache, am 24. August Wiz, am 18. September OpenAI weitere Angriffswege.
• Nach dem Leak der CVE-Nummern zog das Team den Release vom 22. auf den 21. Oktober vor. Technische Details waren mit dem Leak nicht öffentlich geworden.
• Gegen 20:00 am 20. Oktober veröffentlichte Calif versehentlich ein Video seines Proof-of-Concepts. Laut Foundation hat es die Entwicklung weiterer PoCs beschleunigt.
• Am 21. Oktober um 07:41 veröffentlichte Chainguard Images mit dem Fix, vor dem abgestimmten Release. Damit ließ sich der Patch studieren, bevor andere aktualisieren konnten.

Die Foundation nennt die Verzögerung bei der Behebung „a structural failure“, verursacht durch den Entscheidungsprozess des Sicherheitsteams und fehlende Ressourcen.

Pakete und Images

Ubuntu führt die Korrekturen unter USN-8948-1 und USN-8948-2. Die Versionsnummern der Distributionen sehen alt aus, enthalten aber den zurückportierten Fix. Maßgeblich ist das Changelog des Pakets mit den beiden CVE-Nummern, nicht die Ausgabe von php -v.

Übergangsmaßnahmen des PHP-Teams

Für den Fall, dass nicht sofort aktualisiert werden kann, nennt php.net diese Einstellungen. Sie verringern die Angriffsfläche, machen eine Installation laut PHP-Team aber nicht sicher:

• memory_limit=-1, nicht überschreibbar gesetzt, etwa per php_admin_value im FPM-Pool oder in der Apache-Konfiguration. Kein Ersatz durch RLIMIT_AS oder RLIMIT_DATA, beide können den Fehler gerade auslösen.
• Ein niedriges post_max_size: 8M ohne Uploads, 32M mit Uploads, upload_max_filesize darunter. Dazu Grenzen am Webserver oder Proxy für Anfragegröße, Feldanzahl, Multipart-Teile, Header und Verschachtelungstiefe.
• session.upload_progress.enabled=0 in php.ini, im FPM-Pool oder in der Serverkonfiguration, danach jeden Worker neu starten.
• Auf PHP 8.5 zusätzlich fatal_error_backtraces=0.
• Ungültige oder veraltete Einstellungen entfernen, die pro Anfrage Meldungen vor der Initialisierung erzeugen, und von außen auslösbare fatale Fehler und Zeitüberschreitungen beheben.

Korrektur zum Abschnitt „Was ich bis 16 Uhr vorbereite“: Dort steht, session.upload_progress.enabled lasse sich per .user.ini setzen. Laut php.net reicht das für diesen Zweck nicht: Weder ini_set() noch die .user.ini von FPM greifen früh genug. Die Einstellung gehört in php.ini, den FPM-Pool oder die Serverkonfiguration.

Quellen zum Update

• php.net: Security advisory, Critical remote code execution vulnerabilities, update now (21.10.2026)
• GHSA-w8hw-w9fx-j79w: RCE via OOM corruption (CVE-2026-109618)
• GHSA-6wmf-4rv5-p3rp: RCE via stale global state (CVE-2026-109619)
• PHP Foundation: Today’s PHP Security Release, and How We’re Strengthening PHP Security
• CERT-EU: Security Advisory 2026-018, Version 1.1
• watchTowr: CVE-2026-109619, PHP Remote Code Execution Exploited
• The Hacker News: PHP Issues Emergency Patches for Two Critical PHP2Shell RCE Flaws
• Dane Knecht (Cloudflare) auf X
• Sophos: Proof-of-concept exploit released for PHP vulnerabilities
• CISA: Known Exploited Vulnerabilities Catalog
• Debian Security Tracker: CVE-2026-109618
• Ubuntu: CVE-2026-109618
• AlmaLinux: php2shell, Patches in progress
• Docker Hub: offizielles PHP-Image