PHP2Shell: Die zwei kritischen PHP-Lücken erklärt

PHP2Shell ist der Spitzname für zwei Sicherheitslücken in PHP, der Programmiersprache, auf der WordPress, Drupal und viele andere Websites laufen. Sie werden als CVE-2026-109618 und CVE-2026-109619 geführt, und PHP hat beide am 21. Oktober 2026 behoben. PHP bewertet jede von ihnen mit 9.2 von 10 und sagt, dass ein Angreifer ohne Konto sie über das Internet ausnutzen kann.

Am 26. Oktober wurde die Lage ernster. An diesem Tag nahm die US-Behörde Cybersecurity and Infrastructure Security Agency (CISA) beide Lücken in ihren Katalog nachweislich ausgenutzter Fehler auf, wie Tenable berichtet. Zivile US-Bundesbehörden müssen sie bis zum 29. Oktober beheben.

Was PHP2Shell ist und wer es entdeckt hat

PHP2Shell ist ein Name für zwei getrennte Fehler. Wer ihn geprägt hat, wird unterschiedlich dargestellt. Laut der Insikt Group von Recorded Future hat Wiz Research die Lücken gefunden und benannt, in Zusammenarbeit mit der Sicherheitsfirma Calif und mit OpenAI. Tenable führt den Namen auf ein Video der Exploit-Kette zurück, das der Forscher Kirill Firsov geteilt hat. Firsov würdigte dabei LCFR von Calif.io.

Die PHP Foundation würdigte unter anderem Calif, OpenAI und Wiz. Calif und Wiz gaben beide an, bei der Forschung KI-Modelle eingesetzt zu haben. Laut Calif reicht der früheste betroffene Codepfad bis zu PHP 5.4.0 zurück, berichtet Tenable.

Wie die beiden Lücken funktionieren

Beide Fehler stecken im Code, den PHP zu Beginn und am Ende jeder Webanfrage ausführt. Dieser Code läuft, bevor der eigene Code einer Website, etwa ein WordPress-Plugin, überhaupt zum Zug kommt.

Ein Webserver hält einen Pool dauerhaft laufender PHP-Prozesse vor, die Worker heißen. Jeder Worker beantwortet eine Anfrage, räumt auf und übernimmt die nächste. Durch diese Wiederverwendung können Reste einer Anfrage die nächste beeinflussen.

CVE	Bezeichnung von PHP	Was schiefgeht
CVE-2026-109618	OOM-Korruption	PHP geht beim Aufbau der internen Daten einer Anfrage der Speicher aus. Der Aufräumschritt behandelt die halb aufgebauten Daten dann als gültig.
CVE-2026-109619	Veralteter globaler Zustand	Daten einer Anfrage verweisen weiter auf Speicher, der bereits freigegeben wurde. Die nächste Anfrage im selben Worker kann sie nutzen, bevor PHP sie zurücksetzt.

OOM steht für „out of memory“, also Speichermangel. Bei beiden Lücken geht es um das, was Programmierer einen Use-after-free-Fehler nennen: Das Programm nutzt ein Stück Speicher weiter, nachdem es ihn zurückgegeben hat. Ein Angreifer, der steuert, was in diesem Speicher landet, kann das Programm lenken.

Laut Recorded Future gehört zu den Fehlern ein Use-after-free im Code, der Daten zum Session-Upload-Fortschritt liest. Das ist eine PHP-Funktion, mit der sich Datei-Uploads verfolgen lassen. Sie ist seit Version 5.4.0 Teil von PHP und standardmäßig aktiviert, berichtet Recorded Future unter Berufung auf Daten von VirusTotal. Ein verwandter Fehler gibt Speicherinhalte aus dem Worker preis. Laut Wiz kann das Passwörter, Login-Tokens, API-Schlüssel und Zertifikate aus den Anfragen anderer Personen offenlegen.

Wer von PHP2Shell betroffen ist

Laut PHP kann jede Installation betroffen sein, die Webanfragen bedient. PHP nennt PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das sind die wichtigsten Wege, auf denen ein Webserver PHP ausführt. Das höchste Risiko sieht PHP bei mod_php, das PHP direkt im Apache-Webserver ausführt. Dort kann eine einzige Anfrage ohne Anmeldung einen demonstrierten Exploit auslösen, bevor irgendein Anwendungscode läuft.

Ein Angriff funktioniert nicht überall. Laut der Sicherheitsfirma Field Effect hängt der Erfolg von PHP-Version, Betriebssystem, Webserver, Worker-Einstellungen und Speicherlayout ab. Der Angriff „scheint nicht in allen betroffenen Umgebungen gleichermaßen zuverlässig zu sein“, schrieb die Firma.

Trotzdem haben Forscher vollständige Übernahmen beliebter Anwendungen gezeigt. Laut Tenable bestätigte Calif Codeausführung ohne Anmeldung auf bestimmten Versionen von WordPress, Drupal, Joomla und Magento. Trail of Bits erlangte Shells, also Kontrolle über die Kommandozeile des Servers, auf MediaWiki, Symfony, Laravel und phpBB.

