Fragen und Antworten

Jedes Release vor 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Die Forschenden fanden betroffenen Code bis zurück zu PHP 5.4, und fast jede Version dazwischen ist von mindestens einer der beiden CVEs betroffen.

PHP 8.1, 8.0, 7.x und 5.x sind End-of-Life und erhalten kein neues Release. Das PHP-Team veröffentlichte minimale Quellcode-Backports für 7.4, 8.0 und 8.1 für alle, die PHP selbst bauen; OS-Hersteller mit verlängertem Support liefern eigene gepatchte Pakete.

Nein. Das waren die Demo-Ziele. Der Bug steckt im PHP-Interpreter, daher ist jede Website auf anfälligem PHP exponiert — Laravel, Symfony, Magento, Moodle, Nextcloud, MediaWiki, Eigenentwicklungen, sogar ein „Hello World“-Skript.

Nein. Die demonstrierten Angriffe funktionieren vor der Authentifizierung und über normale HTTP-Requests. Es braucht weder Login noch Plugin noch einen speziellen Endpunkt.

Beides. Apache mit mod_php ist am klarsten ausnutzbar (RCE für beide CVEs mit Standardlimits bestätigt). Auf PHP-FPM wurde RCE über den Session-Pfad bestätigt, und der OOM-Pfad ist laut Analyse anfällig. FrankenPHP und LiteSpeed LSAPI gelten als wahrscheinlich anfällig.

Die Advisories konzentrieren sich auf die Verarbeitung von Web-Requests. CLI-Skripte werden im Normalbetrieb nicht über HTTP erreicht, stammen aber aus demselben Paket und werden ohnehin aktualisiert. Langlaufende Worker, die Requests bedienen (Octane, RoadRunner, Swoole, FrankenPHP-Worker-Modus), sollten als webseitig behandelt werden.

Nicht unbedingt. Debian, Ubuntu, RHEL und SUSE portieren Security-Fixes zurück, ohne die Upstream-Version zu ändern (zum Beispiel 8.3.6-0ubuntu0.24.04.x). Suchen Sie CVE-2026-109618 im Changelog des Pakets — die Patch-Anleitung enthält die genauen Befehle.

Installieren Sie auf jeder Laufzeit ein gepatchtes PHP-Release (oder das gepatchte Paket Ihres Herstellers) und starten Sie danach PHP-FPM, Apache und alle langlaufenden PHP-Prozesse neu. Das ist die einzige vollständige Abhilfe. Anwendungs-Updates und Konfigurationsänderungen ersetzen sie nicht.

Wählen Sie einen gepatchten PHP-Build und lassen Sie den Worker-Neustart bestätigen. Fragen Sie bei PHP 8.1 oder älter nach einem Hersteller-Backport beider CVEs; die Versionsreihe allein belegt den Patchstatus nicht.

Prüfen Sie, ob Ihr OS-Hersteller (RHEL, Ubuntu Pro / ESM, Debian LTS, CloudLinux) ein gepatchtes Paket liefert — LTS-Anbieter erhielten die Fixes vorab. Wenn Sie PHP selbst bauen, spielen Sie den Quellcode-Backport des PHP-Teams für 7.4, 8.0 oder 8.1 ein. Setzen Sie in der Zwischenzeit die temporären Workarounds um, behalten Sie eine WAF davor und planen Sie die Migration auf 8.4 oder 8.5.

Teilweise. Cloudflare, Akamai, Imperva und andere haben Regeln oder Hinweise veröffentlicht, und Cloudflare deckt auch den Free-Plan ab. Die Abdeckung hängt aber vom Anbieter und Angriffspfad ab, und Angreifer verändern Payloads bereits, um sie zu umgehen. Betrachten Sie eine WAF als Zeitgewinn zum Patchen, nicht als Lösung.

Es handelt sich um Patch-Releases innerhalb desselben Branches, die Anwendungskompatibilität bleibt also normalerweise unberührt. Eine Verhaltensänderung: Das neue harte Speicherlimit beendet den Prozess sofort, sodass Shutdown-Funktionen in diesem Fall nicht laufen. Testen Sie speicherintensive Pfade.

Alles im Speicher des PHP-Workers: Datenbankpasswörter, API-Schlüssel, Session-Cookies, Request-Daten anderer Benutzer sowie Zertifikate oder Schlüssel, die PHP geladen hat. Dieser Pfad braucht keine Codeausführung und ist daher unauffälliger.

Cloudflare meldete am 21. Oktober 2026 erste Angriffe mit veränderten Payloads, um Regeln zu umgehen, und watchTowr meldete Ausnutzung in seinen Honeypots. Eine bestätigte Kompromittierung war nicht veröffentlicht. Das Embargo ist vor dem Release geplatzt — gehen Sie davon aus, dass fähige Angreifer funktionierende Exploits haben.

Nicht mit Sicherheit. Nützliche Signale sind fatale Memory-Limit-Fehler nach Multipart-Requests, Häufungen von HTTP 500, Segfaults von Workern und ungewöhnlich lange oder prozentkodierte PHPSESSID-Cookies. Ihr Fehlen beweist keine Sicherheit, und Anwendungslogs zeigen womöglich nichts, weil der Bug unterhalb der Anwendung läuft.

Logs sichern, den Host patchen oder isolieren (Neuaufbau aus einem sauberen Image ist am besten), jedes Geheimnis austauschen, das PHP im Speicher sehen konnte, Sessions invalidieren und prüfen, worauf diese Zugangsdaten Zugriff geben.

php2shell ist der Name des kombinierten Exploit-Skripts, mit dem Forschende Remote Code Execution ohne Authentifizierung auf WordPress, Drupal und Joomla gezeigt haben. Der Name wurde auch zum Namen der Forschung.

Wiz Research, OpenAI Codex Security und Calif, die zwischen August und September 2026 unabhängig voneinander meldeten, während das PHP-Security-Team den Fix entwickelte. Laut Wiz halfen KI-Modelle beim Finden, bei der Exploit-Entwicklung und der Patch-Validierung.

Die CVE-IDs wurden vor dem Release mit einem falschen Score von 10.0 geleakt. Der offizielle CVSS-4.0-Score beider CVEs ist 9.2.