CVE-2026-109619 · GHSA-6wmf-4rv5-p3rp
Die requestübergreifende Hälfte von PHP2Shell: Nach einem fatalen Fehler lässt PHP globale Zeiger auf bereits freigegebenen Speicher zurück. Der nächste Request auf demselben Worker nutzt sie — und gibt Speicher preis oder verschafft einem Angreifer Codeausführung.
Zuletzt geprüft 2026-10-22
Schweregrad
Authentifizierung
Behoben in
Teil von
Ein fataler Fehler (auch OOM) kann das Zurücksetzen pro Request überspringen, sodass globaler Error-, Session-, Objekt- oder Extension-Zustand auf Speicher zeigt, der am Ende des Requests freigegeben wurde. Der nächste Request auf demselben Worker kann diesen freigegebenen Speicher vor der normalen Initialisierung verwenden.
Auswirkung: Use-after-free, das zum Auslesen von Worker-Speicher oder zur Codeausführung führt. Demonstriert: Pre-Auth-RCE auf WordPress und Drupal; anwendungsunabhängiges Auslesen von Speicher aus der Ferne.
PHP hält einen Teil des Zustands in requestbezogenen Globals — Error-, Session-, Objekt- und Extension-Zustand. Normalerweise wird er am Ende jedes Requests zurückgesetzt. Ein fataler Fehler, auch Out-of-Memory, kann dieses Zurücksetzen überspringen, und Warnungen während des Shutdowns können den Error-Zustand nach dem Löschen wieder befüllen.
Der Speicher, auf den diese Globals zeigen, wird am Ende des Requests freigegeben. Führt derselbe Worker danach Code vor der normalen Request-Initialisierung aus — INI-Diagnosen oder Upload-Progress-Verarbeitung —, nutzt er freigegebenen Speicher. Worker, die viele Requests nacheinander bedienen (PHP-FPM, mod_php-Kindprozesse), machen das erreichbar.
Use-after-free im Fatal-Error-Backtrace
EG(last_fatal_error_backtrace) überlebt einen OOM, der den Request-Heap zerstört. Eine frühe Diagnose im nächsten Request folgt dem hängenden Zeiger. Stärkster demonstrierter Fall: PHP 8.5 mit fatal_error_backtraces, RCE auf mod_php.
Lebenszyklus des Session-Upload-Progress
Session-Zustand, der von einem abgebrochenen Request übrig blieb, wird im nächsten Request von der Upload-Progress-Verarbeitung genutzt. RCE sowohl auf mod_php als auch auf PHP-FPM bestätigt.
Type Confusion im Shared Memory von OPcache
Ein Allokationsfehler zwischen dem Hochzählen von CG(map_ptr_last) und dem Veröffentlichen der gemeinsamen Grenze hinterlässt Slots, über die sich Worker uneinig sind; so kann ein Worker einen Slot für einen anderen Objekttyp wiederverwenden.
Weiterer requestbezogener Zustand
Objekt- und Extension-Zustand beschreibt das Advisory als unter Bedingungen ausnutzbar. Der Fix deckt das Muster ab, nicht nur diese Pfade.
Das PHP-Advisory und der Wiz-Beitrag gruppieren manche Pfade unterschiedlich. Der Patch behebt das gemeinsame Fehlermuster, die Gruppierung ändert also nichts an dem, was Sie tun müssen.
| Branch | Anfällig | Behoben in |
|---|---|---|
| 8.5 | < 8.5.12 | 8.5.12 |
| 8.4 | < 8.4.27 | 8.4.27 |
| 8.3 | < 8.3.36 | 8.3.36 |
| 8.2 | < 8.2.35 | 8.2.35 |
| 8.1 · 8.0 · 7.4 | alle | Nur Quellcode-Backport |
| 5.4 – 7.3 | alle | Kein Fix |
| Setup | …109619 | Hinweise |
|---|---|---|
| Apache + mod_php | RCE bestätigt | Beide CVEs mit Standardlimits bis zur RCE bestätigt. Setup mit dem höchsten Risiko. |
| PHP-FPM (nginx, Apache, Caddy…) | RCE bestätigt | RCE über den Session-Lebenszyklus auf FPM bestätigt. OOM-Pfad über Codepfade auf Anwendungsebene bestätigt; kein generischer FPM-Exploit veröffentlicht. |
| FrankenPHP / LiteSpeed LSAPI | Wahrscheinlich | Laut Advisory wahrscheinlich anfällig. Langlebige Worker machen requestübergreifenden Zustand eher relevanter als weniger. |
| CLI (Cron, Queue-Worker, artisan) | Nicht behandelt | In den Advisories nicht behandelt und im Normalbetrieb nicht per HTTP-Request erreichbar. Trotzdem aktualisieren — es ist dasselbe Paket. |
Vektor: CVSS:4.0/AV:N/AC:H/AT:P/PR:N/UI:N/VC:H/VI:H/VA:H/SC:N/SI:N/SA:N
| Metrik | Bedeutung hier | Wirkung |
|---|---|---|
AV:N Attack Vector: Network | Über das Internet mit gewöhnlichen HTTP-Requests erreichbar. | Erhöht Score |
AC:H Attack Complexity: High | Der Exploit muss auf das Speicherlayout jedes Ziels abgestimmt werden; es ist kein Copy-and-paste mit einem Request. | Senkt Score |
AT:P Attack Requirements: Present | Der Erfolg hängt von Einsatzbedingungen ab (SAPI, Limits, Worker-Wiederverwendung), die der Angreifer nicht kontrolliert. | Senkt Score |
PR:N Privileges Required: None | Kein Konto, kein Login. | Erhöht Score |
UI:N User Interaction: None | Niemand muss etwas anklicken. | Erhöht Score |
VC:H / VI:H / VA:H Auswirkung auf das verwundbare System: High | Vollständiger Verlust von Vertraulichkeit, Integrität und Verfügbarkeit auf dem PHP-Server. | Erhöht Score |
SC:N / SI:N / SA:N Auswirkung auf Folgesysteme: None | Der Score zählt das Weiterspringen auf andere Systeme nicht mit — in der Praxis ermöglichen gestohlene Zugangsdaten das oft. | Senkt Score |
Die Lösung ist ein PHP-Update
Installieren Sie ein gepatchtes Release und starten Sie jeden PHP-Worker neu. Patch-Anleitung →
Wenn Sie nicht sofort aktualisieren können, nennt php.net diese Teilmaßnahmen:
session.upload_progress.enabled = 0 in php.ini, im FPM-Pool oder in der Serverkonfiguration, danach jeden Worker neu starten. Details →fatal_error_backtraces = 0 und neu starten. Das blockiert nur den bestätigten Backtrace-Pfad.error_reporting, display_errors oder @ zu verbergen, hilft nicht.pm.max_requests = 1 erwägen, wo die Leistung es zulässt.Ja. Ein requestübergreifender Use-after-free kann Worker-Speicher offenlegen — Passwörter, API-Schlüssel, Session-Token anderer Benutzer —, ohne dass der Angreifer je Code ausführt. Das erschwert die Erkennung.
Teilweise. Es blockiert die bestätigten Session-Pfade, aber nicht andere Varianten, und wirkt nur in php.ini, im FPM-Pool oder in der Serverkonfiguration — nicht in .user.ini oder per ini_set() — gefolgt von einem Neustart jedes Workers.
Ja. Die RCE über den Session-Lebenszyklus wurde sowohl auf mod_php als auch auf PHP-FPM bestätigt. FPM-Worker bedienen viele Requests nacheinander — genau das, was requestübergreifender veralteter Zustand braucht.
Es verkürzt, wie lange korrupter Zustand überlebt, und pm.max_requests = 1 schaltet die Worker-Wiederverwendung ganz ab — zu hohen Leistungskosten. Gegen Pfade, die nur einen Request brauchen, hilft es nicht.