PHP-Notfallrelease: Zwei kritische Core-RCEs in 8.2.35 bis 8.5.12 gefixt
PHP hat einen außerplanmäßigen Sicherheitsrelease veröffentlicht, der zwei kritische Use-after-Free-Schwachstellen im Sprachkern schließt - beide ermöglichen Remotecode-Ausführung ohne Authentifizierung, beide mit 9,2 auf der CVSS-v4.0-Skala. Die behobenen Versionen sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, heute veröffentlicht und im Release-Archiv des Projekts gelistet. Minimale Source-Backports für die lange nicht mehr gepflegten Zweige 7.4, 8.0 und 8.1 gibt es nur auf GitHub - offizielle Binärpakete dafür existieren nicht.
Dem Release ging ein ungewöhnlich chaotisches Vorab-Fenster voraus. Am 20. Oktober kündigte das Projekt einen Notfallrelease für heute 14:00 UTC an, ohne betroffene Versionen oder Funktionen zu nennen; wie OX Security dokumentierte, zirkulierten Screenshots eines Exploit-Tools bevor die Patches draußen waren, und das Projekt warnte selbst, dass Proof-of-Concept-Code, der in diesem Fenster kursiert, oft als Malware getarnt ist. Jetzt, wo Patches und Advisories öffentlich sind, ist das technische Bild klarer, als der Teaser-Zyklus vermuten ließ.Ein Out-of-Memory-Pfad zur Code-Ausführung
CVE-2026-109618, geführt als GHSA-w8hw-w9fx-j79w, missbraucht die Art, wie PHP Speichermangel behandelt. Schlägt eine Allokation fehl, wickelt die Engine den Request per longjmp() ab - geschieht das, während der Request-Speicher nur teilweise initialisiert ist, liest oder verzweigt die Shutdown-Phase später auf Speicher in ungültigem Zustand. Das Advisory beschreibt eine Familie von Allokationsdruck-Tricks, die das über einen gewöhnlichen HTTP-Request erreichbar machen: Multipart-Bodies ohne brauchbaren Content-Length, die an post_max_size vorbeischlüpfen, Parts mit Tausenden Headern, deren In-Memory-Repräsentation ihre Drahtgröße weit übersteigt, und leere File-Controls, die Metadaten-Arrays anlegen, ohne je gegen max_file_uploads zu zählen. Das Apache-mod_php-SAPI ist als ausnutzbar bestätigt: Forscher validierten unauthentifizierte Remotecode-Ausführung als Web-Worker-Account über einfaches HTTP gegen Default-Prefork-Konfigurationen - mit hoher Attack Complexity und womöglich mehreren Versuchen. PHP-FPM gilt über anwendungsspezifische Allokationspfade als anfällig, FrankenPHP und LiteSpeed wahrscheinlich ebenfalls. Der Patch ersetzt das rohe longjmp durch eine weiche Out-of-Memory-Falle am nächsten VM Safe Point plus ein hartes Versagen, das den Worker direkt beendet.Veralteter Zustand in Worker-Prozessen
CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp) ist der leisere Bruder: Worker-Prozesse tragen globalen Zustand - Error-Handler, Session-Daten, Objekt- und Extension-Buchhaltung - der auf Speicher zeigen kann, der einem einzelnen Request gehört. Schreibt ein Fatal Error, ein Out-of-Memory-Abbruch oder ein spätes Diagnostic solchen Zustand und nichts setzt ihn zurück, bevor der Request-Speicher freigegeben wird, baumeln die Globals des Workers ins Leere. Alles, was sie vor der Initialisierung eines frischen Requests berührt, liest freigegebenen Speicher. Zwei Produktionspfade sind bestätigt: die in PHP 8.5 neuen Fatal-Error-Backtraces unter mod_php und der Session-Upload-Progress-Mechanismus unter mod_php und FPM. Producer und Consumer müssen auf demselben Worker-Prozess landen - das macht FPM-Pools mit vielen Workern schwerer, aber nicht unmöglich zu treffen.Ein strategisch gestaltetes Heap-Layout kann vollständige Remotecode-Ausführung (RCE) ermöglichen. - PHP-Security-Advisory, GHSA-6wmf-4rv5-p3rp
Was Administratoren jetzt tun sollten
Aktualisieren ist die einzige vollständige Mitigation, und das ist kein Patch-and-Forget: Beide Advisories betonen, nach dem Upgrade alle PHP-Worker neu zu starten, weil veralteter Zustand in langlebigen Prozessen überdauern kann. Unterstützte Zweige erhalten Release-Binaries; Seiten auf EOL-Zweigen müssen die Source-Backports selbst einspielen.- Update auf 8.2.35, 8.3.36, 8.4.27 oder 8.5.12 (oder die GitHub-Backports für 7.4/8.0/8.1 einspielen), danach jeden Worker-Prozess neu starten.
- Wenn ein Update heute nicht möglich ist: session.upload_progress.enabled=0 und unter PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen und die Worker neu starten.
- Für die OOM-Schwachstelle memory_limit=-1 zentral erzwingen und prüfen, dass keine Pool- oder .htaccess-Override wieder ein endliches Limit setzt.
- post_max_size konservativ halten, Multipart-Requests am Frontend blockieren, wenn die Anwendung sie nicht nutzt, und Eingabevariablen, Header und Uploads begrenzen.
- Container- oder cgroup-Speicherlimits statt RLIMIT_AS oder RLIMIT_DATA verwenden - das Advisory warnt ausdrücklich, dass die RLIMIT-Mechanismen Allokationsfehler auf den verwundbaren Pfad drücken.
- Optional die Worker-Recyklierung mit pm.max_requests kappen, um das Fenster für Zustandsverschleppung zu verkürzen.