PHP2Shell-Angriffe erreichen Honeypots, Millionen Dienste bleiben auffällig

Mehr als vier Millionen deutsche Dienste mit auffälligen Versionen

Der Schwachstellenscanner Censys fand am Freitag rund 4,2 Millionen PHP-Instanzen in Deutschland, deren gemeldete Versionsnummern als anfällig galten. Am Morgen des 27. Oktober waren es laut t3n weiterhin mehr als vier Millionen. Heise bezifferte die insgesamt in Deutschland erfassten PHP-Dienste auf knapp elf Millionen. Diese Angaben beschreiben erkannte Dienste mit bestimmten Versionsnummern – nicht ebenso viele nachweislich verwundbare Unternehmen oder Server. [1][2]

Die Zahlen sind zudem eine Momentaufnahme. Censys berichtete laut Heise weltweit von mehr als 41 Millionen erfassten PHP-Diensten mit potenziell anfälligen Versionsnummern; zum dortigen Meldungszeitpunkt seien knapp acht Millionen aktualisiert worden, während 33,5 Millionen weiterhin als anfällig gezählt wurden. Da sich Installationen fortlaufend ändern und die Erfassung zeitversetzt erfolgt, sind solche Werte keine zeitlose Bestandsaufnahme. [2]

Versionsnummern sind ein Indikator, keine abschließende Diagnose

Censys leitet den Status einer Instanz aus der erkannten PHP-Version ab. Linux-Distributionen können Sicherheitskorrekturen jedoch in ältere Versionszweige zurückportieren. Eine alte Versionsnummer bedeutet deshalb nicht zwingend, dass die betreffende Installation noch verwundbar ist. Umgekehrt erschwert es die Einordnung, wenn ein Dienst seine Version nicht preisgibt: Laut Heise war das bei rund 54 Prozent der PHP-Dienste der Fall. [2]

Hinzu kommt, dass Censys Dienste und nicht Organisationen oder einzelne Maschinen zählt. Ein Server kann mehrere URLs oder PHP-Dienste auf unterschiedlichen Ports bereitstellen. Die vom Scanner erfasste Zahl kann daher nicht unmittelbar als Zahl betroffener Unternehmen oder eigenständiger Server gelesen werden. Censys selbst bezeichnet die Ergebnisse laut Heise als Schätzung zur Lageeinschätzung, nicht als maßgebliche Bestandswahrheit. [2]

Die Inventarisierung muss über Webprojekte hinausgehen

Für Unternehmen besteht eine praktische Herausforderung darin, alle PHP-Laufzeitumgebungen zu finden. PHP kann direkt für eine Website eingesetzt werden, aber auch als bislang unbemerkte Abhängigkeit anderer Software auf einem internetfähigen Server vorhanden sein. Heise weist ausdrücklich auf diese Möglichkeit hin. Eine Bestandsaufnahme allein anhand bekannter Webprojekte kann daher Installationen übersehen. [2]

Für die Priorisierung ist nicht nur relevant, ob PHP vorhanden ist, sondern auch, welche Version tatsächlich läuft und ob der Dienst aus dem Internet erreichbar ist. Der Sicherheitsanbieter Zafran empfiehlt, zunächst exponierte Systeme zu erfassen und zu aktualisieren; diese Empfehlung stammt von einem Anbieter und ist als solche einzuordnen. Als Analyse folgt daraus: Ein öffentlicher Dienst mit ungeklärtem Patch-Status verdient eine zeitnahe technische Prüfung, ohne dass ein bloßer Versionsfund bereits eine erfolgreiche Ausnutzung beweist. [2][5]

Patches sind verfügbar, aber nicht für alle Versionen gleich

Heise nennt als korrigierte PHP-Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12. Für PHP 7.4, 8.0 und 8.1 gebe es Korrekturen lediglich im Quellcode, jedoch keine fertigen Releases; noch ältere Versionen blieben ungepatcht. Unternehmen mit älteren Laufzeitumgebungen müssen deshalb prüfen, welche Pakete ihre Distribution oder ihr Hosting-Anbieter bereitstellt und welche Upgrade- oder Abschottungsmöglichkeiten bestehen. [2]

