PHP2Shell: Kritische PHP-Lücken, mod_php besonders gefährdet

Eigentlich sollte die Veröffentlichung am Donnerstag kommen. Nachdem Details zu zwei Lücken am Dienstag über Hacker News durchgesickert waren, zog das PHP-Team seine Sicherheitsupdates auf Mittwoch, 21. Oktober, 14 Uhr UTC vor. Behoben sind die Fehler in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Beide Lücken stecken im Interpreter selbst, nicht in einem CMS, und tragen laut den Sicherheitshinweisen von PHP zu CVE-2026-109618 und CVE-2026-109619 jeweils einen CVSS-4.0-Wert von 9,2. Bestätigt ist Codeausführung ohne Anmeldung mit den Rechten des Webserver-Prozesses.

Der Fehler steckt im Speicher-Handling

Der erste Fehler hängt an der Art, wie PHP auf Speichermangel reagiert. Bei einem Out-of-Memory springt der Interpreter per longjmp() aus dem laufenden Kontext, auch wenn Request-Speicher in diesem Moment nur halb initialisiert ist. Der Shutdown liest diesen Zustand danach als gültig. Den Speichermangel kann ein Angreifer mit einem Multipart-Request erzwingen, der unterhalb von post_max_size bleibt, etwa über unbegrenzt viele Header pro Teil, leere Datei-Felder, die nicht gegen max_file_uploads zählen, oder verschachtelte Feldnamen. Der Patch ersetzt longjmp() durch einen weichen OOM am nächsten sicheren Punkt der VM und einen harten Abbruch per _exit() oberhalb einer zweiten Schwelle.

Der zweite Fehler betrifft globalen Zustand, der einen Request überlebt. Bricht ein fataler Fehler eine Operation ab, bevor sie ihren Zustand zurücksetzt, zeigt ein globales Feld auf bereits freigegebenen Heap. Liest der nächste Request auf demselben Worker diesen Wert vor der normalen Initialisierung, entsteht ein Use-after-free. PHP nennt zwei bestätigte Wege: die fatal_error_backtraces von PHP 8.5 und Session Upload Progress, das ab Werk aktiv ist und kein session_start() in der Anwendung braucht.

Warum mod_php das größte Risiko trägt

Apache mit mod_php ruft den Request-Shutdown auch dann auf, wenn schon der Start des Requests gescheitert ist. Der Speichermangel beim automatischen Parsen des Bodys reicht damit, und keine Zeile Anwendungscode muss laufen. Gegen mod_php mit Standardwerten für Speicher und Eingaben hat PHP die Codeausführung vollständig nachgestellt. PHP-FPM beendet ein Kind, wenn dessen Start fehlschlägt, und entschärft so den direkten Weg. Für die zweite Lücke hat PHP trotzdem einen Exploit gegen einen normalen FPM-Pool bestätigt, der allerdings eine passende Operation in der Anwendung braucht. FrankenPHP gilt nach Quellcode-Analyse als ähnlich anfällig wie mod_php, LSAPI als bedingt. Die hohe Angriffskomplexität im CVSS-Vektor spiegelt wider, dass Heap-Layout und Build den Erfolg beeinflussen.

Erste Angriffe, KI half beim Exploit

Laut watchTowr laufen bereits Ausnutzungsversuche gegen beide Lücken, Cloudflare meldete gegenüber The Hacker News erste Angriffe schon vor dem Patch. Einen bestätigten Einbruch gibt es bisher nicht. In den Niederlanden gingen trotzdem vorsorglich DigiD und MijnOverheid vom Netz, das britische NCSC rät, Systeme ohne Patch notfalls offline zu nehmen.

Gefunden hat die Fehler Wiz Research, gemeldet am 24. August. Wiz schreibt, Gemini 4 Argon und GPT-5.6 Sol hätten bei Fund, Exploit-Entwicklung und Patch-Prüfung geholfen, vor allem beim Feintuning des Exploits je Ziel. Auch OpenAI und die Firma Calif waren laut Wiz an Fund und Koordination beteiligt. Dass Sprachmodelle die Hürde für Exploits senken, passt zu dem, was Anthropic zuletzt über sich selbst kopierende KI auf billigen TV-Boxen geschrieben hat.

Was Admins jetzt tun sollten

Die einzige vollständige Lösung ist das Update. Distributionen und LTS-Anbieter haben die Patches vorab bekommen und rüsten sie oft in ältere Versionsnummern nach, entscheidend ist deshalb das Changelog mit den CVE-Nummern. Für die nicht mehr gepflegten Zweige 7.4, 8.0 und 8.1 gibt es nur minimale Backports für alle, die selbst kompilieren. Wer nicht sofort aktualisieren kann, setzt laut PHP administrativ memory_limit=-1, weil der planbare Speicherdeckel den bestätigten OOM-Exploit erst möglich macht. Dazu kommen session.upload_progress.enabled=0 und unter PHP 8.5 fatal_error_backtraces=0, danach müssen alle Worker neu starten. Wer keine Multipart-Formulare nutzt, blockt sie am Frontend. Vollständig schützt keine dieser Einstellungen. Bei Webspace oder einer NAS mit Webserver hilft nur ein Blick auf die PHP-Version, die der Anbieter ausliefert.