PHP steckt auch in Produkten, die man nicht mit PHP verbindet. Field Effect zählt Palo Alto Networks, Citrix, F5, HPE, NetApp, QNAP und Trend Micro zu den Herstellern mit betroffenen Produkten. Help Net Security berichtete am 22. Oktober, dass laut Palo Alto jede Version seiner Software PAN-OS und Panorama betroffen ist. Ein korrigiertes Release gab es demnach noch nicht.

Tenable verweist auf eine Shodan-Suche von Henk Poley, die mehr als 1,9 Millionen aus dem Internet erreichbare Hosts mit PHP findet. Dass ein Server PHP ausführt, macht ihn allein noch nicht angreifbar.

Was sich wann geändert hat

Datum (2026)	Ereignis
19. August	Wiz findet die erste Lücke mit KI-gestützten Forschungswerkzeugen
24. August	Wiz meldet die Lücken vertraulich an das Sicherheitsteam von PHP
21. September	PHP bestätigt die Meldung und beginnt mit den Korrekturen
17. Oktober	Die Köderserver von Amazon protokollieren einen Exploit-Versuch
20. Oktober	PHP kündigt ein Notfall-Release für den nächsten Tag an
21. Oktober	Details sickern online durch, Stunden bevor PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht
23. Oktober	PHP legt CVE-2026-115560 offen, eine separate Lücke beim Upload-Fortschritt
26. Oktober	Trail of Bits meldet funktionierende Exploits; die CISA führt beide Lücken als ausgenutzt

PHP hatte das Release laut PHP Foundation für den 22. Oktober geplant und es nach dem Leak vorgezogen. Wir haben zeitnah über die Vorankündigung und danach über das Release vom 21. Oktober berichtet. Amazon gab später an, dass seine Honeypots, also Köderserver, die Angreifer anlocken sollen, einen Versuch vier Tage vor der Offenlegung erfasst haben. Wie der Angreifer vorab an die Details kam, weiß Amazon nicht.

Beim Release erklärte die PHP Foundation, sie habe unter dem online kursierenden Code „keine funktionsfähigen Exploits identifiziert“. Das änderte sich binnen weniger Tage. Laut Tenable wurden am 24. Oktober die Honeypots eines Forschers ausgenutzt, auf denen PHP 8.4.26 lief. Trail of Bits hatte bis zum 26. Oktober funktionierende Exploits gegen PHP 8.2 bis 8.5. Recorded Future warnt dennoch, dass „die verfügbaren Berichte das volle Ausmaß erfolgreicher Ausnutzung oder bestätigter Kompromittierungen nicht belegen“.

Die Lücke vom 23. Oktober ist ein separates Problem, das die Releases vom 21. Oktober nicht beheben. PHP nennt sie „einen unwahrscheinlichen Vektor für Remote-Code-Ausführung im Session-Upload-Fortschritt“. Laut Field Effect betrifft sie Anwendungen, die session.serialize_handler zur Laufzeit ändern, bevor sie session_start() aufrufen, und bei denen der Upload-Fortschritt aktiviert ist.

Was das für Entwickler bedeutet

Ein Update ist die einzige vollständige Lösung. Alles andere verschafft nur Zeit.

• Aktualisieren Sie und starten Sie danach jeden Worker neu. Die korrigierten Releases sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Tenable weist darauf hin, dass ein neues Paket bereits laufende Prozesse nicht patcht. Laut Calif bleibt der alte Code bis zu einem Neustart im Speicher.
• Sichern Sie zuerst den Speicher, wenn ein Server sondiert wurde. Die Empfehlungen von Google Cloud, verfasst gemeinsam mit Mandiant, sehen vor, den Speicher der Worker vor dem Neustart zu erfassen. Ein Neustart vernichtet die Beweise.
• Behandeln Sie Konfigurationsänderungen als Notlösung. PHPs vorläufige Abhilfe für die erste Lücke ist memory_limit=-1, so gesetzt, dass Anwendungen es nicht überschreiben können. Für die zweite ist es session.upload_progress.enabled=0, auf PHP 8.5 zusätzlich fatal_error_backtraces=0.
• Prüfen Sie Session-Code auf CVE-2026-115560. Wenn eine Anwendung session.serialize_handler vor session_start() ändert, schalten Sie den Upload-Fortschritt bis zum nächsten regulären Release von PHP ab.
• Achten Sie auf SimpleXML-Abstürze. Tenable meldet eine Regression in 8.4.27 und 8.5.12, php-src-Issue #24488, die einige SimpleXML-Anwendungen zum Absturz bringen kann. Eine Korrektur wurde gemergt, war aber mit Stand 26. Oktober noch nicht veröffentlicht.
• Schauen Sie über Ihre eigenen Server hinaus. Firewalls, Speichergeräte und Sicherheitstools können PHP mitbringen, lesen Sie also die Advisory jedes Herstellers. Prüfen Sie die Logs bis zurück zum 17. Oktober.
• Planen Sie ein Upgrade, wenn Sie PHP 7.4 bis 8.1 nutzen. Diese Branches erhalten nur minimale Quellcode-Patches, kein offizielles Release. Fragen Sie Ihre Distribution oder Ihren Support-Anbieter nach einem Backport.