PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35: kritische Lücken für Remote Code Execution geschlossen – und wie man ohne Docker-Überraschungen patcht
Am 21. Okt. 2026 schloss PHP zwei kritische RCE-Lücken ohne Authentifizierung. Wer betroffen ist, wie Sie die tatsächlich laufende Version prüfen und drei Docker-Fallen aus unserer Praxis.
Am 21. Oktober 2026 hat das PHP-Projekt die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 veröffentlicht. Laut php.net beheben sie zwei kritische Schwachstellen, die Remote Code Execution ohne Authentifizierung ermöglichen können. Beide sind mit CVSS v4.0 9.2 bewertet. Wer Webanfragen mit PHP ausliefert, sollte heute noch aktualisieren.
Was behoben wurde
Das Security Advisory des Projekts nennt zwei Probleme:
- CVE-2026-109618 (GHSA-w8hw-w9fx-j79w, „RCE via OOM corruption"): Die Behandlung von Speichermangel kann PHP unterbrechen, während Anfragedaten erst teilweise initialisiert sind. Das Aufräumen der Anfrage behandelt ungültige Daten dann als gültig.
- CVE-2026-109619 (GHSA-6wmf-4rv5-p3rp, „RCE via stale global state"): Anfragebezogener Zustand kann das Freigeben seines Speichers überleben, und eine spätere Anfrage im selben Worker nutzt ihn, bevor er zurückgesetzt wird.
Betroffen sind alle Versionen unterhalb von 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Laut Advisory ist das Update die einzige vollständige Lösung.
Wer betroffen ist
Alles, was Webanfragen mit PHP bedient. Die GitHub-Advisories behandeln Apache mod_php, PHP-FPM, LiteSpeed (LSAPI) und FrankenPHP. Die Ankündigung auf php.net nennt das Risiko für mod_php am höchsten, „mit einem demonstrierten Exploit, bei dem eine nicht authentifizierte Anfrage den Angriff auslösen kann, bevor Anwendungscode läuft".
Laut den Advisories erscheint PHP-FPM nach Quellcode-Analyse anfällig, für die zweite Lücke wurde ein Pfad über den Session-Lebenszyklus validiert; bei FrankenPHP sei für die erste Lücke wahrscheinlich mit anwendungsunabhängigen Angriffen zu rechnen. Die Details unterscheiden sich je SAPI, behandeln Sie daher alle Web-SAPIs als betroffen.
Zur Formulierung: php.net spricht von einem demonstrierten Exploit. Eine Primärquelle, die Angriffe in freier Wildbahn bestätigt, haben wir nicht gefunden und behaupten das daher nicht.
Versionen und Support-Ende
- Behoben in 8.5.12, 8.4.27, 8.3.36, 8.2.35.
- PHP 8.2 erreicht am 31. Dezember 2026 das Support-Ende.
- PHP 8.1 und älter erhalten vom Projekt keine Updates mehr. Laut Advisory bieten manche Anbieter Backports.
- Der Debian Security Tracker listet zum Zeitpunkt unserer Prüfung Fixes für bookworm (php8.2 8.2.35-1
deb12u1) und trixie (php8.4 8.4.27-1deb13u1).
Wenn ein sofortiges Update nicht möglich ist
Das Advisory nennt Teilmaßnahmen, die eine Installation nicht sicher machen:
memory_limit = -1 ; per php_admin_value, damit es nicht überschrieben wird
session.upload_progress.enabled = 0 ; danach Worker neu starten
; nur PHP 8.5:
fatal_error_backtraces = 0
Außerdem werden ein kleineres post_max_size (8M ohne Uploads, 32M mit Uploads) und Limits für Multipart-Teile, Header und Uploads empfohlen, oder das Blockieren von Multipart-Anfragen im Frontend, falls Sie sie nicht nutzen.
Die tatsächlich laufende Version prüfen
php -v zeigt die CLI-Version, nicht unbedingt die, die HTTP-Anfragen beantwortet. Prüfen Sie die Web-SAPI:
# im Container oder auf dem Host, der den Traffic bedient
php -r 'echo PHP_VERSION, " ", PHP_SAPI, PHP_EOL;' # nur CLI, ein Hinweis
php-fpm -v # FPM-Binary
Die verlässliche Antwort liefert ein laufender Webprozess: eine temporäre Seite, die PHP_VERSION und PHP_SAPI ausgibt (danach löschen, und phpinfo() nie öffentlich lassen).
Starten Sie anschließend alle PHP-Prozesse neu. Eine neue Binärdatei auf der Platte ändert nichts für bereits laufende Prozesse. Langlebige Worker (Octane, RoadRunner, FrankenPHP im Worker-Modus, Queue-Worker, Scheduler) behalten den alten Code bis zum Neustart.
Was wir bei Woodander getan haben
Wir haben unseren eigenen Stack am selben Tag gepatcht. Drei Dinge haben Zeit gekostet, und sie betreffen die meisten Docker-Setups.
1. Images hinken dem Release hinterher. Stunden nach dem Release lieferte das Image dunglas/frankenphp:1-php8.4-bookworm noch PHP 8.4.26 aus, während das offizielle php:8.4-zts-bookworm bereits 8.4.27 hatte. Wir haben eine eigene Basis gebaut: das offizielle PHP-ZTS-Image plus die FrankenPHP-Binary aus dem Upstream-Image (sie bindet libphp.so dynamisch). Wir haben geprüft, dass die Web-SAPI 8.4.27 ausliefert, und wechseln zurück, sobald Upstream neu gebaut hat. Beachten Sie: frankenphp version zeigt weiterhin die PHP-Version, gegen die die Binary gebaut wurde. Prüfen Sie also mit einer echten Anfrage, nicht mit dem Banner.
2. Die Paketquelle war überlastet. PECL lieferte 504-Fehler, während alle neu bauten, und unser Build der redis-Extension schlug fehl. Das GitHub-Tag-Tarball von phpredis ist kein vollwertiger Ersatz: Es enthält das Submodul liblzf nicht. Ein erneuter Versuch nach der Erholung von PECL funktionierte. Cachen oder vendoren Sie Ihre Extension-Builds und halten Sie ein bewährtes Image für ein Rollback bereit.
3. ufw schützt keine von Docker veröffentlichten Ports. Eine ufw-Regel „nur Cloudflare erlauben" greift nicht für Ports, die Docker veröffentlicht, weil Dockers iptables-Regeln zuerst laufen. Setzen Sie die Beschränkung in die Chain DOCKER-USER oder nutzen Sie Cloudflare Tunnel, damit der Origin keinen öffentlichen Port hat. Von außen prüfen:
curl -sS -m 5 -o /dev/null -w '%{http_code}\n' http://YOUR_ORIGIN_IP:PORT/
Kommt eine Antwort, ist der Origin direkt erreichbar, egal was ufw anzeigt. Das ist gerade während des Patchens wichtig.
Checkliste
- Server-Snapshot erstellen oder das vorherige Image-Tag behalten.
- Auf die behobene Version Ihres Zweigs aktualisieren (oder ein Herstellerpaket mit Backport).
- Alles neu starten, was PHP ausführt: FPM, Apache, FrankenPHP, Queue-Worker, Scheduler.
- Die Version pro Prozess über die Web-SAPI prüfen.
- Sicherstellen, dass der Origin nicht direkt erreichbar ist, wenn Sie sich auf CDN oder Firewall verlassen.
- Auf Kompromittierung prüfen: unbekannte Dateien in Web- und Upload-Verzeichnissen, neue Cronjobs, ungewöhnliche Prozesse, unerwartete ausgehende Verbindungen sowie PHP-Logs mit Abstürzen oder Fatal Errors. Laut Advisory beweisen saubere Logs keine Sicherheit.
