Laut einem Bericht von Pierluigi Paganini für Security Affairs vom 24. Oktober haben Angreifer vier Tage vor der öffentlichen Bekanntgabe und der Verfügbarkeit eines Patches versucht, PHP2Shell auszunutzen. Der Bericht stützt sich auf Beobachtungen von Honeypots der AWS-Forscher. Die erkannten Versuche belegen nicht, dass Server erfolgreich kompromittiert wurden.
Die beiden offiziellen Advisories von PHP, veröffentlicht am 21. Oktober 2026, beschreiben kritische Schwachstellen bei der Speicherverwaltung, die Remote Code Execution ermöglichen können. Beide nennen Korrekturen in PHP 8.2.35, 8.3.36, 8.4.27 und 8.5.12. In den jeweiligen Release-Zweigen sind frühere Versionen betroffen. Die genauen Bedingungen für eine Ausnutzung unterscheiden sich je nach Schwachstelle, Server-Schnittstelle, Anwendung und Konfiguration.
Eine erfolgreiche Ausnutzung könnte es einem Angreifer erlauben, Befehle mit den Berechtigungen des Konto des Web-Workers auszuführen. Paganini nennt mögliche Folgen wie Datendiebstahl, Installation von Malware, Änderungen an Websites und Dienstunterbrechungen. Dabei handelt es sich um potenzielle Auswirkungen und nicht um bestätigte Ergebnisse der gemeldeten Versuche.
Speichererschöpfung kann ungültigen Anfragezustand offenlegen
Die erste Schwachstelle, CVE-2026-109618, betrifft die Verwendung von longjmp() durch PHP, um die Verarbeitung einer Anfrage nach einem Out-of-Memory-Fehler abzubrechen. Erfolgt dieser Abbruch, während der Speicher der Anfrage nur teilweise initialisiert ist, kann die Shutdown-Verarbeitung auf ungültige Zustände stoßen und zu Remote Code Execution führen.
Das Advisory beschreibt mehrere Wege, wie Multipart-Anfragen den Speicher erschöpfen können, obwohl scheinbar Eingabelimits gelten. Dazu gehören Anfragen ohne verwertbare deklarierte Content-Länge, nicht begrenzte Header in einzelnen Teilen sowie leere Dateifelder, die Metadaten erzeugen, ohne auf max_file_uploads angerechnet zu werden. Auch anwendungsspezifische Verarbeitung von Eingaben, die ein Angreifer kontrolliert, kann den Speicher erschöpfen.
Laut dem PHP-Advisory wurde Remote Code Execution ohne Authentifizierung über HTTP gegen Apache mod_php validiert. Dabei kamen die Standardwerte für Eingabe- und Speicherlimits von PHP sowie übliche prefork-Konfigurationen mit mehreren Workern zum Einsatz. Die automatische Verarbeitung des Anfragekörpers kann das Problem auslösen, bevor Anwendungscode läuft. Zusätzliche Worker und unabhängiger Traffic können die nötige Anzahl an Versuchen erhöhen. Die Zuverlässigkeit hängt vom PHP-Build, von den Erweiterungen, vom Verhalten des Frontends und vom Allocator-Layout ab.
Für andere Bereitstellungsarten fallen die Befunde unterschiedlich aus. FPM beendet einen Child-Prozess, wenn der Anfragestart fehlschlägt, sodass dieser Startpfad keinen ungültigen Zustand verbrauchen kann. Die Quellcode-Analyse deutet dennoch auf eine Anfälligkeit nach dem normalen Start hin, auch wenn kein vollständiger FPM-Exploit gezeigt wurde. Das Advisory hält FrankenPHP für wahrscheinlich anfällig für anwendungsunabhängige Angriffe. Eine anwendungsspezifische Ausnutzung über LSAPI gilt als wahrscheinlich, ist aber nicht validiert.
Veralteter Zustand kann Anfragegrenzen überschreiten
Die zweite Schwachstelle, CVE-2026-109619, betrifft Zustände auf Worker-Ebene, die Verweise auf Speicher behalten, der zu einer bereits abgeschlossenen Anfrage gehörte.
Für eine Ausnutzung ist zunächst eine Operation nötig, nach der anfragebezogene Zustände auch nach der Freigabe dieses Speichers noch zugänglich sind. Danach folgt eine weitere Operation, die den veralteten Zustand verwendet, bevor die normale Initialisierung ihn zurücksetzt. Im demonstrierten Fall laufen diese Operationen in unterschiedlichen HTTP-Anfragen ab, die derselbe Worker bearbeitet.
Fatale Fehler, einschließlich Speichererschöpfung, können die Bereinigung unterbrechen. Auch nicht-fatale Diagnosen können einen Fehlerzustand neu befüllen, nachdem er gelöscht wurde. Ein gezielt angeordneter Heap kann das daraus entstehende Use-after-Free in Remote Code Execution verwandeln. Ob ein Zustand erreichbar ist, hängt von dem konkreten Zustand, der Anwendung, den Erweiterungen und der Konfiguration ab.
Updates bieten die vollständige Abhilfe
Beide Advisories verweisen Betreiber auf die gepatchten Versionen in den jeweiligen PHP-Zweigen:
- PHP 8.2: 8.2.35
- PHP 8.3: 8.3.36
- PHP 8.4: 8.4.27
- PHP 8.5: 8.5.12
Laut dem Herausgeber ist das Update die einzige vollständige Gegenmaßnahme gegen die Schwachstelle durch Speichererschöpfung und die einzige verlässliche gegen die Schwachstelle durch veralteten Zustand.
Für Installationen, die nicht aktualisieren können, entfernt die administrative Vorgabe memory_limit=-1 das vorhersehbare Limit pro Anfrage, das beim bestätigten Exploit für Speichererschöpfung genutzt wurde. Jeder PHP-Worker muss neu gestartet werden. Betreiber müssen außerdem sicherstellen, dass Einstellungen für Pools, Verzeichnisse oder Anwendungen kein endliches Limit wieder einführen. Das bleibt ein unvollständiger Schutz, weil zugrunde liegende Allokationsfehler den verwundbaren Pfad trotzdem auslösen können.
PHP warnt ausdrücklich davor, RLIMIT_AS oder RLIMIT_DATA zu verwenden, da diese mmap()-Fehler verursachen können, die genau diesen Pfad auslösen. Auch Speicherlimits für Container oder cgroups bieten nur unvollständigen Schutz. Sie können mehrere Worker oder den Master-Prozess beenden.
Für PHP 8.5 entfernt die administrative Einstellung fatal_error_backtraces=0 in Verbindung mit einem Neustart jedes Workers den Auslöser, der im bestätigten RCE-Fall über veralteten Zustand genutzt wurde. Andere globale oder erweiterungsbezogene Zustände deckt sie nicht ab. Laut Advisory gibt es keine generische Konfigurationsänderung, die vollständigen Schutz bietet.
Der Herausgeber empfiehlt außerdem vorsichtige Werte für post_max_size, unabhängig durchgesetzte Grenzen für die dekodierte Größe von Anfragen am Frontend sowie Begrenzungen für die Verschachtelung von Eingaben, Variablen, Multipart-Teile, Header pro Teil und Uploads. Anwendungen, die keine Multipart-Formulardaten verwenden, können diese am Frontend blockieren. Diese Maßnahmen verringern das Risiko, ersetzen aber keine Updates.
In seinem Bericht vom 24. Oktober fordert Paganini Betreiber auf, verdächtige Aktivitäten zu prüfen, die bis zum 17. Oktober zurückreichen. Außerdem erörtert er, wie KI die Entwicklung von Exploits beschleunigen könnte. Gleichzeitig warnt er davor, Angriffe vorschnell als KI-gesteuert einzustufen.
