php2shell nach dem Patch: Angriffe, Exploits, Folgen

Stand: 24. Oktober 2026, 23 Uhr deutscher Zeit. Alle Uhrzeiten in UTC, sofern nicht anders angegeben.

Am 21. Oktober hat das PHP-Team die beiden kritischen Lücken CVE-2026-109618 und CVE-2026-109619 mit PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 geschlossen. Was vor und am Release-Tag feststand, steht in php2shell: was über die kritischen PHP-Lücken feststeht.

Dieser Artikel hält fest, was in den drei Tagen danach passiert ist. Er gibt nur wieder, was eine benannte Quelle sagt, und trennt Beobachtungen von Behauptungen. Wo sich Quellen widersprechen, stehen beide da.

Das Wichtigste in Kürze

• Es gibt sehr viele Angriffsversuche. Öffentlich bestätigt ist bis zu diesem Stand ein einziger erfolgreicher Angriff auf ein reales Ziel, berichtet von Palo Alto Networks Unit 42.
• Sophos meldete am 22. Oktober eine erfolgreiche Ausnutzung und nahm sie fünf Stunden später zurück.
• CISA, BSI und Rapid7 kennen keine bestätigte erfolgreiche Ausnutzung. Im KEV-Katalog der CISA stehen beide CVEs nicht.
• Die öffentlichen Exploits funktionieren laut Rapid7 und Sansec nur unter eng begrenzten Bedingungen, nicht gegen eine Standardinstallation.
• Am 23. Oktober hat das PHP-Team eine weitere Lücke angekündigt, CVE-2026-115560. Einen Patch gibt es noch nicht, die Übergangsmaßnahme ist dieselbe wie zuvor.
• Der Patch selbst hat Nebenwirkungen: Zu 8.5.12 und 8.4.27 sind mehrere mögliche Regressionen gemeldet, bestätigt ist noch keine.

Angriffe: viele Versuche, wenig Belegtes

Die Meldungen der Sicherheitsfirmen in zeitlicher Reihenfolge:

Der einzige berichtete Treffer. Laut Unit 42 hatten die Angreifer innerhalb von zwei Stunden nach der ersten Ausnutzung Passwort-Hashes und Secrets der Mehrfaktor-Anmeldung erbeutet, einen NTLM-Relay-Tunnel ins Active Directory aufgebaut und versucht, Domänen-Administrator zu werden. Die Ausgaben ihrer Erkundung waren mit Trennzeilen wie ==SHELLUSER== gegliedert, die Unit 42 als für ein KI-Modell gemacht deutet. Eine zweite, unabhängige Quelle für diesen Fall habe ich nicht gefunden.

Die Korrektur von Sophos. Am 22. Oktober um 16:18 schrieb Sophos von einer erfolgreichen Ausnutzung. Um 21:21 folgte der Satz „we are correcting that assessment“: Die Kundentelemetrie zeige Scans und eine kleine Zahl gescheiterter Versuche, es gebe keinen Beleg für eine erfolgreiche Kompromittierung durch diese Lücken. Wer in den Stunden dazwischen berichtet hat, hat die erste Fassung übernommen.

Zahlen ohne Nenner. Die Millionen von Cloudflare zählen Anfragen, die eine Regel ausgelöst haben, keine verwundbaren Server und keine Einbrüche. Cloudflare selbst nennt im Blog keine Zahl und schreibt nur, Angreifer hätten ihre Payloads verändert, um die Regeln zu umgehen. Unit 42 zählt über 22,6 Millionen erreichbare Instanzen, die „potentially vulnerable“ seien. Das ist eine Schätzung der Angriffsfläche, keine Zählung verwundbarer Systeme.

Was die Behörden sagen

Das BSI listet zudem Produkte, die PHP mitbringen und für die eigene Hinweise der Hersteller vorliegen, darunter F5, Citrix NetScaler, pfSense, QNAP, Synology und cPanel. Wer solche Geräte betreibt, ist vom Update des Herstellers abhängig, nicht vom PHP-Release.

Wie gut die öffentlichen Exploits sind

Auf GitHub sind seit dem 20. Oktober zahlreiche Repositories mit „php2shell“ im Namen entstanden. Was die Fachleute über ihre Wirksamkeit sagen:

