PHP2Shell: Was die kritischen PHP-Lücken vom Oktober 2026 bedeuten und was jetzt zu tun ist

Am 21. Oktober 2026 hat das PHP-Projekt außerhalb des normalen Zyklus vier Sicherheits-Releases veröffentlicht. Sie schließen zwei Lücken, die unter dem Namen „PHP2Shell” bekannt geworden sind und die das Projekt selbst mit CVSS 9.2 bewertet: Ein Angreifer kann damit ohne Anmeldung Code auf dem Server ausführen. Zwei Tage später folgte ein weiterer Hinweis zu einer dritten, verwandten Lücke, für die es noch keinen Patch gibt.

PHP steckt hinter einem großen Teil des Webs: WordPress, Shopware, TYPO3, Nextcloud, unzählige Eigenentwicklungen und viele fertige Werkzeuge, die als Container ausgeliefert werden. Entsprechend breit ist die Frage, wer etwas tun muss.

Stand: 23. Oktober 2026. Die Lage entwickelt sich noch; zur dritten Lücke ist das vollständige Advisory erst für das nächste reguläre Release angekündigt. Jede konkrete Aussage unten ist mit der verlinkten Quelle belegt. Prüfen Sie den aktuellen Stand, bevor Sie Maßnahmen ableiten.

Das Wichtigste in Kürze

• Betroffen ist jede PHP-Installation, die Webanfragen beantwortet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko sieht das PHP-Projekt bei mod_php.
• Behoben in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für 8.1 und älter gibt es vom PHP-Projekt keine Releases mehr, nur Quellcode-Backports.
• Angegriffen wird bereits. Amazon hat einen ersten Ausnutzungsversuch auf den 17. Oktober datiert, also vier Tage vor der Veröffentlichung.
• Neu seit dem 23. Oktober: CVE-2026-115560. Bis zum nächsten Release sollte session.upload_progress.enabled=0 gesetzt sein.
• Ein Update allein reicht nicht. Laufende PHP-Prozesse müssen neu gestartet, Container-Images neu gebaut werden.

Was passiert ist

Die Abfolge der Ereignisse ist ungewöhnlich und erklärt die Dringlichkeit:

Dass ein Angriffsversuch vor der Veröffentlichung beobachtet wurde, heißt: Mindestens ein Angreifer kannte die Lücke, bevor Betreiber reagieren konnten. Nach der Veröffentlichung ist das Muster das übliche. Laut The Hacker News, das sich auf Cloudflare beruft, stiegen die Angriffsversuche binnen eines Tages von Zehntausenden auf Millionen. Sicherheitsfirmen berichten von Versuchen, eine Variante des Mirai-Botnetzes zu installieren.

Die beiden Lücken, verständlich erklärt

Beide Fehler sitzen im PHP-Kern selbst, nicht in einer Anwendung. Das ist der entscheidende Unterschied zu den meisten Meldungen, die Sie aus dem WordPress-Umfeld kennen: Es hilft nichts, dass Ihr Shop-System aktuell ist, wenn der Interpreter darunter es nicht ist.

CVE-2026-109618 – Speicherkorruption bei Speichermangel. Wenn PHP beim Verarbeiten einer Anfrage der Speicher ausgeht, kann die Verarbeitung abbrechen, während interne Daten der Anfrage erst halb angelegt sind. Die Aufräumroutine behandelt diese halbfertigen Daten anschließend so, als wären sie gültig. Ein Angreifer kann das gezielt herbeiführen. Laut PHP-Projekt gibt es für mod_php einen demonstrierten Exploit, bei dem eine einzige Anfrage ohne Anmeldung reicht und der Angriff abläuft, bevor überhaupt Code der Anwendung ausgeführt wird. Ein Login, eine Web Application Firewall in der App oder eine Eingabeprüfung im eigenen Code greifen dann gar nicht erst.

