PHP2Shell: Zwei kritische Remote-Code-Execution-Schwachstellen in PHP — was bekannt ist und wie man sich vorbereitet

Das PHP Security Team hat zwei kritische Schwachstellen mit einem CVSS v4.0 Score von 9.2 bekanntgegeben und ein außerplanmäßiges Security-Release für den 21. Oktober 2026 um 14:00 UTC angekündigt. Nach Angaben der Forscher von watchTowr ermöglichen beide Schwachstellen Remote Code Execution (RCE). Patches erhalten nur die vier unterstützten Branches — von 8.2 bis 8.5. Nach Berechnungen des Unternehmens Mallory laufen rund 884.000 aus dem Internet erreichbare Hosts auf veralteten PHP-Versionen und erhalten keinen Fix vom Vendor. Eine Ausnutzung in the Wild ist zum Zeitpunkt der Veröffentlichung nicht beobachtet worden, aber die Historie vergleichbarer PHP-Schwachstellen zeigt, dass Angriffe innerhalb von 24 Stunden nach Offenlegung der Details beginnen können.

Was über die Schwachstellen bekannt ist

Die offizielle PHP-Mitteilung bestätigt die Existenz zweier kritischer Schwachstellen, legt jedoch keine technischen Details, keine betroffenen Versionen und nicht einmal die CVE-Identifikatoren offen. Vollständige Informationen sollen mit dem Release veröffentlicht werden. Die Identifikatoren CVE-2026-109618 und CVE-2026-109619 tauchen in Veröffentlichungen von Forschern und in einem Leak auf Hacker News auf, werden aber in der PHP-Mitteilung selbst nicht genannt.

Hier ist es wichtig, bestätigte Fakten von unbestätigten Behauptungen zu trennen. Offiziell steht bislang Folgendes fest:

• Beide Schwachstellen wurden vom PHP Security Team mit CVSS v4.0 9.2 (Critical) bewertet
• Patches werden für die PHP-Branches 8.2, 8.3, 8.4 und 8.5 veröffentlicht
• Technische Details, einschließlich verwundbarer Komponente und Angriffsvektor, sind bisher nicht offengelegt

In einem Leak auf Hacker News vom 20. Oktober war eine Bewertung mit CVSS 10.0 und die Behauptung zu lesen, die Schwachstellen beträfen alle Versionen ab PHP 5. Allerdings stammt die 10.0-Bewertung aus einem nicht verifizierten Leak und ist keine offizielle Bewertung des Vendors. Wie watchTowr in seinem FAQ anmerkt, ist die genannte Spannweite „ab PHP 5“ durch keine offizielle Vendor-Mitteilung bestätigt; ebenso wenig sind die technischen Ursachen der Schwachstellen und Konfigurationsanforderungen für deren Ausnutzung geklärt.

Matrix der betroffenen Versionen und Umfang des Problems

Auf Basis der derzeit verfügbaren Daten ergibt sich folgendes Bild:

• Branches 8.2–8.5 — werden unterstützt und erhalten Patches. Nach Angaben von Mallory sind die gefixten Versionen: 8.2.35, 8.3.36, 8.4.27 und 8.5.12 (diese Versionsnummern stammen von Mallory, nicht aus der offiziellen PHP-Mitteilung)
• PHP 8.1 und älter — Branches, die das Ende ihres Lebenszyklus (End of Life) erreicht haben, erhalten keinen Vendor-Patch
• PHP 5 und neuer — nicht bestätigter Versionsbereich der Schwachstellen aus dem Leak

Gerade der letzte Punkt sorgt für die größte Unsicherheit. Sollten die Schwachstellen tatsächlich Versionen bis hinunter zu PHP 5 betreffen, würde sich der Umfang des Problems deutlich vergrößern. Nach Berechnungen von Mallory laufen von rund 1,5 Millionen aus dem Internet erreichbaren Hosts, die ihre PHP-Version über HTTP-Banner in Shodan preisgeben, 883.717 (59 %) auf Branches, die keine Fixes erhalten. Weitere 740.000 Hosts geben die Präsenz von PHP ohne Versionsangabe an. Diese Zahlen spiegeln Banner wider, nicht verifiziert verwundbare Systeme oder eindeutige Organisationen, weisen aber auf ein erhebliches potenzielles Ausmaß der Auswirkungen hin.

Status der Ausnutzung

Nach Angaben von watchTowr ist mit Stand 21. Oktober 2026 keine Ausnutzung in the Wild beobachtet worden. Huntress berichtet, dass bis einschließlich 20. Oktober weder Ausnutzung in den Umgebungen seiner Partner beobachtet, noch ein Proof of Concept reproduziert oder Informationen über öffentlichen Exploit-Code erhalten wurden. Die Schwachstellen sind nicht im CISA-Katalog der Known Exploited Vulnerabilities aufgeführt. Bestätigte Indicators of Compromise (IOC) liegen zum Zeitpunkt der Veröffentlichung ebenfalls nicht vor.