• Rapid7: Jeder öffentliche Proof-of-Concept zeige Codeausführung nur für eine bestimmte Kombination aus Betriebssystem, PHP-Version und Webserver, und keiner scheine „broadly reliable“. Rapid7 selbst habe einen funktionierenden Exploit nur unter engen Laborbedingungen.
• Sansec: „The public exploits do not work against a default PHP installation.“
• Red Hat bewertet die Lücke abweichend als „Important“ mit CVSS 3.1 von 8.1. Begründung: RHEL setzt standardmäßig PHP-FPM ein, dessen Worker bei frühen Initialisierungsfehlern beendet werden, bevor sie die beschädigten Strukturen erreichen. Codeausführung sei dort „difficult in practice“.

Das deckt sich mit dem Advisory des PHP-Teams vom 21. Oktober, das einen vollständigen Exploit für mod_php bestätigt und für PHP-FPM bei CVE-2026-109618 ausdrücklich keinen. Rapid7 warnt zugleich, eine übertragbarere Technik könne jederzeit auftauchen.

Eine neue Lücke: CVE-2026-115560

Am 23. Oktober hat das PHP-Team auf php.net einen informativen Hinweis veröffentlicht. Er empfiehlt, session.upload_progress.enabled=0 bis zum nächsten regulären Bugfix-Release zu setzen, „to fully protect from an unlikely RCE vector“.

Die Lücke tritt laut PHP-Team nur auf, wenn alles davon zutrifft:

• Die Anwendung setzt session.serialize_handler in der Konfiguration auf php_binary oder php_serialize,
• stellt ihn zur Laufzeit mit ini_set() vor session_start() auf php um,
• und der Session-Upload-Fortschritt ist eingeschaltet.

Wer den Handler zur Laufzeit nie umstellt, kann die Funktion laut PHP-Team eingeschaltet lassen. Wer die Einstellung schon seit dem 21. Oktober als Übergangsmaßnahme gesetzt hat, muss nichts weiter tun. Ein vollständiges Advisory soll mit dem nächsten Release erscheinen; einen Termin dafür nennt das PHP-Team nicht. Ein Release 8.5.13 oder 8.4.28 gibt es bis zu diesem Stand nicht.

