PHP2Shell-Update für zwei kritische PHP-RCE-Schwachstellen angesetzt
PHP2Shell ist der Name, den Sicherheitsforscher zwei kritischen PHP-Schwachstellen gegeben haben, die laut watchTowr remote code execution (RCE) ermöglichen können. Das bedeutet, dass ein Angreifer möglicherweise von einem anderen Ort aus Befehle auf einem anfälligen Server ausführen kann. PHP setzte für den 21. Oktober um 14:00 UTC ein außerplanmäßiges Sicherheitsrelease an und bewertete beide Schwachstellen gemäß Version 4.0 des Common Vulnerability Scoring System (CVSS), einer Standardskala zur Bewertung des Schweregrads von Schwachstellen, mit 9,2. Zum Zeitpunkt der Abfassung war das Update noch nicht veröffentlicht worden, und PHP hatte weder die betroffenen Versionen noch die technische Ursache, die erforderliche Konfiguration oder die korrigierten Versionen bekannt gegeben.
Die Notfallmitteilung folgte auf einen Beitrag vom 20. Oktober auf Hacker News, in dem behauptet wurde, zwei RCE-Schwachstellen beträfen jede PHP-Version ab PHP 5. Der Beitrag vergab einen CVSS-Wert von 10,0, nannte den 22. Oktober als erwartetes Datum der Offenlegung und lieferte keine Belege. watchTowr erklärte anschließend, die unter Embargo stehenden Schwachstellen existierten tatsächlich, veröffentlichte jedoch keine technischen Details. PHP veröffentlichte am selben Abend um 19:33 UTC eine eigene Mitteilung und setzte das Update einen Tag früher an als das im Leak genannte Datum. In der Mitteilung hieß es außerdem, das Release könne vorgezogen werden, falls Details zu den Schwachstellen öffentlich würden oder Hinweise auf aktive Angriffe auftauchten.
Sicherheitsforscher verwenden die Identifikatoren CVE-2026-109618 und CVE-2026-109619, die beide in dem geleakten Beitrag genannt wurden. In der Mitteilung von PHP wurde keiner der beiden Identifikatoren genannt, sodass ihre offizielle Zuordnung zu den Schwachstellen dort nicht bestätigt worden war. Auch die Behauptung aus dem Leak, dass alle Releases seit PHP 5 anfällig seien, war unbestätigt. Auf der FAQ-Seite von watchTowr hieß es, kein offizielles Vendor Advisory habe einen solchen Umfang festgestellt, und es sei keine erforderliche PHP-Funktion oder Konfiguration beschrieben worden. Auch die Bezeichnung PHP2Shell stammt von Sicherheitsforschern und nicht von PHP.
Nur die vier unterstützten PHP-Branches 8.2 bis 8.5 kommen für Fixes infrage. Vor dem Release zitierte Tracker erwarteten Updates mit den Versionsnummern PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, doch PHP hatte diese Versionen nicht bestätigt. Mit Stand vom 24. September waren 8.5.11, 8.4.26, 8.3.35 und 8.2.34 die aktuellen Releases. PHP 8.5 befand sich bis zum 31. Dezember 2027 im aktiven Support, PHP 8.4 bis zum 31. Dezember 2026. PHP 8.3 erhielt bis zum 31. Dezember 2027 ausschließlich Sicherheitsupdates und PHP 8.2 bis zum 31. Dezember 2026.
PHP 8.1, 8.0, alle 7.x-Releases und alle 5.x-Releases sind end of life. Das bedeutet, dass PHP für sie keine Sicherheitsupdates mehr bereitstellt. Falls letztlich bestätigt wird, dass die Schwachstellen diese Branches betreffen, erhalten Installationen, die sie weiterhin verwenden, keinen Vendor-Patch. Dies ist besonders für ältere Websites, Hosting-Konten, Control Panels, Geräte von Drittanbietern und Windows-Anwendungen relevant, die möglicherweise eine integrierte PHP-Installation enthalten, welche Administratoren nicht routinemäßig sehen.
Das Sicherheitsunternehmen Mallory zählte am 20. Oktober rund 884.000 aus dem Internet erreichbare Hosts, deren HTTP banner – die Identifikationsinformationen, die ein Webserver offenlegen kann – gegenüber der Suchmaschine Shodan PHP 8.1 oder älter auswies. Dies entsprach 59 Prozent der rund 1,5 Millionen Hosts, die eine PHP-Version offenlegten. Weitere 740.000 Hosts meldeten die Verwendung von PHP, gaben jedoch keine Version preis. Diese Zahlen beschreiben sichtbare Banners und keine Systeme, bei denen bestätigt wurde, dass sie eine der beiden PHP2Shell-Schwachstellen enthalten. Daher lässt sich daraus nicht die Zahl der betroffenen Server ableiten.
PHP hatte vor dem geplanten Release keinen Workaround veröffentlicht. Huntress empfahl, jede PHP-Installation zu ermitteln, einschließlich der in Geräten, Windows-Software, cPanel und Plesk enthaltenen Kopien, und sich anschließend darauf vorzubereiten, zuerst die aus dem Internet erreichbaren Systeme zu aktualisieren. Administratoren sollten außerdem prüfen, ob ihre Linux-Distribution oder ihr Hosting-Anbieter ein backported package bereitstellt, das eine Sicherheitskorrektur auf ein älteres paketiertes Release anwendet, ohne es durch das neueste vollständige Release zu ersetzen. Systeme auf einem Branch mit dem Status end of life sollten aktualisiert, aus dem öffentlichen Internet entfernt oder hinter einem Virtual Private Network oder einer web application firewall platziert werden, bis sie aktualisiert werden können. CERT-EU empfahl zusätzlich, eine Isolierung öffentlich erreichbarer Anwendungen von öffentlichen Netzwerken in Betracht zu ziehen, solange kein Fix verfügbar war.
Monitoring kann helfen, verdächtige Aktivitäten zu erkennen, ersetzt jedoch nicht das Patchen. Administratoren wurde geraten, Warnmeldungen auszulösen, wenn php-fpm, php-cgi, httpd oder apache2 Command Shells, Interpreter oder Download-Utilities startet. Eine von einem Sicherheitsforscher veröffentlichte Process-Watcher-Utility kann unter Linux jedes von einem PHP-Prozess gestartete Programm zusammen mit seiner Command Line aufzeichnen. Sie erfasst ein Programm jedoch erst, nachdem dessen Ausführung begonnen hat, und blockiert es nicht. Falls verdächtige Aktivitäten festgestellt werden, sehen die Empfehlungen vor, den Server zu isolieren, die PHP- und Webserver-Logs zu sichern und nach web shells – bösartigen Dateien, die eine Fernsteuerung des Servers ermöglichen – sowie nach unerwarteten Dateien im Website-Verzeichnis, neuen cron jobs, geplanten Tasks oder Accounts zu suchen.
Huntress erklärte, dass das Unternehmen mit Stand vom 20. Oktober in Partnerumgebungen keine Ausnutzung beobachtet, kein proof of concept erstellt oder reproduziert und keine Kenntnis von öffentlich verfügbarem Exploit-Code gehabt habe. Auch watchTowr führte mit Stand vom 21. Oktober keine gemeldete Ausnutzung auf und erklärte, die Schwachstellen seien nicht im Known Exploited Vulnerabilities Catalog der US Cybersecurity and Infrastructure Security Agency enthalten. Dieser Status könnte sich ändern, sobald technische Details verfügbar werden. Zum Vergleich: Akamai beobachtete im Juni 2024 innerhalb von 24 Stunden nach der Veröffentlichung von CVE-2024-4577 Versuche, diese separate PHP-Schwachstelle, die den CGI mode unter Windows betrifft, gegen seine Honeypot-Systeme auszunutzen.
Von dem offiziellen Release wurde erwartet, dass es klärt, welche Versionen anfällig sind, welche PHP-Komponente betroffen ist, ob die Ausnutzung von einem bestimmten Betriebsmodus, einer Konfiguration oder einem Login abhängt und welche Releases die Fixes enthalten. Website-Betreiber sollten ihren Hosting-Anbieter oder Administrator bitten, den installierten PHP-Branch und den Update-Status zu bestätigen, statt sich auf einen unbestätigten Versionsbereich zu verlassen. Für Betreiber von WordPress-Websites, die einen Managed Service suchen, bietet AEU Hosting vollständig verwaltetes und durchgängig abgesichertes WordPress Hosting an. Bis PHP das endgültige Advisory veröffentlicht, bleibt das genaue Ausmaß der Gefährdung ungewiss. Nicht unterstützte PHP-Installationen müssen jedoch bereits jetzt aktualisiert oder isoliert werden, da sie keinen Vendor-Fix erhalten können.