Bei der Umsetzung zählt der Zustand der tatsächlich laufenden Anwendung, nicht nur ein geänderter Paketstand. Zafran empfiehlt, nach dem Einspielen von Updates auch PHP-FPM, Apache und andere länger laufende PHP-Prozesse neu zu starten. Das ist ein Hinweis des Sicherheitsanbieters auf mögliche Abweichungen zwischen installiertem Patch und aktivem Laufzeitprozess; die konkrete Vorgehensweise muss zur jeweiligen Systemarchitektur passen. [5]

Ein Patch beantwortet nicht automatisch die Frage nach einem Einbruch

Die Honeypot-Beobachtung zeigt, dass Codeausführung über die Lücken möglich war. Daraus folgt nicht, dass jede ungepatchte Installation angegriffen wurde – ebenso wenig beweist ein nachträglich eingespieltes Update, dass zuvor keine Ausführung stattgefunden hat. Diese Unterscheidung ist für die Vorfallbewertung wichtig: Schwachstellenbehebung und Prüfung möglicher vorheriger Aktivitäten sind unterschiedliche Aufgaben. [1][5]

Zafran rät bei einem Verdacht dazu, betroffene Systeme zu isolieren, Webserver- und PHP-Protokolle zu sichern und unter anderem neue Dateien, Webshells, Cronjobs und Konten zu untersuchen. Da diese Hinweise von einem Sicherheitsanbieter stammen, sind sie als dessen Handlungsempfehlung zu verstehen. Für Unternehmen ergibt sich daraus vor allem, Belege zu sichern und den Patch-Status nicht mit einer abgeschlossenen Vorfallanalyse gleichzusetzen. [5]

Was die Lage für Unternehmen bedeutet

Die verfügbaren Informationen zeichnen ein abgestuftes Bild: Es gibt Hinweise auf aktive Ausnutzung und einen dokumentierten Codeausführungstreffer in Honeypots; zugleich lässt sich aus diesen Befunden keine belastbare Zahl erfolgreicher Angriffe auf produktive Unternehmenssysteme ableiten. Auch die Millionenwerte für Deutschland sind keine bestätigten Fallzahlen, sondern beruhen auf der Erkennung von PHP-Diensten und ihren Versionsnummern. [1][2]

Für Sie als IT-Verantwortliche sind damit drei Fragen zentral: Wo läuft PHP – auch als indirekte Abhängigkeit? Welche dieser Systeme sind tatsächlich verwundbar und aus dem Internet erreichbar? Und gibt es Hinweise auf Aktivitäten, die über einen reinen Scanversuch hinausgehen? Die Reihenfolge folgt aus den dokumentierten Grenzen der Censys-Erfassung und der beobachteten Codeausführung auf Honeypots; sie ersetzt keine Prüfung der eigenen Systeme. [1][2]

Die hohe Zahl auffälliger Versionsmeldungen unterstreicht den Handlungsdruck, darf aber nicht als Beleg für vier Millionen kompromittierte Dienste interpretiert werden. Entscheidend ist die individuelle Verifikation des Laufzeit- und Patch-Status – einschließlich möglicher Rückportierungen und nicht offensichtlicher PHP-Installationen. [2]

Quellen

1. [1] php2shell-Lücke wird ausgenutzt – viele Server noch verwundbar — https://t3n.de/news/php2shell-angreifer-nutzen-die-luecken-jetzt-aus-4-millionen-deutsche-dienste-veruwndbar-1770083 (abgerufen am 2026-10-27)
2. [2] php2shell: Millionen PHP-Dienste in Deutschland verwundbar | heise online — https://www.heise.de/news/php2shell-Millionen-PHP-Dienste-in-Deutschland-verwundbar-11498464.html (abgerufen am 2026-10-27)
3. [4] PHP2Shell: Was die kritischen PHP-Schwächen bedeuten und was zu tun ist | Illumio — https://www.illumio.com/de/blog/php2shell-a-years-old-vulnerability-a-global-emergency-and-what-to-do-now (abgerufen am 2026-10-27)
4. [5] Everything You Need to Know About the Two Critical PHP Vulnerabilities — https://www.zafran.io/resources/php2shell-everything-you-need-to-know-about-the-two-critical-php-vulnerabilities (abgerufen am 2026-10-27)