🌐 Auch auf: English · Français · Español
Am 21. Oktober 2026 hat das PHP-Projekt vier Releases auf einmal veröffentlicht – 8.5.12, 8.4.27, 8.3.36 und 8.2.35 – und sich den üblichen „Bugfix-Release“-Smalltalk gespart. Zwei kritische Lücken, jeweils CVSS 9.2, Codeausführung aus der Ferne ohne Anmeldung, und ein Satz, den jeder Admin zweimal lesen sollte: „There are no complete mitigations, updating is the only safe choice.“
Die Fehler stecken schon sehr lange in PHP; spannend ist nicht eine einzelne schlechte Codezeile, sondern wie PHP hinter sich aufräumt. Hier die kurze, nerdige Fassung.
🧨 Lücke 1: der Speicher-Fallschirm, der zu früh aufgeht
CVE-2026-109618. Geht einer Anfrage der Speicher aus, wickelt PHP nicht höflich ab, sondern springt mit longjmp() direkt hinaus. Passiert das, während Anfragedaten erst halb initialisiert sind, behandelt das Aufräumen am Ende der Anfrage die halb gebauten Strukturen als gültig und arbeitet mit Müll. Mit dem richtigen Müll ist das Codeausführung als Webserver-Benutzer.
Das Gemeine: Man erreicht „Speicher voll“, obwohl man scheinbar innerhalb der Grenzen bleibt, die PHP durchsetzt. Multipart-Uploads ohne brauchbare Längenangabe rutschen an post_max_size vorbei, Multipart-Teile dürfen beliebig viele Header tragen, die in PHP viel mehr Speicher kosten als auf der Leitung, und leere Dateifelder zählen nicht zu max_file_uploads. Der Fix schafft longjmp() bei Speichermangel ganz ab.
👻 Lücke 2: der Zustand der letzten Anfrage spukt in der nächsten
CVE-2026-109619. Ein PHP-Worker bedient viele Anfragen nacheinander. Mancher globale Zustand – Fehler, Sessions, Daten von Erweiterungen – kann noch in den Speicher der vorigen Anfrage zeigen, nachdem dieser freigegeben wurde. Greift die nächste Anfrage darauf zu, bevor PHP ihn zurückgesetzt hat, gibt es ein klassisches Use-after-free. Bestätigte Auslöser: die in PHP 8.5 neuen Backtraces bei fatalen Fehlern und der Session-Upload-Fortschritt.
🎯 Wer betroffen ist
- Alles, was Web-Anfragen bedient: PHP-FPM, Apache mit
mod_php(Exploit bestätigt, höchstes Risiko), php-cgi, FrankenPHP, LiteSpeed. - Bei PHP-FPM wurde der Weg über den Session-Upload-Fortschritt als RCE bestätigt; der Speicher-Weg gilt „nach Quellcode-Analyse als anfällig“.
- Die Zweige 8.2 bis 8.5. PHP 8.1 und älter bekommen gar keinen Fix – wer das noch betreibt, hat hiermit sein Zeichen. PHP 8.2 selbst ist am 31. Dezember 2026 am Ende.
🩹 Notbehelfe, falls ein Update heute wirklich nicht geht
session.upload_progress.enabled = 0(und danach aus lassen, wenn man es nicht braucht), dazufatal_error_backtraces = 0unter PHP 8.5 – alle Worker neu starten.- Anfragegröße, Multipart-Teile und Header am Reverse Proxy begrenzen; Multipart ganz sperren, wo die Anwendung keine Uploads braucht.
- Ein Speicherlimit über Container oder cgroup – nicht
RLIMIT_AS/RLIMIT_DATA, die lösen genau den anfälligen Weg aus. - All das senkt das Risiko. Nichts davon schließt die Lücke. Das sagen die Advisories selbst.
🐳 Die Container-Falle – der Preis der Schichten
Container haben einen Nachteil, den ein Tag wie dieser schmerzhaft sichtbar macht. Ein offizielles Image wird nicht aus einem Guss gebaut; es ist ein Stapel von Schichten, und jede Schicht gehört jemand anderem: unten eine Debian-Basis, darauf das offizielle php-Image, darauf das wordpress– oder nextcloud-Image. Ein Fix in PHP muss diese Kette hinauf, Stockwerk für Stockwerk:
- Das PHP-Projekt veröffentlicht das Release (hier: am 21. Oktober am Nachmittag, europäische Zeit).
- Die Maintainer des offiziellen
php-Images passen ihre Build-Dateien an, ein Reviewer übernimmt sie, und die Build-Farm baut jede Variante neu – fpm, apache, cli, alpine, debian, für jede Architektur. Das geschah etwa eine Stunde nach dem Release. - Erst danach können die Images von
wordpressundnextcloudauf der neuen Basis neu gebaut werden, wieder für jeden Tag und jede Architektur – unter demselben Tag wie vorher. Dieser Schritt kam Stunden später, nicht Minuten. - Und erst dann kann mein Update-Lauf das neue Image holen und die Pods neu starten.
Auf einem klassischen Server tippt man apt upgrade, sobald die Distribution das Paket liefert – Distributionen bekommen die Patches vorab und veröffentlichen meist innerhalb von Stunden. Bei Containern kann man PHP nicht einfach im Image aktualisieren: Der Container ist zum Ersetzen gedacht, nicht zum Flicken, und was man von Hand ändert, ist beim nächsten Neustart weg. Man wartet auf die Leute, die die Schichten bauen. Meistens ist das ein Vorteil – reproduzierbare, getestete Images, ein Update ist ein Image-Tausch, ein Rollback der vorige Tag. An einem Tag mit einer kritischen RCE ist es ein Wartezimmer.
Zwei praktische Folgen. Erstens: Der Tag sagt nichts. wordpress:7.1.3-php8.4-fpm war vor und nach dem Fix derselbe Tag, also die PHP-Version im Image prüfen: docker exec … php -v oder kubectl exec … -- php -r "echo PHP_VERSION;" muss 8.4.27 / 8.5.12 (oder 8.3.36 / 8.2.35) zeigen – dann das Image neu ziehen und den Pod neu starten. Zweitens: einen Plan für die Wartezeit haben. Genau dafür sind die Notbehelfe oben da.
🏠 Und auf meinen eigenen Servern?
Ja, betroffen – alle drei. Der Blog läuft mit WordPress im offiziellen Image wordpress:…-php8.4-fpm, die beiden Nextcloud-Server im offiziellen Image nextcloud:…-fpm mit PHP 8.5: überall PHP-FPM, hinter nginx. Und beide bestätigten Wege waren offen: Der Session-Upload-Fortschritt ist standardmäßig an, unter PHP 8.5 auch die Backtraces bei fatalen Fehlern. Der Rest des Aufbaus macht einen Angriff schwerer – kein mod_php, Größenlimits am Ingress, ein Speicherlimit für jeden Pod, SELinux um jeden Container –, aber schwerer ist nicht unmöglich, und nichts davon ist ein Fix.
Die Wartezeit. Das reparierte PHP war draußen, die reparierten Images nicht (siehe die Container-Falle oben). Also habe ich für diese Stunden den sanften Weg aus der Notbehelf-Liste genommen: session.upload_progress.enabled = Off auf allen drei Servern, auf den beiden Nextclouds mit PHP 8.5 zusätzlich fatal_error_backtraces = Off. Das schließt genau die beiden Wege, die die Advisories unter PHP-FPM als ausnutzbar bestätigt haben, und keine der beiden Anwendungen nutzt eine der Funktionen – WordPress verwendet den Upload-Fortschritt gar nicht, Nextcloud lädt große Dateien in Stücken per JavaScript hoch. Die Seiten blieben online. Ein Fix ist das nicht: Der Weg über Speichermangel bleibt theoretisch offen, bis das reparierte PHP läuft. Beide Einstellungen bleiben auch nach dem Update aus: Das Advisory empfiehlt, den Upload-Fortschritt abgeschaltet zu lassen, wo er nicht gebraucht wird – eine Funktion, die niemand nutzt, kann auch die nächste Lücke nicht öffnen –, und die Backtraces bei fatalen Fehlern bringen hier wenig, weil Nextcloud seine Fehler ohnehin mit Stack-Trace in sein eigenes Log schreibt.
Stand: alles bereinigt. Das neu gebaute WordPress-Image mit PHP 8.4.27 stand um 20:06 Uhr MESZ (18:06 UTC) bereit, etwa vier Stunden nach dem PHP-Release; das neu gebaute Nextcloud-Image mit PHP 8.5.12 folgte um 20:25 Uhr MESZ (18:25 UTC). Der Blog läuft seit 20:26 Uhr mit dem gepatchten PHP, die beiden Nextcloud-Server seit 20:31 und 20:36 Uhr – geprüft in jedem Container, nicht am Tag, zusammen mit den beiden Notbehelf-Einstellungen, die aus bleiben. Vom Release bis zum letzten gepatchten Server: rund viereinhalb Stunden, die meiste Zeit davon Warten auf die Images. Keine Spuren eines Angriffs in den Logs, und die Integritätsprüfungen von WordPress (Kern und alle Plugins) und Nextcloud waren sauber. Ich bin safe. 🐘✅
⏱️ TL;DR
Zwei kritische RCEs ohne Anmeldung in PHP selbst, jede Web-SAPI, kein echter Workaround. Jetzt auf 8.5.12 / 8.4.27 / 8.3.36 / 8.2.35 aktualisieren – Distributionspakete, Container-Images, Hosting-Oberfläche, was auch immer ihr nutzt. Und wenn euer Hoster PHP für euch betreibt: fragt heute nach, ob er es schon getan hat. apt upgrade war nie wörtlicher gemeint. 🐘🔐
Keine Gewähr: Dieser Beitrag beschreibt, was ich auf meinen eigenen Servern vorgefunden und getan habe, nach bestem Wissen am Tag des Schreibens. Für eure Systeme übernehme ich keine Haftung – weder für das Update noch für die hier beschriebenen Notbehelfe, die ausdrücklich keinen vollständigen Schutz bieten. Der einzige echte Fix ist die gepatchte PHP-Version; prüft für euer Setup die offiziellen Advisories.
Quellen: PHP Security Advisory vom 21.10.2026, GHSA-w8hw-w9fx-j79w, GHSA-6wmf-4rv5-p3rp.