CVE-2026-109619 – veralteter Zustand im Worker. Ein PHP-Prozess bearbeitet nacheinander viele Anfragen. Durch den Fehler kann interner Zustand einer Anfrage überleben, obwohl der zugehörige Speicher schon freigegeben ist. Eine spätere Anfrage an denselben Prozess greift dann auf diesen veralteten Zustand zu, bevor er zurückgesetzt wird. Bestätigte Wege dorthin führen über die Upload-Fortschrittsanzeige von Sessions und, nur in PHP 8.5, über Backtraces bei schweren Fehlern.

Die dritte Lücke: CVE-2026-115560

Am 23. Oktober hat das PHP-Projekt einen kurzen Hinweis nachgeschoben. Auch hier geht es um die Upload-Fortschrittsanzeige von Sessions, und auch hier ist Codeausführung möglich. Die Voraussetzungen sind aber eng. Alle drei müssen zusammenkommen:

1. In der Konfiguration ist session.serialize_handler auf php_binary oder php_serialize gesetzt.
2. Die Anwendung stellt den Wert zur Laufzeit per ini_set() auf php um, bevor sie session_start() aufruft.
3. Die Upload-Fortschrittsanzeige (session.upload_progress.enabled) ist eingeschaltet. Das ist der Standard.

Das PHP-Projekt hält diese Kombination in der Praxis für unwahrscheinlich und behebt die Lücke deshalb im regulären Zyklus. Es empfiehlt aber, bis dahin die Upload-Fortschrittsanzeige abzuschalten. Wer das schon für CVE-2026-109619 getan hat, muss nichts weiter tun.

Die Einstellung kostet in den meisten Fällen nichts. Sie betrifft nur Fortschrittsbalken beim Hochladen, die über PHP-Sessions abgefragt werden. Moderne Oberflächen messen den Fortschritt meist direkt im Browser.

Was jetzt zu tun ist

1. Alle PHP-Installationen finden

Der häufigste Fehler bei solchen Meldungen ist nicht das vergessene Update, sondern die vergessene Installation. PHP läuft oft dort, wo es niemand auf dem Zettel hat:

• auf dem Webserver der Firmenwebsite und auf dem Server des Shops,
• in fertigen Container-Images von Werkzeugen, die nebenbei betrieben werden: Wikis, Ticketsysteme, Paste-Dienste, Admin-Oberflächen,
• auf Staging-, Test- und Altsystemen, die „eigentlich” abgeschaltet werden sollten,
• bei Agenturen und Dienstleistern, die Ihre Website betreuen.

Bei Shared Hosting und Managed-Angeboten liegt das Update beim Anbieter. Fragen Sie trotzdem nach, und lassen Sie sich die Version nennen.

2. Die richtige Version prüfen

Auf vielen Linux-Systemen gibt es mehrere PHP-Binärdateien mit eigener Konfiguration: eine für die Kommandozeile, eine für PHP-FPM. Entscheidend ist die, die Webanfragen beantwortet:

php -v          # Kommandozeile
php-fpm8.3 -v   # FPM, Name je nach Distribution und Version

Achten Sie auf eine Besonderheit der Distributionen: Debian, Ubuntu, Red Hat und andere spielen Sicherheitsfixes oft zurück, ohne die Versionsnummer zu ändern. Eine „alte” Nummer kann also gepatcht sein und umgekehrt. Maßgeblich ist das Sicherheitshinweis-Verzeichnis Ihres Anbieters, nicht die Zahl hinter dem Punkt.

3. Aktualisieren und neu starten

Das Update ist die einzige vollständige Lösung. Das betont das PHP-Projekt ausdrücklich. Danach gilt:

