PHP2Shell: Über 34 Millionen PHP-Dienste melden noch betroffene Versionen – was die Zahlen bedeuten
Das öffentliche Censys-Dashboard zeigt auch zwei Tage nach der Veröffentlichung der korrigierten Versionen mehr als 34 Millionen PHP-Dienste, die eine Version aus dem betroffenen Bereich melden. Das sind keine 34 Millionen nachweislich hackbaren Server, aber ein deutliches Zeichen, wie schwer sich eine Korrektur über die gesamte Webinfrastruktur verteilt.
Gemeldete Versionen, keine bestätigte Verwundbarkeit. Backports bleiben von außen unsichtbar.
DIE ZAHLEN
Millionen Dienste melden weiterhin betroffene Versionen
Die Sicherheitsforscher von Censys erfassen weltweit öffentlich erreichbare PHP-Dienste, deren gemeldete Version im betroffenen Bereich für PHP2Shell (CVE-2026-109618 und CVE-2026-109619) liegt. Die korrigierten Versionen erschienen am 21. Oktober. Trotzdem zeigt das öffentliche Live-Dashboard auch am 23. Oktober noch einen enormen Bestand. Es verfolgt, wie sich die Zahl der erfassten Dienste seit Bekanntwerden der Lücken verändert, und wird laut Censys stündlich aktualisiert.
Beim Abruf am 23. Oktober 2026 zeigte das Dashboard diese Werte:
| Kennzahl | Erfasster Stand |
|---|---|
| Seit Beginn der Erfassung mit betroffener Version gesehen | 41.400.836 Dienste |
| Bei der jüngsten Erfassung weiterhin mit betroffener Version | 34.280.868 Dienste |
| Seit Beginn auf eine als korrigiert erkannte Version gewechselt | 7.128.257 Dienste |
| PHP-Dienste ohne öffentlich erkennbare Versionsangabe | 49.695.981 Dienste |
Die Werte sind eine Momentaufnahme und verändern sich mit jeder neuen Erfassung. Auch Änderungen an der Erkennung können dazu führen, dass Dienste neu eingeordnet werden.
Rund 34,3 von 41,4 Millionen sind etwa 83 Prozent der Dienste, die seit Beginn als betroffen erkannt wurden. Umgekehrt haben gut 17 Prozent auf eine korrigierte Version gewechselt. Beides ist eine Orientierung anhand der Zähler, keine exakte Patchquote: Neu entdeckte Dienste, verzögerte Scans und geänderte Erkennung beeinflussen die Werte. Außerdem liegen erst zwei Tage zwischen Release und Abruf.
EINORDNUNG
Warum das nicht 34 Millionen verwundbare Server sind
Dienste sind keine Server
Censys zählt Dienste, nicht einzelne physische Server oder Betreiber. Ein Host kann viele Websites und Dienste auf verschiedenen Ports bereitstellen.
Backports bleiben unsichtbar
Linux-Distributionen können Korrekturen zurückportieren, ohne die gemeldete Versionsnummer anzuheben. Die versionsbasierte Zählung ist laut Censys deshalb eine Obergrenze der möglichen Betroffenheit.
Ohne Version heißt nicht sicher
Fast 50 Millionen Dienste verraten ihre Version nicht. Sie dürfen weder automatisch als verwundbar noch als sicher eingestuft werden.
Die Daten sind keine vollständige Schwachstellenprüfung. Sie sind ein deutlicher Hinweis darauf, wie groß die öffentlich sichtbare Angriffsfläche ist.
ALTE ZWEIGE
Besonders problematisch: PHP 7.4 und älter
Im Dashboard gehören diese Versionsstände zu den am häufigsten gemeldeten:
- PHP 7.4.33: rund 6,43 Millionen Dienste
- PHP 8.1.34: rund 2,05 Millionen Dienste
- PHP 5.2.6: rund 1,56 Millionen Dienste
- PHP 5.6.40: rund 1,52 Millionen Dienste
- PHP 8.0.30: rund 1,16 Millionen Dienste
Diese Zahlen beziehen sich auf gemeldete Versionsstände und beweisen nicht, dass jedes dieser Systeme ungepatcht ist. Zur Zeile PHP 5.2.6: Laut Forschern und Censys beginnt der betroffene Bereich bei PHP 5.4. Das Dashboard zählt diese Version offenbar trotzdem mit, die Einordnung hängt also an dessen Methode.
Für PHP 8.2 bis 8.5 gibt es reguläre korrigierte Releases. PHP 8.2 wird allerdings nur noch bis zum 31. Dezember 2026 mit Sicherheitsupdates versorgt. PHP 8.1 und ältere Zweige liegen außerhalb des Upstream-Supports, für 7.4, 8.0 und 8.1 existieren nur Quellcode-Backports, und Distributionen oder Supportanbieter liefern teils eigene Korrekturen. Für PHP 5.4 bis 7.3 gibt es laut Censys keinen Fixpfad mehr.
Wer eine solche Version betreibt, kann deshalb nicht einfach das nächste offizielle PHP-Update installieren. Oft ist eine Migration auf einen unterstützten Zweig nötig, und das ist in gewachsenen Umgebungen der schwierigere Teil.
URSACHEN
Warum sind nach dem Fix noch so viele Systeme betroffen?
Die Censys-Auswertung liefert dafür keine vollständige Erklärung, denn sie zeigt den Zustand der Dienste, nicht die Abläufe ihrer Betreiber. Es gibt aber plausible Gründe, die nicht für jeden einzelnen Eintrag gelten müssen:
Ein PHP-Update ist nicht nur ein Paketupdate
In produktiven Umgebungen hängt PHP an Webserver, PHP-FPM-Pools, CMS, Plugins, Frameworks und eigenen Anwendungen. Updates werden deshalb oft erst getestet und in Wartungsfenstern ausgerollt. Bei einer kritischen Lücke braucht es dann aber eine Zwischenmaßnahme und einen klaren Zeitplan.
Unklar, wo überall PHP läuft
PHP kann in mehreren Versionen parallel, über PHP-FPM oder in Container-Images und Drittanbieterprodukten laufen. Ein korrigiertes Hostpaket hilft nicht, wenn ein Container seine eigene Runtime mitbringt.
Alte Anwendungen blockieren die Migration
Alte Frameworks und Erweiterungen sind oft nicht mit aktuellen PHP-Versionen kompatibel. Ein Wechsel von 7.4 auf 8.4 ist dann kein Routineeingriff. Eine nur mit einem ungepflegten Zweig lauffähige Anwendung muss modernisiert, isoliert oder ersetzt werden.
Hosting-Plattformen vergrößern den Aufwand
Auf Hostingplattformen laufen viele Websites mit unterschiedlichen Anforderungen und mehreren parallelen PHP-Runtimes. Betreiber müssen die tatsächlich genutzten Runtimes erfassen und sicherstellen, dass die Prozesse die neuen Versionen verwenden.
Der Patchstand ist von außen unklar
Eine alte Versionsnummer kann bereits einen Backport enthalten. Umgekehrt belegt eine neue Nummer nicht, dass jede Runtime und jeder Prozess aktualisiert wurde. Ein Teil des scheinbaren Rückstands kann deshalb an der externen Erkennung liegen.
Es wäre falsch, jeden Eintrag als nachlässigen Administrator zu bezeichnen. Genauso falsch wäre es, die Zahlen mit diesem Hinweis abzutun.
AUSWIRKUNG
Die eigentliche Gefahr: was danach passiert
PHP2Shell betrifft die Verarbeitung von Webanfragen in der PHP-Laufzeit. Unter geeigneten Bedingungen kann ein nicht authentifizierter Angreifer Code im Kontext des Webserver- oder PHP-Prozesses ausführen. Das ist nicht automatisch eine vollständige Übernahme des Servers: Welche Rechte ein Angreifer erhält und wie weit er sich bewegen kann, hängt von Berechtigungen, Isolation und Konfiguration ab. Möglich sind etwa das Sammeln von Systeminformationen, der Start weiterer Programme oder eine Webshell als späterer Zugang.
Zur tatsächlichen Ausnutzung hat Censys mehrere widersprüchliche Meldungen zusammengetragen. Amazon beobachtete Versuche in Honeypots seit dem 17. Oktober, watchTowr meldet Versuche gegen beide Lücken, VulnCheck sah einen erfolglosen Webshell-Versuch. Andere Stellen, darunter das Canadian Centre for Cyber Security, meldeten bis zum 21. Oktober keine aktive Ausnutzung, und beide CVEs standen laut Censys am 22. Oktober nicht im CISA-Katalog bekannter ausgenutzter Schwachstellen. Die Lage ist deshalb anhand der einzelnen Quellen und ihrer Zeitstempel zu beurteilen.
Wer eine betroffene Version öffentlich erreichbar betrieben hat, sollte bei Verdachtsmomenten auch auf mögliche Kompromittierung prüfen. Wie das geht, zeigt unser Beitrag PHP2Shell: So prüfst du, ob es Hinweise auf einen Angriff gab.
MASSNAHMEN
Was Betreiber daraus mitnehmen
Die Auswertung ist ein guter Anlass, die eigene PHP-Landschaft zu erfassen, statt sich an einer öffentlichen Zahl zu orientieren. Die konkreten Schritte, korrigierten Versionen und Praxisbefehle stehen im PHP2Shell-Hauptbeitrag. Drei Punkte sind hier besonders wichtig:
Alte Zweige nicht ignorieren
Bei PHP 7.4 und älter klären, ob ein bestätigter Backport existiert. Sonst eine Migration auf einen unterstützten Zweig einplanen. Dass ein Zweig seit Jahren ohne sichtbare Probleme läuft, macht ihn nicht sicher.
Fixstand der Plattform prüfen
Bei distributionsverwalteten Systemen zählen die Sicherheitsmeldungen und Paketstände des Anbieters. Ein zurückportierter Fix kann vorhanden sein, auch wenn die Versionsnummer abweicht.
Nicht auf die Statistik warten
Censys kann die weltweite Exposition schätzen, aber nicht die eigene Inventarisierung ersetzen. Verlässlich sind die eigenen Paketstände und die tatsächlich laufenden Runtimes.
BEI RDDZ
Was wir bei RDDZ daraus ableiten
Wir bieten bei RDDZ aktuell nur noch PHP ab Version 8.3 an. Ältere Zweige, wie sie in der Censys-Auswertung ein großer Teil des Bestands sind, gehören damit nicht zu unserem aktuellen Angebot.
Die Auswertung zeigt zugleich, warum die Frage nach dem Patchstatus nicht bei einer einzelnen Versionsnummer enden darf. In komplexeren Umgebungen müssen zusätzliche PHP-Runtimes, Container und Anwendungen berücksichtigt werden, und der Zustand einer öffentlich sichtbaren Runtime sagt nicht automatisch etwas über alle Komponenten eines Hosts aus.
Wichtig ist uns eine klare Trennung: Ein Sicherheitsupdate behebt die bekannte Schwachstelle in der korrigierten Runtime, ist aber kein rückwirkender Beweis dafür, dass ein System vorher nicht angegriffen wurde. Die öffentlichen Zahlen belegen außerdem nicht, dass ein bestimmter Anbieter oder eine bestimmte Infrastruktur kompromittiert ist. Sie sind ein ernstes Signal dafür, wie groß die Aufgabe ist, kritische Updates im gesamten Web zeitnah umzusetzen.
FAZIT
Das Problem ist größer als ein einzelner PHP-Patch
Mehr als 34 Millionen öffentlich erfasste PHP-Dienste melden laut Censys weiterhin eine Version aus dem betroffenen Bereich, und fast 50 Millionen weitere geben ihre Version nicht preis. Der hohe Anteil alter PHP-Zweige zeigt, dass es nicht nur um die Geschwindigkeit von Updates geht: Ein Teil der Webinfrastruktur hängt an Anwendungen und Laufzeiten, für die Sicherheitsupdates nicht mehr selbstverständlich verfügbar sind.
Die Zahlen dürfen nicht als garantiert verwundbare Server missverstanden werden. Die zentrale Aussage bleibt trotzdem: Eine Korrektur kann an einem Tag erscheinen, bis sie in Millionen Installationen, Containern und Hosting-Plattformen wirksam ist, dauert es deutlich länger. Entscheidend ist nicht, ob ein Patch existiert, sondern ob er auf jedem relevanten System angekommen ist und dort läuft.
QUELLEN
Quellen und weiterführende Informationen
- Censys: PHP2Shell – Live-Auswertung der öffentlich erfassten PHP-Dienste
- Censys: Sicherheitsanalyse zu CVE-2026-109618 und CVE-2026-109619
- PHP-Projekt: Offizielle Sicherheitsmeldungen und korrigierte Releases
- Amazon Threat Intelligence: PHP2Shell-Ausnutzung vor der Veröffentlichung
- Elastic Security Labs: Erkennungsansätze für PHP2Shell
Wissen Sie, welche PHP-Version Ihre Website nutzt?
Alte PHP-Zweige, Container und mehrere Runtimes sind schnell übersehen. Sprechen Sie uns an, wir unterstützen bei Bestandsaufnahme, Migration und Betrieb.