Im Issue-Tracker von PHP steht seit dem 24. Oktober der Vorschlag, session.upload_progress.enabled künftig standardmäßig auszuschalten (Issue #24648).

Was der Patch ändert und was er auslöst

Der Fix für CVE-2026-109618 („Avoid state corruption via bailout“) ändert, wie PHP auf Speichermangel reagiert. memory_limit löst den Fehler nicht mehr sofort aus, sondern verzögert. Neu ist die Einstellung memory_hard_limit_percent: Wird diese harte Grenze überschritten, beendet sich der Prozess mit dem Exit-Code 137, statt einen abfangbaren Fehler zu werfen.

Seit dem Release sind dazu im Issue-Tracker von PHP mehrere Fehler gemeldet. Alle stehen noch auf „Needs Triage“ oder sind ohne Status, keiner ist bestätigt:

Für den Betrieb heißt das: Wer nach dem Update Worker sieht, die mit Exit-Code 137 enden, sollte zuerst an die neue harte Grenze denken und nicht an einen Angriff.

Wer seine Pakete wann nachgezogen hat

Zwei Muster fallen auf. Erstens hat jede Plattform, die PHP für ihre Kunden betreibt, eine andere Antwort, von „schon erledigt“ bis „ziehen Sie um“. Zweitens hängt alles unterhalb von PHP 8.2 an Distributionen und Anbietern, die zurückportieren; das PHP-Projekt selbst hat für 7.4 bis 8.1 nur Quellcode-Backports bereitgestellt. Welche Wege es für diese Versionen gibt: php2shell auf PHP 7.4, 8.0 und 8.1. Für PHP 8.2 gilt das ab Januar ebenfalls: PHP 8.2 endet am 31. Dezember.

Der Streit um das Embargo

Die PHP Foundation hat in ihrem Beitrag zum Release drei Stellen benannt, an denen Informationen vor dem abgestimmten Termin nach außen gelangten. Am meisten Aufmerksamkeit hat der dritte Punkt bekommen:

• Die CVE-Nummern kursierten ab dem 20. Oktober gegen 15:00, mit falscher Bewertung und falscher Uhrzeit.
• Calif veröffentlichte gegen 20:00 versehentlich ein Video seines Proof-of-Concepts.
• Chainguard veröffentlichte am 21. Oktober um 07:41, „more than six hours before the coordinated release“, fertige Images mit dem Fix. Damit konnte jeder den Patch in Binärform studieren, während alle anderen noch warteten.

Chainguard-CEO Dan Lorenc begründete den Schritt laut TechTarget auf LinkedIn so: „This decision was based on how easily we were able to independently discover the vulnerability and build an exploit“. Ob er sich entschuldigt hat, berichten die Medien unterschiedlich. Laut TechTarget bedauerte er die zusätzliche Last für die Foundation und die Maintainer, laut The Register entschuldigte er sich nicht. Einen eigenen Beitrag von Chainguard dazu habe ich nicht gefunden.

Clint Gibler, Leiter der Cyber-Forschung bei OpenAI, schrieb laut TechTarget: „We were intending for the patch to go live Thursday, but a rumor/leak started Tuesday“. Die Foundation selbst nennt die monatelange Verzögerung bei der Behebung „a structural failure“ und kündigt an, Entscheidungen im Sicherheitsteam künftig per Mehrheit zu treffen.

Was die offiziellen Stellen jetzt empfehlen

Zusammengefasst aus PHP-Team, CISA, BSI und NCSC, ohne eigene Ergänzung:

1. Aktualisieren auf 8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder auf ein Paket der Distribution mit beiden CVE-Nummern im Changelog. Laut PHP-Team und BSI ist das der einzige vollständige Schutz.
2. session.upload_progress.enabled=0 gesetzt lassen bis zum nächsten Bugfix-Release, wegen CVE-2026-115560. Gesetzt in php.ini, im FPM-Pool oder in der Serverkonfiguration, nicht per ini_set() oder .user.ini.
3. Was nicht aktualisiert werden kann, vom Netz nehmen, ausdrücklich auch PHP 8.1 und älter (CISA).
4. Vor dem späten Update auf Kompromittierung prüfen, insbesondere auf Hintertüren (NCSC).
5. Geräte mit eingebautem PHP über die Hinweise ihrer Hersteller absichern (BSI, NCSC).

Häufige Fragen

Wird php2shell massenhaft ausgenutzt? Es gibt massenhaft Versuche. Eine bestätigte erfolgreiche Ausnutzung in der Breite kennen CISA, BSI und Rapid7 bis zu diesem Stand nicht. Öffentlich beschrieben ist ein erfolgreicher Angriff, von Unit 42.

Ich habe am 21. Oktober aktualisiert. Muss ich noch etwas tun? Wegen CVE-2026-115560 empfiehlt das PHP-Team, session.upload_progress.enabled=0 bis zum nächsten Release zu setzen. Betroffen ist nur, wer den Session-Serializer zur Laufzeit umstellt.

Ist der Patch unvollständig? Laut BSI wurden entsprechende Berichte widerlegt. Gemeldet sind Regressionen, also Fehler, die der Patch verursacht haben könnte, keine Umgehungen.

Warum steht php2shell nicht im KEV-Katalog der CISA? Aufgenommen wird nur, was nachweislich ausgenutzt wurde. Die CISA schreibt, sie habe keine erfolgreiche Ausnutzung beobachtet.

Quellen

• php.net: Informational advisory, Session upload progress (23.10.2026)
• php.net: Security advisory vom 21.10.2026
• PHP Foundation: Today’s PHP Security Release, and How We’re Strengthening PHP Security
• AWS Security Blog: PHP2Shell exploitation prior to public disclosure in MadPot
• Cloudflare: PHP vulnerabilities, WAF protection
• The Register: Hackers pile on PHP2Shell (22.10.2026)
• Sophos: Proof-of-concept exploit released for PHP vulnerabilities (mit Korrektur vom 22.10.)
• Unit 42: CVE-2026-109618 and CVE-2026-109619
• Rapid7: CVE-2026-109618 and CVE-2026-109619
• Sansec: Critical PHP RCE, CVE-2026-109618 and CVE-2026-109619
• CISA: Critical Vulnerabilities in PHP Require Immediate Patching
• CISA: Known Exploited Vulnerabilities Catalog
• BSI: Cybersicherheitswarnung 2026-297981-1232, Version 1.2 (PDF)
• CERT-EU: Security Advisory 2026-018
• NCSC: Critical security issue affecting PHP
• Red Hat: CVE-2026-109618
• Debian Security Tracker: CVE-2026-109618
• Ubuntu: CVE-2026-109618
• remirepo: PHP 8.2.35, 8.3.36, 8.4.27, 8.5.12
• FrankenPHP 1.13.2
• Laravel: PHP critical vulnerability response updates
• php-src #24492, #24493, #24497, #24631, #24648
• TechTarget: PHP2Shell disclosure unravels after leaks forced early patch drop
• The Register: PHP blames Chainguard (22.10.2026)

Wer seine Versionen laufend im Blick haben will und nicht erst beim nächsten Leak, braucht ein Patch-Management, das auch die Server und Images erfasst, nicht nur die Pakete im Repository.