Das Ausbleiben beobachteter Ausnutzung ist allerdings nur eine Momentaufnahme. Zum Vergleich: Als im Juni 2024 CVE-2024-4577 (eine PHP-Schwachstelle im CGI-Modus unter Windows) offengelegt wurde, registrierte Akamai innerhalb von 24 Stunden Exploit-Versuche auf Honeypots.

Chronologie des Leaks und der Reaktionen

Die Situation entwickelte sich auf ungewöhnliche Weise. Am 20. Oktober erschien auf Hacker News ein Post mit Informationen über zwei RCE-Schwachstellen in PHP, angeblich mit einem CVSS-Score von 10.0, unter Nennung der CVE-Identifikatoren und mit einem Offenlegungsdatum — dem 22. Oktober (Donnerstag). Der Autor des Posts räumte ein, dass seine Quelle „trust me, bro“ sei. Daraufhin bestätigte watchTowr auf X, dass das Leak real sei, die Schwachstellen unter Embargo stünden und alle bis Donnerstag warten müssten. PHP veröffentlichte seine Mitteilung noch am selben Abend um 19:33 UTC und setzte den Release für Mittwoch an — einen Tag früher als das im Leak genannte Datum. Die Mitteilung enthält den Hinweis, dass der Release vorgezogen werden kann, falls Details zu den Schwachstellen öffentlich werden oder Hinweise auf aktive Ausnutzung auftauchen.

Das Leak offenbarte die Existenz der Schwachstellen, deren Bewertung, das Datum und die CVE-Identifikatoren, aber nicht den technischen Mechanismus der Schwachstellen. Das ist ein wichtiger Unterschied: Die Informationen im Leak reichten nicht aus, um einen Exploit zu entwickeln.

Praktische Empfehlungen

PHP hat keine Workarounds veröffentlicht. Bis zum Erscheinen der Patches wird folgendes Vorgehen empfohlen, basierend auf den Empfehlungen von Huntress und CERT-EU:

1. Inventarisierung: Erfassen Sie alle PHP-Installationen, einschließlich eingebettetem PHP in Vendor-Appliances, Windows-Anwendungen und Administrationspanels (cPanel, Plesk)
2. Update-Bereitschaft: Bereiten Sie sich darauf vor, den Patch unmittelbar nach Veröffentlichung des Releases zu installieren. Internet-exponierte Systeme haben Priorität. Prüfen Sie, ob Ihr Linux-Distribution oder Hosting-Provider Backport-Pakete bereitstellt
3. Veraltete Versionen: Systeme mit PHP 8.1 und älter müssen aktualisiert, vom Internet getrennt oder hinter einem VPN beziehungsweise WAF betrieben werden
4. Isolation: CERT-EU empfiehlt, in Betracht zu ziehen, internet-exponierte PHP-Anwendungen bis zur Verfügbarkeit eines Fixes von öffentlichen Netzen zu isolieren
5. Prozess-Monitoring: Richten Sie Alarme ein, wenn php-fpm, php-cgi, httpd oder apache2 Shells, Interpreter oder Download-Werkzeuge starten. Auf Linux-Servern ohne EDR kann process-watcher von Florian Roth eingesetzt werden — das Tool protokolliert jedes Programm mit Befehlszeile, das von einem PHP-Prozess gestartet wird. Wichtig: Es erfasst Prozesse erst nach deren Start und, so der Autor, „verhindert nichts“
6. Reaktion auf den Vorfall: Bei Anzeichen verdächtiger Aktivitäten sollten Sie den Server isolieren, Webserver- und PHP-Logs sichern, auf Webshells prüfen, nach neuen Dateien im Webroot sowie nach neuen Cron-Jobs und Benutzerkonten suchen

Die Priorisierung des Patchens sollte berücksichtigen, dass Systeme auf veralteten PHP-Branches (8.1 und älter) keinen Vendor-Fix erhalten. Laut Mallory gibt es rund 884.000 aus dem Internet erreichbare Hosts in dieser Kategorie. Für diese Systeme bleiben nur die Optionen: Upgrade auf einen unterstützten Branch, Einschränkung des Netzwerkzugriffs oder Betrieb hinter einem WAF. Organisationen auf unterstützten Branches (8.2–8.5) müssen den Patch unmittelbar nach seiner Veröffentlichung installieren, beginnend mit den internet-exponierten Servern.

Der Release sollte die zentralen offenen Punkte klären: welche Versionen genau betroffen sind, welche PHP-Komponente die Schwachstelle enthält, ob für die Ausnutzung ein bestimmter PHP-Betriebsmodus oder eine spezielle Konfiguration erforderlich ist und wie der Vendor selbst die Schwachstellen beschreibt. Bis dahin sind alle Maßnahmen präventiver Natur, und der kritischste Schritt besteht darin, die Bereitschaft für ein sofortiges Update der unterstützten Branches sicherzustellen und Systeme mit veralteten PHP-Versionen zu isolieren oder außer Betrieb zu nehmen.