• Alle PHP-Prozesse neu starten. PHP-FPM- und Apache-Worker laufen mit dem alten Code weiter, bis sie neu gestartet werden.
• Container neu bauen und neu ausrollen. Ein Neustart des alten Containers lädt das alte Image. Prüfen Sie nach dem Ausrollen im laufenden Container, welche Version dort tatsächlich antwortet.
• Versionen ab 8.1 abwärts bekommen vom PHP-Projekt keine Releases mehr. Entweder liefert Ihr Distributor oder ein LTS-Anbieter einen zurückgespielten Fix, oder es ist Zeit für den Umstieg. Auch PHP 8.2 erhält nach dem 31. Dezember 2026 keine Sicherheitsfixes mehr.

4. Die Upload-Fortschrittsanzeige abschalten

Setzen Sie in der php.ini oder in der Pool-Konfiguration von PHP-FPM:

session.upload_progress.enabled = 0

Drei Details machen den Unterschied:

• Die Einstellung muss vor dem Verarbeiten der Anfrage greifen. ini_set() im Anwendungscode oder eine .user.ini helfen nicht.
• Danach alle Worker neu starten.
• In der Web-Umgebung prüfen, nicht auf der Kommandozeile. Die Kommandozeile liest auf vielen Systemen eine andere php.ini. Verlässlich ist eine phpinfo()-Ausgabe, die über den Webserver aufgerufen und danach sofort wieder gelöscht wird.

Taucht die Einstellung dort gar nicht auf, ist das Session-Modul nicht geladen, und dieser Angriffsweg existiert auf dem System nicht. Die beiden Lücken vom 21. Oktober betrifft das nur teilweise: CVE-2026-109618 hat mit Sessions nichts zu tun. Aktualisiert werden muss also trotzdem.

Wie weit diese Einstellung trägt, sollten Sie realistisch einschätzen. Sie schließt bekannte Angriffswege, nicht die Fehler dahinter. Das PHP-Projekt sagt das für CVE-2026-109619 selbst: Die Einstellung blockiere die bestätigten Session-Pfade, „but not other variants”. Der eigentliche Fehler ist veralteter Zustand im Worker, die Upload-Fortschrittsanzeige ist nur ein bestätigter Weg dorthin. Gegen diese Lücke hilft deshalb allein das Update.

Bei CVE-2026-115560 spricht das PHP-Projekt zwar von vollständigem Schutz, gemeint ist aber dieser eine Angriffsweg. Nach unserer Einschätzung, die das Advisory nicht ausdrücklich bestätigt, folgen die Bedingungen einem seit Jahren bekannten Muster: Eine Session wird in einem anderen Format gelesen, als sie geschrieben wurde. Dann lassen sich über präparierte Session-Inhalte eigene Objekte einschleusen. Die Upload-Fortschrittsanzeige ist dabei nur der bequemste Kanal, um ohne Anmeldung eigene Daten in die Session zu bringen. Schreibt eine Anwendung an anderer Stelle Nutzereingaben in die Session und wechselt sie zugleich das Format zur Laufzeit, kann das Problem trotz Workaround bestehen bleiben.

Daraus folgen zwei Dinge:

