Kritische PHP-Lücken: kein Patch, kein Workaround

Für Mittwoch, den 21. Oktober 2026, 14:00 UTC ist ein außerplanmäßiges Security-Release angekündigt. Es soll zwei kritische PHP-Lücken schließen, die mit CVSS v4.0 9.2 bewertet sind und nach derzeitigem Stand Remote Code Execution erlauben. Zum Redaktionsschluss lag kein Patch vor; betroffene Versionen, technische Details und Fix-Versionen sollen erst mit dem Release veröffentlicht werden, Workarounds wurden vorab nicht genannt. Auslöser der Eile ist ein Leak: Am 20. Oktober brach eine öffentliche Offenlegung das Embargo, Screenshots kursierten auf X und Mastodon.

PHP-Lücken: Was bestätigt ist und was aus dem Leak stammt

Geführt werden die beiden Schwachstellen als CVE-2026-109618 und CVE-2026-109619. Beide IDs sind nicht offiziell bestätigt; CVE-Nummern sind nicht offiziell vergeben, die Zuordnung zu den zwei Lücken ist nicht bestätigt. Wer die Kennungen in Scannern, Tickets oder Asset-Datenbanken führt, sollte diesen Unterschied kennen: offiziell vergeben sind sie nicht.

Auch der Scope ist offen. CVSS 10.0, Betroffenheit „ab PHP 5" und eine Offenlegung am 22. Oktober sind unbelegt; Belege jenseits von „source: trust me, bro" gibt es nicht. Offiziell bewertet sind 9.2, ein Versionsbereich ist nicht bestätigt. Der interne Name „php2shell" wiederum ist nicht offiziell. Es handelt sich um echte, unter Embargo stehende RCE-Lücken: „we can confirm that they’re real". Die kursierenden Screenshots fanden öffentlich Beachtung.

883.717 Hosts ohne Vendor-Fix: Was die 59-Prozent-Zahl bedeutet

Für den 20. Oktober 2026 sind rund 1,5 Millionen internetseitig erreichbare Hosts mit PHP-Banner erfasst. 883.717 davon – 59 Prozent – laufen auf einem Branch, der keinen Vendor-Patch erhält. Rund 740.000 weitere Hosts melden PHP ohne Versionsangabe und lassen sich keiner Branch zuordnen. Aufgeschlüsselt entfallen 368.570 Hosts auf PHP 5.x, 329.358 auf PHP 7.x und 185.789 auf PHP 8.0/8.1 – zusammen exakt die 883.717. Weitere 612.269 Hosts laufen auf PHP 8.2 bis 8.5 und dürfen mit einem Fix rechnen. Zählt man alle Antworten mit „X-Powered-By: PHP" zusammen, kommt man auf 2.237.277 Systeme.

Bei den Ländern liegt Deutschland mit 45.835 unversorgten Hosts bei 41 Prozent. Spitzenreiter sind die USA mit 228.770 (54 Prozent), China mit 67.306 (75 Prozent) und Algerien mit 31.306 (100 Prozent). Bei den Providern führt Amazon mit über 290.000 betroffenen Bannern, gefolgt von Hostinger (142.401), Alibaba Cloud (81.078), Hetzner (51.354), DigitalOcean (47.105) und OVH (36.848).

Zwei Einschränkungen gehören zu diesen Zahlen. Erstens sind es Banner-Zählungen, keine bestätigt verwundbaren Systeme: Welche Version tatsächlich läuft und ob die betroffene Funktion erreichbar ist, lässt sich aus einem Banner nicht ableiten. Zweitens bündelt Shared Hosting viele Websites pro IP-Adresse – die Zahl betroffener Websites liegt also deutlich höher als die der Hosts.

Welche PHP-Versionen noch Patches bekommen

Fixes erhalten ausschließlich die vier unterstützten Branches PHP 8.2, 8.3, 8.4 und 8.5. Der Support-Status im Detail: 8.5 wird aktiv bis 31. Dezember 2027 versorgt, 8.4 bis 31. Dezember 2026, 8.3 erhält nur noch Security-Fixes bis 31. Dezember 2027, 8.2 nur noch Security-Fixes bis 31. Dezember 2026. Die aktuellen Releases vom 24. September 2026 – 8.5.11, 8.4.26, 8.3.35 und 8.2.34 – stammen alle aus der Zeit vor dem Fix.

Erwartet werden die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Diese Nummern sind nicht bestätigt. End of Life sind PHP 8.1 und älter, PHP 8.0 sowie die 7.x- und 5.x-Reihe; sie bekommen keinen Vendor-Patch. Ob 8.0 und 8.1, die im September kein Release erhielten, ausnahmsweise noch versorgt werden, ist offen.

Was Betreiber jetzt tun können

Der Fix erscheint am 21. Oktober um 14:00 UTC. Ein früherer Zeitpunkt bleibt vorbehalten, „should details of either vulnerability become public, or should evidence of active exploitation appear in the wild". Bis dahin empfiehlt es sich, internetseitig erreichbare Anwendungen von öffentlichen Netzen zu isolieren. Wer auf einem EOL-Branch sitzt, kann nicht patchen, sondern nur migrieren oder isolieren; ein Notfall-Change-Fenster direkt nach dem Release ist für 8.2 bis 8.5 die einzige belastbare Option.

Für Erkennung statt Abwehr steht ein process-watcher bereit, der von PHP-Prozessen gestartete Programme protokolliert. Er greift erst, wenn Ausführung bereits stattfindet, und verhindert nichts – als Detektionspflaster für ein nicht patchbares System ist das brauchbar, als Schutz nicht.

Bis zum 20. Oktober war keine Ausnutzung und kein öffentlicher Proof-of-Concept bekannt; auffindbarer Exploit-Code existierte nicht. Das ist eine Momentaufnahme vom Tag vor dem Release – mit dem Patch steigt erfahrungsgemäß das Interesse an Reverse Engineering.

Einordnung: Warum bis zum Release vieles offen bleibt

Die Zeitleiste ist widersprüchlich. Genannt sind der 22. Oktober, der 21. Oktober, 14:00 UTC und der ursprüngliche Embargo-Termin „Thursday at 11 am ET". Dazu kommt die Differenz beim Score: 10.0 gegen 9.2. Wer eine Risikobewertung schreibt, sollte den Vendor-Score verwenden und den Rest als unbestätigt führen, statt die höhere Zahl zu übernehmen, weil sie dramatischer klingt.

Unklar bleibt auch, unter welchen Voraussetzungen sich die Lücken ausnutzen lassen. Dass sie unauthentifiziert erreichbar sind, stützt sich bislang allein auf den Schweregrad; benötigte Funktion, Extension, Konfiguration und Authentifizierungsbedarf sind nicht benannt. Für Sysadmins heißt das: Die Dringlichkeit ist hoch, das konkrete Angriffsszenario aber noch nicht beschrieben.

Für Betreiber bleibt es dabei: Wer 8.2 bis 8.5 fährt, sollte das Release am Mittwoch unmittelbar einplanen und die eigene Asset-Liste vorher prüfen. Wer ältere Branches betreibt, hat keine Patch-Perspektive und sollte Isolation als Dauerzustand bewerten, nicht als Übergangslösung. Der einzige Vorteil der Lage: Das Zeitfenster vor dem Fix lässt sich für eine ehrliche Bestandsaufnahme nutzen.

Quellen