Das PHP-Sicherheitsteam hat für den 21. Oktober 2026 um 14:00 Uhr UTC eine außerplanmäßige Sicherheitsveröffentlichung angekündigt. Sie soll zwei kritische Schwachstellen mit einem CVSS-v4.0-Wert von jeweils 9,2 schließen. Sicherheitsforscher führen die Lücken als CVE-2026-109618 und CVE-2026-109619 und bezeichnen sie gemeinsam als „PHP2Shell“. Nach Angaben von watchTowr ermöglichen beide Fehler die Ausführung von Code aus der Ferne.
Offizielle Korrekturen sind nur für die unterstützten PHP-Zweige 8.2, 8.3, 8.4 und 8.5 vorgesehen. Für PHP 8.1 und ältere Versionen wird es keinen Hersteller-Patch geben. Gerade dort liegt das operative Problem: Betreiber können ein End-of-Life-System nicht einfach aktualisieren, sondern müssen auf einen unterstützten Zweig wechseln oder die Anwendung bis dahin vom öffentlichen Netz trennen.
Noch fehlen allerdings entscheidende technische Angaben. PHP hatte vor der Veröffentlichung weder den betroffenen Programmteil noch konkrete Versionsgrenzen, notwendige Konfigurationen oder mögliche Authentifizierungsvoraussetzungen genannt. Auch eine aktive Ausnutzung wurde mit Stand vom 21. Oktober nicht bestätigt.
Die Warnung kam nach einem vorzeitigen Leak
Auslöser der beschleunigten Veröffentlichung war ein Beitrag vom 20. Oktober, der zwei PHP-RCE-Lücken, einen Veröffentlichungstermin und die beiden CVE-Kennungen vorzeitig nannte. In diesem Leak war von einem CVSS-Wert von 10,0 und einer Betroffenheit aller Versionen seit PHP 5 die Rede. Beides war zu diesem Zeitpunkt nicht durch eine Herstellerinformation belegt.
watchTowr bestätigte anschließend, dass die Schwachstellen real und eigentlich noch unter Embargo waren. Nach den verifizierten Angaben konnte das Unternehmen CVE-2026-109618 reproduzieren. Das ist jedoch nicht mit einem öffentlich verfügbaren Proof of Concept oder beobachteten Angriffen gleichzusetzen. Öffentlicher Exploit-Code war zunächst nicht bekannt.
PHP veröffentlichte seine Vorabwarnung am 20. Oktober um 19:33 Uhr UTC und zog die Sicherheitsfreigabe damit auf Mittwoch vor. Der Hersteller behielt sich zudem eine noch frühere Veröffentlichung vor, falls technische Details bekannt oder Angriffe beobachtet würden. Der belastbare Schweregrad stammt von PHP: 9,2 nach CVSS 4.0. Die im Leak genannte Bewertung von 10,0 ist nicht die offizielle Einstufung.
Die Patch-Grenze verläuft zwischen 8.2 und 8.1
PHP 8.2 bis 8.5 können offizielle Korrekturen erhalten. Vor der außerplanmäßigen Freigabe waren dies PHP 8.5.11, 8.4.26, 8.3.35 und 8.2.34. Mehrere Sicherheits-Tracker erwarteten die Fixes in den Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. PHP hatte diese konkreten Versionsnummern zum Zeitpunkt der Vorabwarnung aber noch nicht bestätigt. Betreiber sollten deshalb die veröffentlichte Herstellerinformation sowie die Pakete ihrer Linux-Distribution oder ihres Hosting-Anbieters prüfen.
Patch-Lage der PHP-Versionen
Die Grafik trennt unterstützte PHP-Zweige mit angekündigten Sicherheitsfixes von End-of-Life-Versionen ohne offiziellen PHP-Patch.
PHP 8.1, 8.0, 7.x und 5.x sind nicht mehr im Support. Sollte die offizielle Analyse bestätigen, dass die Fehler bis in diese Zweige zurückreichen, bleiben entsprechende Installationen ohne PHP-eigenen Fix. Die Behauptung, sämtliche Versionen seit PHP 5 seien betroffen, ist bis zur Herstellerveröffentlichung dennoch nur eine unbestätigte Reichweitenangabe.
Wie groß der Altbestand ist, lässt sich nur näherungsweise bestimmen. Das Sicherheitsunternehmen Mallory zählte am 20. Oktober rund 884.000 öffentlich erreichbare Hosts, deren HTTP-Banner bei Shodan PHP 8.1 oder älter auswies. Das entsprach 59 Prozent der etwa 1,5 Millionen Hosts mit sichtbarer Versionsangabe. Weitere rund 740.000 Hosts meldeten PHP ohne Versionsnummer. Solche Banner belegen weder die tatsächliche Version zuverlässig noch eine Verwundbarkeit, zeigen aber, wie groß der zu prüfende Bestand sein kann.
RCE ist bestätigt, der konkrete Angriffspfad noch nicht
Remote Code Execution beschreibt die technische Auswirkung: Gelingt die Ausnutzung, kann ein Angreifer Code im Kontext des betroffenen PHP-Prozesses ausführen. Noch offen ist, ob dafür eine bestimmte Betriebsart wie CGI oder PHP-FPM, eine besondere Konfiguration, eine verwundbare Funktion oder eine Anmeldung erforderlich ist. Diese Voraussetzungen entscheiden darüber, welche öffentlich erreichbaren Anwendungen tatsächlich angreifbar sind.
Entsprechend ist die Lage ernst, aber nicht mit einer laufenden Angriffswelle gleichzusetzen. Huntress hatte bis zum 20. Oktober keine Ausnutzung in den überwachten Partnerumgebungen festgestellt und keinen öffentlichen Exploit nachgebaut. Auch watchTowr meldete zunächst keine beobachteten Angriffe. Die CVEs standen zudem nicht in CISA's Katalog der nachweislich ausgenutzten Schwachstellen.
Die verbleibende Reaktionszeit kann trotzdem kurz sein. Bei CVE-2024-4577, einer anderen PHP-Schwachstelle im CGI-Betrieb unter Windows, registrierte Akamai innerhalb von 24 Stunden nach der Veröffentlichung erste Versuche gegen Honeypots. Das ist kein Beleg für einen vergleichbaren Verlauf bei PHP2Shell, zeigt aber, warum öffentlich erreichbare PHP-Systeme unmittelbar nach Bereitstellung der Fixes priorisiert werden sollten.
Was Betreiber jetzt konkret tun sollten
Der erste Schritt ist ein vollständiges Inventar. Dazu gehören nicht nur selbst betriebene Webserver, sondern auch PHP-Installationen in Hosting-Panels wie cPanel oder Plesk, Windows-Anwendungen, Appliances und von Drittanbietern gelieferte Softwarepakete. Gerade eingebettete Laufzeitumgebungen werden bei regulären Serverinventuren leicht übersehen.
Unterstützte Systeme sollten nach Freigabe der bestätigten Pakete zuerst aktualisiert werden, wenn sie aus dem Internet erreichbar sind. Bei Linux-Systemen können Distributionen Korrekturen in eigene Pakete zurückportieren. Maßgeblich ist deshalb nicht allein die sichtbare PHP-Versionsnummer, sondern auch der Sicherheitsstatus des jeweiligen Distributionspakets.
Für End-of-Life-Versionen bleiben drei belastbare Optionen: auf einen unterstützten PHP-Zweig migrieren, den Dienst vorübergehend aus dem öffentlichen Netz nehmen oder den Zugriff auf vertrauenswürdige Netze beziehungsweise ein VPN begrenzen. CERT-EU empfiehlt bei nicht sofort patchbaren, internetseitig erreichbaren Anwendungen eine Isolation. Eine Web Application Firewall kann eine zusätzliche Barriere bilden, ersetzt ohne Kenntnis des genauen Angriffspfads aber keinen Patch.
Bis technische Indikatoren verfügbar sind, sollten Betreiber ungewöhnliche Kindprozesse von php-fpm, php-cgi, httpd oder apache2 überwachen. Verdächtig sind insbesondere gestartete Shells, Interpreter und Download-Werkzeuge. Wird ein möglicher Einbruch entdeckt, reicht das nachträgliche Patchen nicht: Der Server sollte isoliert, Web- und PHP-Protokolle sollten gesichert und Webroot, Cronjobs, geplante Aufgaben sowie neu angelegte Konten sollten untersucht werden.
PHP2Shell ist damit zunächst weniger eine Geschichte über einen fertigen Massenexploit als über die Patch-Fähigkeit realer Webinfrastruktur. Bei unterstützten Zweigen ist die Aufgabe ein priorisiertes Update. Bei alten Laufzeitumgebungen wird aus demselben Fehler dagegen ein Migrations- und Isolationsproblem – und genau diese Systeme lassen sich oft nicht innerhalb eines Wartungsfensters ersetzen.
Jens analysiert seit Jahren digitale Märkte, Preisbewegungen und Plattform-Strategien. Als Betreiber mehrerer datengetriebener Systeme wertet er täglich große Mengen an Produkt- und Trenddaten aus. Sein Fokus liegt auf Einordnung statt Hype: Was bedeutet eine Entwicklung wirklich für Nutzer, Preise und Märkte?
