Am 21. Oktober 2026 veröffentlichte PHP Notfallupdates für CVE-2026-109618 und CVE-2026-109619. Beide Lücken haben einen CVSS-v4.0-Wert von 9,2 und können in betroffenen Umgebungen unauthentifizierte Remote Code Execution ermöglichen. Die Schwachstellen betreffen PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Bei mod_php stuft PHP das Risiko als besonders hoch ein, weil eine nicht authentifizierte Anfrage den fehlerhaften Ablauf vor dem Start des Anwendungscodes erreichen kann.

CVE-2026-109618 betrifft die Speicherverwaltung bei fehlgeschlagenen Allokationen. Komplexe Multipart-Anfragen, viele Header innerhalb von Teilen, verschachtelte Feldnamen und weitere vom Angreifer kontrollierte Speicheranforderungen können den Out-of-Memory-Pfad auslösen. Die anschließende Bereinigung kann Daten behandeln, die noch nicht vollständig initialisiert wurden. Der bestätigte Effekt ist Codeausführung unter dem Konto des Web-Workers.

CVE-2026-109619 entsteht durch Request-Zustand, der zu lange erhalten bleibt. Ein langlebiger Worker kann einen Zeiger auf Speicher behalten, der nach einer früheren Anfrage bereits freigegeben wurde. Eine spätere Anfrage trifft dann auf einen Use-after-free-Zustand. PHP bestätigte einen Angriffsweg über Fatal-Error-Backtraces in PHP 8.5 und einen weiteren über den Session-Upload-Fortschritt. Das zugrunde liegende Problem beschränkt sich nicht auf eine einzelne Einstellung oder Erweiterung.

Die Schwachstelle liegt im PHP-Laufzeitsystem und nicht zwingend in WordPress, Laravel, Magento oder einem Plugin. Eine aktualisierte Anwendung kann weiterhin ein verwundbares PHP-Binary verwenden. Der Fehler kann über ein kleines Skript, einen Health-Check, ein Login-Formular oder einen Upload-Endpunkt erreicht werden, bevor das Framework die Anfrage protokolliert. Cloudflare ordnet die Fehlerbilder der Verarbeitung von Speicher, Fehlern und Request-Zustand während HTTP-Anfragen zu.

Behoben sind die Versionen PHP 8.5.12, PHP 8.4.27, PHP 8.3.36 und PHP 8.2.35. PHP 8.1 und ältere Versionen erhalten vom PHP-Projekt keine Sicherheitskorrekturen mehr. Betriebssystem- und Long-Term-Support-Anbieter können Patches zurückportieren. Deshalb sind Paket-Changelog und Herstellerhinweis verlässlicher als die sichtbare Upstream-Versionsnummer.

Laut PHP Foundation zeigten sich erste Hinweise auf das Speicherproblem bei einem externen Audit im Jahr 2024. Calif, OpenAI und Wiz wiesen später einen verlässlichen Weg zur Codeausführung nach. Die Patches ändern die Behandlung von Out-of-Memory-Situationen und setzen einen größeren Bereich requestbezogener globaler Zustände zurück. Ein verzögerter Soft-Out-of-Memory-Pfad und eine sichere harte Prozessbeendigung verhindern die Verarbeitung ungültiger Zustände beim Aufräumen.

Das Einspielen der Paketdateien genügt nicht. Betreiber müssen das tatsächlich verwendete Laufzeitsystem und die Paketquelle jeder öffentlichen Anwendung ermitteln, ein korrigiertes Paket oder Container-Image installieren und Apache, PHP-FPM, CGI-Worker, FrankenPHP, LiteSpeed sowie andere langlebige PHP-Prozesse neu starten. Danach sollten Binary und Paket-Changelog geprüft werden. Tests müssen Uploads, Sessions, Queues und Hintergrundjobs abdecken. Vor der regulären Log-Rotation sind alte Protokolle zu sichern.