• Den Format-Wechsel abstellen. Suchen Sie im eigenen Code und in Plugins nach ini_set('session.serialize_handler'. Eine Anwendung sollte ihre Sessions in genau dem Format lesen, in dem die Konfiguration sie schreibt. Das ist die eigentliche Ursache, nicht die Fortschrittsanzeige.
• Das nächste Release im Blick behalten. Erst mit dem regulären Bugfix-Release kommen das vollständige Advisory zu CVE-2026-115560 und der Fix. Dann gilt dasselbe wie am 21. Oktober: aktualisieren, Prozesse neu starten, Container neu bauen.

Nach drei Lücken in derselben Gegend innerhalb von zwei Tagen ist es zudem wahrscheinlich, dass sich Forscher diesen Teil von PHP gerade genau ansehen. Weitere Varianten wären keine Überraschung. Planen Sie das nächste PHP-Update deshalb so ein, dass es innerhalb von Stunden laufen kann, nicht erst nach Tagen.

5. Wenn das Update noch nicht möglich ist

Für Systeme, die sich nicht sofort aktualisieren lassen, nennt das PHP-Projekt Maßnahmen, die einzelne Angriffswege erschweren, eine Installation aber nicht sicher machen:

• memory_limit=-1, gesetzt so, dass die Anwendung es nicht überschreiben kann, etwa per php_admin_value im FPM-Pool.
• Ein niedriges post_max_size: 8M für Anwendungen ohne Datei-Uploads, 32M mit Uploads, upload_max_filesize jeweils darunter. Zusätzlich Größenbegrenzungen am Webserver oder Reverse Proxy.
• Auf PHP 8.5 zusätzlich fatal_error_backtraces=0.
• Speicherbegrenzung über Container oder cgroups, nicht über RLIMIT_AS oder RLIMIT_DATA. Letztere können genau den Fehler auslösen, der ausgenutzt wird.

Das ist Schadensbegrenzung für ein paar Tage, kein Ersatz für das Update.

6. Prüfen, ob schon etwas passiert ist

Weil Angriffe vor der Veröffentlichung begonnen haben, lohnt der Blick zurück. Hinweise in den Protokollen:

• PHP-Fehler „Allowed memory size … exhausted” mit dem Zusatz Unknown on line 0, also während der Initialisierung, nicht in Ihrem Code,
• abstürzende Webserver-Worker, bei Apache etwa die Meldung AH00052,
• POST-Anfragen mit dem Feldnamen PHP_SESSION_UPLOAD_PROGRESS in Formular-Uploads, auf die Amazon ausdrücklich hinweist,
• ungewöhnlich große Formularfelder mit Binärdaten.

Das stärkste Signal ist ein Webserver- oder PHP-Prozess, der eine Shell startet. Ein erfolgreicher Angriff muss weder einen Absturz noch einen Fehlerstatus hinterlassen. Wer hier fündig wird, sollte das System als kompromittiert behandeln: isolieren, Zugangsdaten auf dem System austauschen, sauber neu aufsetzen.

Was sich daraus lernen lässt

PHP2Shell ist kein Lehrstück über PHP, sondern über Bestandsführung. Die eigentliche Arbeit bei einer solchen Meldung besteht selten im Update selbst. Sie besteht in der Antwort auf zwei Fragen: Wo läuft das bei uns überall? Und woher wissen wir, dass das Update wirklich angekommen ist?

Wer darauf innerhalb einer Stunde eine belastbare Antwort hat, ist für die nächste Lücke dieser Art gut aufgestellt. Wer erst eine Inventur beginnen muss, verliert die Tage, in denen die Angreifer am aktivsten sind. Genau dieses Zeitfenster war diesmal schon vor der Veröffentlichung offen.

Wenn Sie nicht sicher sagen können, auf welchen Systemen in Ihrem Unternehmen PHP läuft und in welcher Version, ist das der eigentliche Befund. Ich unterstütze Unternehmen bei solchen Bestandsaufnahmen und bei der Absicherung von Webservern; die Formate stehen unter Assessments & Schulungen.

---

Quellen

• PHP-Projekt: News-Archiv 2026 (Ankündigung 20.10., Security Advisory und Releases 21.10., Informationshinweis zu CVE-2026-115560 vom 23.10.)
• PHP-Projekt: GitHub Security Advisory GHSA-w8hw-w9fx-j79w (CVE-2026-109618)
• PHP-Projekt: GitHub Security Advisory GHSA-6wmf-4rv5-p3rp (CVE-2026-109619)
• Amazon Web Services: Amazon threat intelligence identifies PHP2Shell exploitation prior to public disclosure in MadPot (21.10.2026)
• Datadog Security Labs: PHP2Shell, critical vulnerabilities in PHP: detection, analysis, and remediation (21.10.2026, aktualisiert 22.10.)
• The Hacker News: PHP Warns of Another Unpatched RCE Risk Two Days After Emergency PHP2Shell Patches (23.10.2026)
• CERT-EU: Security Advisory 2026-018