PHP2Shell: Zwei kritische PHP-RCE-Lücken mit CVSS 9.2

Was ist passiert?

PHP korrigierte zwei kritische Fehler im Interpreter-Kern, die eine nicht authentifizierte Remotecodeausführung ermöglichen können. Sie sind unabhängig vom Framework und betreffen alle SAPIs, die Webanfragen verarbeiten: PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed.

CVE-2026-109618 nutzt einen OOM-Abbruch, während Anfrage-Speicher nur teilweise initialisiert ist; beim Shutdown kann beschädigter Zustand als gültig verarbeitet werden. CVE-2026-109619 ist ein requestübergreifender Use-after-Free: Ein globaler Wert kann nach der Freigabe noch auf Speicher einer früheren Anfrage zeigen.

Betroffene Versionen

Für PHP 8.2 bis 8.5 gibt es offizielle Korrekturversionen. PHP 8.1 und älter sind upstream EOL. PHP stellte minimale Quellcode-Backports für 7.4, 8.0 und 8.1 bereit, aber keine neuen offiziellen Binärreleases.

Warum Anwendungsupdates nicht reichen

Die Angriffswege liegen in Initialisierung, Parsing oder Cleanup einer PHP-Anfrage, bevor Anwendungscode läuft. Updates für WordPress, Drupal, Joomla, Laravel oder Sicherheitsplugins ersetzen kein PHP-Update.

• mod_php gilt als höchstes Risiko: Eine nicht authentifizierte Anfrage kann vor dem Anwendungscode angreifen.
• PHP-FPM ist nicht sicher. Die Quellcodeanalyse stützt die Anfälligkeit, und die verwandte Lücke wurde auf mod_php und FPM nachgewiesen.
• Ein Paketupdate ist nicht abgeschlossen, solange alte FPM-, Apache-, IIS- oder CLI-Worker den alten Code ausführen.
• Docker benötigt ein neues Image und einen neu erzeugten Container. docker restart startet weiterhin das alte Image.

Bestandsaufnahme

Ein passiver Scanner erfasste CLI, FPM, CGI, Apache-Module, Docker, Windows-Dienste, Erweiterungen und relevante INI-Werte. Anschließend wurde die Laufzeit hinter jedem echten Web-Einstiegspunkt geprüft, nicht nur ein einzelnes php -v.

• PATH, /www/server/php, /usr/local, /opt, FPM-Pools, Apache, IIS FastCGI, Registry und Container prüfen.
• Paketinstallationszeit mit Worker-Startzeit vergleichen, um installierte, aber nicht aktive Patches zu finden.
• Versteckte Banner, CDN und WAF senken die Exposition, beweisen aber keinen gepatchten Origin.
• Appliances, NAS-Systeme, Panels und eingebettetes PHP benötigen eigene Herstellerhinweise.

Sichere Behebungsreihenfolge

Nur das PHP-Update ist die vollständige Behebung. Die Reihenfolge gilt für Linux und Windows Server, einschließlich BT-Panel, IIS und Containern.

• Im Cloud- oder Hypervisor-Portal einen vollständigen Snapshot erstellen und PHP, SAPI, Erweiterungen, Dienste und Pools dokumentieren.
• PHP-Verzeichnis, php.ini, FPM-/Apache-/IIS-Konfiguration und Binärdateien sichern; das Rollback-Skript prüfen.
• Offizielles Release desselben Zweigs oder ein laut Distribution eindeutig korrigiertes Paket installieren.
• Bei Docker das korrigierte Image ziehen und den Container neu erzeugen. Nach Paketupdates FPM, Apache, IIS und dauerhaft laufende Worker vollständig neu starten.
• Login, Uploads, Zahlungen, Warteschlangen, Cache und kritische APIs testen und die tatsächliche Web-SAPI-Version prüfen.
• Bei vorheriger Internetexposition nach Webshells, unerwarteten Kindprozessen, neuen Aufgaben, ausgehenden Verbindungen und Zugriffen auf Zugangsdaten suchen.

Wenn ein sofortiger Patch nicht möglich ist

Konfigurationsmaßnahmen blockieren nur einzelne bekannte Wege und machen PHP nicht sicher. Patch und vollständiger Neustart aller Worker bleiben die einzige vollständige Behebung.

• CVE-2026-109618: memory_limit=-1 dort erzwingen, wo Anwendungen es nicht überschreiben können; post_max_size senken und Body-, Part-, Header- und Verschachtelungsgrenzen am Proxy setzen. RLIMIT_AS oder RLIMIT_DATA sind kein Ersatz.
• CVE-2026-109619: session.upload_progress.enabled=0 vor der Request-Initialisierung setzen und alle Worker neu starten; unter PHP 8.5 zusätzlich fatal_error_backtraces=0.
• .user.ini oder ini_set() nicht als zentrale Schutzmaßnahme verwenden; sie greifen für einige Pfade zu spät.
• Cloudflare WAF oder andere Edge-Regeln sind Defense in Depth und schützen nur darüber geleiteten Verkehr.

Rollback und Grenzen

Der bevorzugte Rollback ist immer der vollständige Maschinen-Snapshot. Die Server-Skripte erzeugen Berichte, Manifeste und Rollback-Dateien unter /root/php2shell-fullfix/<Zeitstempel>/ unter Linux beziehungsweise C:\ProgramData\PHP2ShellFullFix\<Zeitstempel>\ unter Windows.

Automatische Änderungen sind auf erkannte BT-Panel-PHP-Installationen, wenige Debian-Offiziell-Image-Container und offizielle Windows-PHP-ZIPs begrenzt. Unbekannte Quellbuilds, Distributionspakete und eingebettete Laufzeiten erhalten nur einen manuellen Pfad.

Werkzeuge für diesen Incident

Die Scanner inventarisieren nur Versionen und Konfiguration. Die Server-Skripte starten standardmäßig im Prüfmodus und verlangen vor Änderungen drei Bestätigungen.

SHA256-Prüfsummen

Primärquellen

Produktfakten stammen vorrangig aus PHP- und GitHub-Security-Advisories; Hinweise von CISA, CERT-EU, NCSC-NL und Cloud-Anbietern dienen der Gegenprüfung.

1. PHP official security advisory · 2026-10-21
2. CVE-2026-109618 · GHSA-w8hw-w9fx-j79w
3. CVE-2026-109619 · GHSA-6wmf-4rv5-p3rp
4. PHP 8.2.35 official release record
5. NCSC-NL · php2shell operational information
6. CISA CSAF/VEX · VA-26-295-01
7. Canadian Centre for Cyber Security · AL26-026
8. CERT-EU Security Advisory 2026-018
9. Cloudflare · php2shell WAF protection