Cloudflare-Chef Matthew Prince berichtete auf X, sein Unternehmen habe in den zehn Stunden vor der öffentlichen Bekanntgabe der Schwachstellen am Mittwoch bereits Tausende Ausnutzungsversuche beobachtet. „Das stieg in den 45 Minuten nach der Ankündigung auf Zehntausende, innerhalb von zwei Stunden auf Hunderttausende und inzwischen auf Millionen", schrieb er spät am 21. Oktober.

Am Tag darauf erklärte Check Point Research, Ausnutzungsversuche hätten bereits zehn Prozent der Organisationen weltweit erreicht. Dem steht nur ein kleiner Anteil sichtbar aktualisierter Systeme gegenüber.

Forscher von Ox Security nutzten über Shodan auffindbare Installationen als Stichprobe und stellten fest, dass 24 Stunden nach Verfügbarkeit der korrigierten Fassungen mehr als 99 Prozent der Instanzen keine gepatchte Version auswiesen. Forscher von Flare ergänzten, dass 73 Prozent dieser Instanzen PHP-Zweige anzeigten, die von der PHP Foundation keine Aktualisierungen mehr erhalten. Flare schränkte die Zahlen zugleich ein: Einfaches Internet-Scanning übersehe wichtige Feinheiten.

Cisco Talos schätzte auf Basis offener Quellen (OSINT), dass rund die Hälfte aller PHP-Systeme überhaupt keine Patches erhalten wird.

Am Morgen des 23. Oktober (US-Ostküstenzeit) teilte Ox mit, der Wert von 99 Prozent sei auf 97,5 Prozent gesunken. Flare gab an, von den 27 Prozent öffentlich sichtbarer Einträge mit noch unterstützten Zweigen seien etwa fünf Prozent aktualisiert worden.

Schritt eins: PHP überhaupt finden

Einig sind sich die Fachleute darin, dass Organisationen zuerst sämtliche Systeme mit PHP erfassen und inventarisieren müssen. Das ist leichter gesagt als getan. Die US-Behörde CISA wies in einer Sicherheitswarnung vom 21. Oktober darauf hin, dass PHP nicht nur Websites betreibt, sondern „oft Bestandteil anderer Software ist und die Verbreitung möglicherweise nicht direkt erkennbar" sei.

Flare beobachtete das bei der Untersuchung der Angriffsfläche unmittelbar. „Was mir bei der Untersuchung auffiel, war, wie viel PHP wir außerhalb des klassischen Webhostings gefunden haben", sagt Adrian Cheek, Senior Cybercrime Researcher bei Flare. „Wir haben es in Speichergeräten, physischen Zutrittskontrollsystemen, Kameras und Fernzugriffsschnittstellen identifiziert. Wer nur auf die Hauptwebsites schaut oder eine externe Prüfung auf die Ports 80 und 443 beschränkt, übersieht einen Teil davon."

Für Organisationen mit solchen Beständen gelte: „Man kann sich in der Regel nicht an einem Speichersystem oder einer physischen Zutrittskontrolleinheit anmelden und deren PHP-Installation eigenständig aktualisieren. Man braucht den Hersteller, der aktualisierte Firmware bereitstellt. Hat der Hersteller das Produkt abgekündigt, gibt es für die Organisation womöglich gar keinen Patch."

Nicht mit einem Klick erledigt

Öffentlich verfügbare Daten deuten darauf hin, dass der Großteil des weltweit eingesetzten PHP auf alten Zweigen läuft. „Wer eine Anwendung rund um PHP 5 oder PHP 7 betreibt, muss für den Wechsel auf eine aktuelle PHP-Version möglicherweise Teile der Anwendung neu schreiben, Abhängigkeiten ersetzen und alles testen, was kaputtgehen könnte. Es gibt gute Gründe, warum Organisationen das nicht leichtfertig tun, besonders wenn die Anwendung etwas operativ Wichtiges trägt", erklärt Cheek.

In solchen Fällen zieht sich die Behebung hin – sofern sie überhaupt angegangen wird. Zugleich sind alte PHP-Versionen nicht automatisch verloren. Die häufigste Version in den öffentlichen Daten, 7.4.3, ist jene, die mit Ubuntu 20.04 ausgeliefert wurde. Cheek weist darauf hin: „Linux-Distributionen behalten häufig eine ältere PHP-Versionsnummer bei und portieren Sicherheitskorrekturen zurück. Eine alte Versionsnummer bedeutet also nicht automatisch, dass die Software ungepatcht ist." Neben Betriebssystemen können auch Anwendungen Korrekturen für das mitgelieferte PHP zurückportieren.

