Die meisten PHP-Server sind trotz Warnungen weiterhin kritischen PHP2Shell-Exploits ausgesetzt

Fünf Tage nach der öffentlichen Bekanntmachung zweier kritischer PHP-Schwachstellen, bekannt als PHP2Shell, melden Sicherheitsfirmen, dass die überwiegende Mehrheit der internetseitigen Systeme ungepatcht bleibt und aktiv von Angreifern ins Visier genommen wird. Trotz dringender Warnungen von Regierungsbehörden und großen Technologieanbietern hinken die Bemühungen zur Behebung dem Tempo der Exploit-Versuche deutlich hinterher.

Was passiert ist

Die Schwachstellen, identifiziert als CVE-2026-109618 und CVE-2026-109619, tragen einen Common Vulnerability Scoring System (CVSS)-Score von 9,2, was auf ein schwerwiegendes Risiko für Remote Code Execution hinweist. Da PHP etwa 70 % aller Websites mit identifizierbaren serverseitigen Sprachen betreibt, darunter viele WordPress-Installationen, ist das potenzielle Ausmaß enorm. Daten von Ox Security zeigen jedoch, dass am 26. Oktober noch 93,6 % der Systeme diesen Fehlern ausgesetzt waren. Moshe Siman Tov Bustan von Ox Security merkte an, dass zwar Panik in den Schlagzeilen um sich griff, das tatsächliche Patchen aber kaum vorankam, sodass kritische Assets ungeschützt blieben, gerade als Proof-of-Concept-Exploits in freier Wildbahn auftauchten.

Unabhängige Scans anderer Sicherheitsfirmen bestätigen diese langsame Reaktion. Censys berichtete, dass zwar 11,2 Millionen PHP-Dienste gepatcht erschienen, aber 32,5 Millionen weiterhin unsichere Versionen angaben. Eine wesentliche Komplikation besteht darin, dass 58 % der erkannten PHP-Dienste, insgesamt über 61 Millionen, ihre Versionsnummern nicht offenlegten; viele davon führen wahrscheinlich nicht mehr unterstützte Software aus. Flare stellte fest, dass fast drei Viertel der 2,2 Millionen von ihm verfolgten PHP-Einträge auf Branches liefen, die vom PHP-Projekt nicht mehr unterstützt werden. Ebenso identifizierte Mallory etwa 1,9 Millionen internetseitige Dienste, oder 73,5 % seiner Stichprobe, die nicht unterstützte PHP-Versionen ausführen, die keine offiziellen Patches erhalten.

Wichtige Details

• Ox Security meldet, dass 93,6 % der Systeme fünf Tage nach der Offenlegung weiterhin für PHP2Shell-Schwachstellen exponiert waren.
• Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 haben einen CVSS-Score von 9,2 und ermöglichen Remote Code Execution.
• Censys-Daten zeigen, dass 32,5 Millionen PHP-Dienste unsichere Versionen melden, während 61,3 Millionen Dienste ihre Versionsinformationen verbergen.
• Studien von Flare und Mallory deuten darauf hin, dass etwa 73–75 % der verfolgten PHP-Dienste auf nicht unterstützten Branches ohne offizielle Fixes laufen.
• Cloudflare beobachtete, dass Exploit-Versuche innerhalb weniger Stunden nach der öffentlichen Ankündigung von Tausenden auf Millionen sprangen.
• Die US Cybersecurity and Infrastructure Security Agency (CISA) ordnete eine Behebung für Bundesbehörden bis zum 29. Oktober 2026 an.

Hintergrund

PHP2Shell bezieht sich auf ein Paar kritischer Fehler, die es Angreifern ermöglichen, beliebigen Code auf Servern auszuführen, die verwundbare PHP-Versionen betreiben. Wenn eine Schwachstelle offengelegt wird, ist die Standardreaktion die Anwendung eines Sicherheitspatches, der vom Software-Maintainer bereitgestellt wird. Für unterstützte PHP-Versionen ist dies oft ein unkompliziertes Update. Allerdings läuft ein großer Teil des Internets auf älteren, end-of-life PHP-Versionen, die keine Sicherheitsupdates mehr vom PHP-Projekt erhalten. In diesen Fällen können Administratoren die Software nicht einfach patchen; sie müssen die gesamte PHP-Umgebung aktualisieren, was oft Tests der Anwendungen auf Kompatibilität und Zusammenarbeit mit Anbietern zur Gewährleistung der Stabilität erfordert. Diese Komplexität verlangsamt die Bemühungen zur Behebung im Vergleich zu einfachen Patches erheblich.

Warum es wichtig ist

Für Teams, die selbst gehostete Infrastruktur verwalten, stellt die Verbreitung nicht unterstützter PHP-Versionen ein erhebliches operatives Risiko dar. Wenn Ihre Server eine veraltete PHP-Branch ausführen, können Sie sich nicht auf ein einfaches Paket-Update verlassen, um CVE-2026-109618 oder CVE-2026-109619 zu beheben. Stattdessen stehen Sie vor einem komplexen Migrationsprojekt, das bestehende Anwendungen brechen kann. Die Verzögerung beim Patchen bedeutet, dass Angreifer ein breites Zeitfenster haben, um Systeme zu kompromittieren, bevor Abwehrmaßnahmen ergriffen werden. Wie Cloudflare-CEO Matthew Prince bemerkte, eskalierten Exploit-Versuche innerhalb weniger Stunden nach der Ankündigung von Tausenden auf Millionen, was darauf hindeutet, dass automatisierte Bots bereits nach verwundbaren Zielen scannen.

Die Situation wird dadurch weiter erschwert, dass viele Organisationen nicht wissen, dass sie nicht unterstützte Software ausführen. Da 58 % der PHP-Dienste ihre Versionsnummern nicht offenlegen, ist es schwierig, das wahre Ausmaß der Exposition einzuschätzen. Regierungsmandate wie die CISA-Frist für US-Bundesbehörden unterstreichen die Schwere der Bedrohung, aber Unternehmen der Privatwirtschaft müssen ihr eigenes Risiko proaktiv managen. Ein Nichtstun könnte zu Datenlecks, Dienstunterbrechungen oder einer vollständigen Übernahme des Systems führen, wie durch bestätigte Versuche der Remote Code Execution belegt wird, die von Sicherheitsforschern aufgezeichnet wurden.

Was Sie tun können

• Überprüfen Sie sofort Ihr Server-Inventar, um alle Instanzen zu identifizieren, die PHP ausführen, und notieren Sie insbesondere, welche Version und welcher Branch jede Instanz verwendet.
• Priorisieren Sie das Upgrade aller Systeme, die nicht unterstützte PHP-Versionen ausführen, auf eine derzeit unterstützte Release, auch wenn dies Refactoring der Anwendungen erfordert.
• Wenden Sie offizielle Sicherheitspatches auf allen Systemen an, die unterstützte PHP-Versionen ausführen, um CVE-2026-109618 und CVE-2026-109619 zu beheben.
• Implementieren Sie Web Application Firewalls oder Intrusion Detection Systems, um bekannte Exploit-Muster zu blockieren, die mit PHP2Shell assoziiert sind.
• Erwägen Sie, nicht-kritische oder hochgradig verwundbare Systeme vorübergehend offline zu nehmen, wenn sofortiges Patchen oder Upgrading nicht machbar ist.
• Überwachen Sie Logs auf Anzeichen von Versuchen der Remote Code Execution, wie ungewöhnliche Prozessspawns oder unerwartete Netzwerkverbindungen von Webserver-Prozessen.