PHP bezeichnet die Aktualisierung als einzige vollständige Abhilfe. Bis dahin können konservative Request-Größen und Grenzen für Multipart-Strukturen die Angriffsfläche verringern. Das Vermeiden vorhersehbarer, vom Angreifer ausgelöster memory_limit-Fehler kann helfen. PHP warnt jedoch davor, RLIMIT_AS oder RLIMIT_DATA als Ersatz einzusetzen, weil diese Limits den problematischen Allokationsfehler auslösen können. session.upload_progress.enabled sollte administrativ deaktiviert und alle Worker sollten neu gestartet werden. Unter PHP 8.5 kommt fatal_error_backtraces hinzu. Diese Maßnahmen blockieren bestätigte Wege, decken aber nicht jede Variante des veralteten Request-Zustands ab.

Cloudflare meldete WAF-Regeln, die Anfrage- und Antwortsignale kombinieren. AWS beschrieb das Blockieren oder Erkennen bekannter Versuche. Solche Kontrollen sind zusätzliche Schutzschichten, ersetzen aber kein Runtime-Update. Wenn ein sofortiger Patch nicht möglich ist, sollte der Dienst über VPN, Allowlist oder eine authentifizierte Edge-Kontrolle abgeschirmt werden. Der Origin darf nicht direkt erreichbar sein. Unnötige Multipart-Uploads sollten ausfallen, nicht benötigte Geheimnisse aus dem Worker verschwinden und dessen Betriebssystem- sowie Netzwerkrechte begrenzt werden. Web-, PHP-, Proxy-, Prozess- und Authentifizierungslogs sind zu sichern.

Amazon Threat Intelligence meldete am 17. Oktober einen PHP2Shell-Ausnutzungsversuch gegen seinen MadPot-Honeypot, vier Tage vor der öffentlichen Bekanntgabe. Rund um die Veröffentlichung sah Amazon weitere Proof-of-Concept-Versuche aus unterschiedlicher anonymisierter Infrastruktur. Ob der frühere Versuch gegen ein echtes Ziel erfolgreich gewesen wäre, konnte Amazon nicht feststellen. Untersuchungen sollten daher am 17. Oktober beginnen oder mit dem frühesten Datum aus den eigenen Threat-Intelligence-Daten.

Die Suche sollte Prozessdaten, Reverse-Proxy- und PHP-Fehlerlogs, Endpoint-Detection-Daten sowie File-Integrity-Warnungen umfassen. Auffällig sind etwa Shells oder Netzwerkprogramme, die von Web-Workern gestartet werden, wiederholte memory_limit-Fehler, HTTP-500-Antworten, Abstürze, ungewöhnliche Neustarts und atypische Multipart-Anfragen. Ebenfalls relevant sind neue Dateien in Webroots, temporären Verzeichnissen oder Startpfaden, unerwartete ausgehende Verbindungen, neue Zugangsdaten oder geplante Aufgaben sowie Zugriffe auf Geheimnisse, Zertifikate oder Datenbanken außerhalb des normalen Anwendungsmusters. Ein unauffälliges Anwendungslog schließt Aktivitäten auf Runtime-Ebene nicht aus.

Die Reaktion beginnt mit einem Verzeichnis aller internetseitig erreichbaren PHP-Dienste. Dazu gehören Container, virtuelle Maschinen, Shared Hosting, Control Panels, Appliances, alte Subdomains, Staging-Systeme und von Dienstleistern verwaltete Installationen. Für jeden Eintrag sollten SAPI, Paketquelle, Patchstatus, Neustartmethode und Verantwortlicher festgehalten werden. Öffentlich erreichbares mod_php und PHP-FPM haben Vorrang, besonders bei Uploads. Bei verdächtiger Codeausführung ist der Host zu isolieren. Flüchtige Beweise sollten gesichert, offengelegte Zugangsdaten gedreht und Artefakte nicht einfach am Ort gelöscht werden.

PHP2Shell zeigt, dass auch Worker-Prozesse eigene Sicherheitsgrenzen brauchen. Die Ausnutzbarkeit hängt von PHP-Build, SAPI, Erweiterungen, Allocator, Frontend-Konfiguration, Worker-Wiederverwendung und Request-Pfad ab. Nicht jeder Server ist deshalb automatisch kompromittiert. Der Schutzstatus der Anwendung sagt über das Runtime-Risiko jedoch nichts aus. Runtime-Pakete, Worker-Rechte, ausgehender Netzwerkzugriff und Prozessstarts durch Web-Identitäten müssen regelmäßig überprüft werden.