Das Sicherheitsrelease vom 21. Oktober 2026 korrigiert die Probleme in PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und ältere Branches gibt es keine neue offizielle Upstream-Version. Minimale Quellcode-Backports wurden für PHP 7.4, 8.0 und 8.1 veröffentlicht. Einige Anbieter können außerdem gepatchte Pakete für alte Versionen bereitstellen. Diese Optionen senken das akute Risiko, ersetzen aber keine unterstützte PHP-Version.

terminal
composer why-not php 8.4
composer audit
vendor/bin/rector process --dry-run
vendor/bin/rector process

CVE-2026–109618 betrifft den Zend Memory Manager. Wenn eine Speichererschöpfung die Initialisierung interner Strukturen unterbricht, kann die Aufräumlogik unvollständige Daten als gültige Strukturen behandeln. Ein wichtiger Angriffsbereich ist die Verarbeitung von multipart/form-data, weil dabei bereits vor dem Anwendungscode große interne Speicheranforderungen entstehen können. Für Apache mod_php wurde unauthentifizierte Remote Code Execution demonstriert. Bei PHP-FPM beendet ein fehlgeschlagener Request-Start normalerweise den betroffenen Worker. Eine Speichererschöpfung nach erfolgreichem Start kann jedoch weiterhin gefährliche Zustände erzeugen. Die offizielle Einschätzung hält FPM deshalb für betroffen, beschreibt für diese CVE aber keinen vollständigen FPM-Exploit.

PHP 8.5.12 ersetzt den unmittelbaren zend_bailout()-Pfad aus PHP 8.5.11 durch eine verzögerte Behandlung von Out-of-Memory-Zuständen. Der Runtime markiert EG(delayed_oom).state als ausstehend und fordert die Verarbeitung über EG(vm_interrupt) an einem sichereren Punkt der VM an. Eine zusätzliche harte Speichergrenze kann den Prozess mit _exit(137) beenden, bevor beschädigte interne Strukturen weiterverwendet werden. Damit ändert sich die Fehlerarchitektur des Runtimes, nicht nur eine einzelne Eingabeprüfung.

CVE-2026–109619 entsteht durch Request-Zustand, dessen Referenz nach der Freigabe des zugehörigen Speichers erhalten bleibt. Ein späterer Request im selben Apache- oder PHP-FPM-Worker kann auf diesen veralteten Zeiger zugreifen. Betroffen sind unter anderem Fehlerbehandlung, Backtraces fataler Fehler, Session-Upload-Progress und Konfigurationsdiagnostik. Session-Upload-Progress kann während der Verarbeitung des Request-Bodys vor der normalen Session-Initialisierung laufen. Ein expliziter Aufruf von session_start() ist daher nicht zwingend erforderlich. Für PHP-FPM nennt das Advisory einen validierten Angriffsweg, der eine passende Anwendungoperation nach dem Request-Start voraussetzt.

Die Korrektur erweitert die Bereinigung beim Request-Ende. zend_shutdown_executor_values() löscht unter anderem EG(last_fatal_error_backtrace), setzt EG(num_errors) zurück und weist EG(errors) sowie EG(exception) den Wert NULL zu. Dadurch soll Request-eigener Zustand nach einem abnormalen Ablauf nicht in den nächsten Request desselben Workers gelangen.

Beide Lücken haben einen CVSS-v4.0-Wert von 9.2. Dieser Wert beschreibt die mögliche Schwere, nicht die konkrete Verwundbarkeit jeder Umgebung. Für die erste CVE existiert bei mod_php ein bestätigter Angriffsweg vor dem Anwendungscode. Für die zweite sind Wege über mod_php und PHP-FPM bestätigt, beim FPM-Betrieb allerdings mit Abhängigkeiten von Anwendung und Konfiguration. Betreiber sollten Version, SAPI, erreichbare Request-Pfade, Konfiguration, Worker-Lebenszyklus und bekannte Voraussetzungen prüfen. Temporäre Konfigurationsänderungen können einzelne Wege erschweren. Die eigentliche Abhilfe bleibt ein korrigierter Runtime.