Betroffene zerfallen damit in klar unterschiedliche Gruppen. Ein Teil muss den aufwendigen Weg gehen und Anwendungen oder Produkte migrieren oder ersetzen; bis dahin empfehlen Fachleute, verwundbare Systeme ganz vom Netz zu nehmen. Für CVE-2026-109619 nennt Cheek eine Zwischenlösung für alle, die an die PHP-Konfiguration herankommen: „Die gemeldeten Angriffe laufen über den PHP-Session-Upload-Progress, eine Funktion, die standardmäßig aktiv ist und keinen session_start-Aufruf in der Anwendung benötigt. Das Deaktivieren von session.upload_progress.enabled und ein Neustart der PHP-Worker blockiert die bestätigten Angriffswege über Session Upload Progress, ohne dass ein PHP-Versionsupgrade nötig ist." Die zweite Lücke, CVE-2026-109618, werde damit nicht abgedeckt; es handle sich bestenfalls um eine vorübergehende Maßnahme.

Andere können auf zurückportierte Korrekturen ihrer Anbieter zurückgreifen. Der Ubuntu-Entwickler Canonical veröffentlichte am 21. Oktober Korrekturen für PHP2Shell für alle Versionen seit 14.04. Auch hier bleibt Nacharbeit, denn ein Betriebssystem- oder Anwendungsupdate bringt nicht zwingend ein vollständiges PHP-Versionsupgrade mit: Wer Ubuntus Aktualisierungen nutzt, kann in künftigen Scans weiterhin scheinbar PHP 7.4.3 anzeigen.

Und, so Cheek: „Der Neustart ist entscheidend. Die Installation eines korrigierten PHP-Pakets ersetzt nicht zwangsläufig den Interpreter, der bereits in laufende Worker-Prozesse geladen ist."

Jeder Fall liegt anders

Neben der Technik entscheidet auch die Größe einer Organisation über die Reaktionsmöglichkeiten. Kleinen Unternehmen fehlt es oft an Aufmerksamkeit und Ressourcen. Nach 48 Stunden ununterbrochener Arbeit, in denen sein Unternehmen mehr als 1.000 Organisationen bei PHP2Shell unterstützte, hebt Ox-Security-Chef Neatsun Ziv dennoch die Vorteile kleiner Strukturen hervor: „In kleinen Organisationen kann man machen, was man will. Man geht einfach rein und patcht. Man wartet fünf Stunden. Niemand beschwert sich, dass etwas kaputtgeht."

Bei großen Organisationen sei das anders: „Sie haben ein Golden Image – eine Server-Basis, die sie aktualisieren", sagt Ziv. „Es ist immer ein Downstream-Modell: Man verteilt ein neues Golden Image, dieses Golden Image wird mit neuer Software gebaut, diese neue Software geht in die Produktion, und in der Produktion kann niemand etwas ändern. Das ist heute die Norm bei Deployments. Niemand geht auf Server und patcht sie tatsächlich. Das wird auf Dauer einfach nicht mehr wartbar."

Hinzu kommen die vielen beteiligten Teams bei größeren Aktualisierungen, besonders kritische Systeme, die nicht ausfallen dürfen, und die schiere Verbreitung von PHP im eigenen Haus. Ziv: „Die meisten Organisationen, mit denen wir arbeiten, haben Hunderte Server gefunden, auf denen PHP läuft."

Alex Spokoiny, Chief Security and Trust Officer bei Check Point, verweist zudem auf das Risiko durch Zulieferer. „Der erste Schritt besteht darin, die relevanten Lieferanten anzusprechen und zu verstehen, wie sie reagieren. Sind sie betroffen? Welche Schutzmaßnahmen haben sie ergriffen? Wann erwarten sie, die Behebung abgeschlossen zu haben? Wenn man darauf keine klaren oder vernünftigen Antworten bekommt, ist das selbst etwas, das man in die Risikobewertung einbeziehen und gegebenenfalls als Anlass für Alternativen sehen muss", rät er.

Auch gemeinsames Vorgehen kann helfen: „Wo technisch möglich, können sie etwa ihren eigenen Schutz durch eine Web Application Firewall auf Anwendungen ausdehnen, die von Dritten betrieben werden, und so die Angriffsfläche verringern, während der Anbieter an einer dauerhaften Lösung arbeitet", sagt Spokoiny.