Bei einer unterstützten PHP-Branch lässt sich die Sicherheitsmaßnahme meist klein halten, etwa mit dem Wechsel von PHP 8.4.26 auf PHP 8.4.27. Eine große Sprachmigration sollte nicht ohne besonderen Grund mit dem dringenden Patch kombiniert werden. Zu prüfen sind das tatsächlich eingesetzte Paket oder Base-Image, automatisierte Tests und geschäftskritische Abläufe. In Containern ist der Tag php:8.4-fpm veränderlich. Caches, Registry-Verzögerungen, Spiegelserver und festgelegte Digests können dazu führen, dass ein Build eine ältere Version enthält. Eine Versionsprüfung beim Build und ein unveränderlicher Image-Digest schaffen Nachvollziehbarkeit. Ein Host-Upgrade ändert PHP innerhalb eines Containers nicht.

Tests sollten Uploads, Importe, langlebige Jobs, Exception-Pfade, Sessions und Integrationen abdecken. Nach dem Deployment sind fehlgeschlagene Requests, Worker-Abstürze, Speicherdruck, Neustarts und fachliche Fehler zu beobachten. Wo die Infrastruktur es erlaubt, sollte die Auslieferung stufenweise erfolgen. Ein Rollback muss ein bekanntes Artefakt bewahren. Die dauerhafte Rückkehr zu einer verwundbaren Version ist keine akzeptable Sicherheitsstrategie.

Für PHP 8.1 und ältere Versionen ist die Lage schwieriger. PHP 8.1 endete am 31. Dezember 2025, ältere Branches waren bereits zuvor aus dem Upstream-Support gefallen. Ein verifizierter Backport eines Anbieters kann das unmittelbare Risiko reduzieren. Das strategische Ziel sollte jedoch eine unterstützte Branch sein. PHP 8.2 erreicht am 31. Dezember 2026 sein Ende. PHP 8.4 oder PHP 8.5 sind daher bei passender Framework- und Dependency-Kompatibilität nachhaltigere Ziele.

Eine Kompatibilitätsprüfung sollte Composer-Vorgaben, nicht unterstützte Extensions, entfernte Sprachfunktionen, veraltetes Verhalten, Framework-Anforderungen und Infrastrukturabhängigkeiten erfassen. composer why-not php 8.4 zeigt mögliche Abhängigkeitssperren. composer audit prüft bekannte Advisories von Paketen. Keine der beiden Prüfungen beweist die Laufzeitkompatibilität. RectorPHP kann mit AST-basierten Transformationen viele Sprachänderungen automatisieren. Eine Konfiguration kann RectorConfig::configure(), withPaths(), withPhpSets() oder schrittweise withPhpLevel() verwenden. Dry-Runs und kleine Änderungsgruppen erleichtern die Kontrolle. Rector aktualisiert den Interpreter nicht, löst nicht jeden Dependency-Konflikt und ersetzt keine Regressionstests. Für KI-gestützte Migrationswerkzeuge gilt dasselbe.

Ein großes Upgrade ist ein Engineering-Programm und keine einzelne Codeaufgabe. Codeänderungen, Dependency-Arbeiten und Tests sollten vor dem Produktionswechsel abgeschlossen werden. Die Staging-Umgebung muss relevante Extensions, Runtime-Einstellungen, Infrastrukturverhalten und repräsentative Daten abbilden. Fehlerpfade und Wiederanlauf müssen ebenfalls geprüft werden. Danach sollte die Einführung schrittweise erfolgen und technische sowie fachliche Messwerte berücksichtigen.

Die Analyse verweist darauf, dass die PHP Foundation bereits 2024 frühe Hinweise auf das Out-of-Memory-Problem eingeräumt hat. Damals war noch kein konkreter Exploit-Weg bekannt. Als Gründe für die Verzögerung nennt sie unter anderem organisatorische und personelle Grenzen und beschreibt Änderungen an den Sicherheitsprozessen. Die veröffentlichten Fixes und die Dokumentation sind wichtige Schritte, beseitigen aber nicht die Wartungsverantwortung der Betreiber. Das geschäftliche Risiko liegt nicht nur in einer möglichen Kompromittierung. Problematisch ist auch, wenn ein Sicherheitspatch ohne ein kurzfristig gestartetes Modernisierungsprojekt nicht ausgerollt werden kann.