PHP2Shell: Eine jahrealte Schwachstelle, ein globaler Notfall und was jetzt zu tun ist

Ein Gedächtnisfehler wurde erstmals 2024 in PHP entdeckt. Zwei Jahre vergingen ohne eine Lösung. Dann hat KI-unterstützte Forschung daraus einen funktionierenden Exploit gemacht. Jetzt sind mehr als 22,6 Millionen vom Internet exponierte Instanzen potenziell gefährdet. Derzeit untersuchen Angreifer verwundbare Server, und öffentliche Webseiten in ganz Europa sind offline gegangen, während Teams patchen.

Das Durcheinander führt auf zwei kritische Schwächen in PHP zurück, die zusammen als PHP2Shell bekannt sind. Am 21. Oktober veröffentlichten PHP-Entwickler Patches für sowohl CVE-2026-109618 als auch CVE-2026-109619, die jeweils mit 9,2 von 10 für den Schweregrad bewertet wurden. PHP betreibt etwa 70 % der Websites, die eine bekannte serverseitige Programmierungsspracheverwenden, einschließlich Seiten, die auf WordPress, Drupal und Joomla basieren. Und da die Fehler in PHP selbst und nicht in einem Plugin oder einer App liegen, könnten Angreifer bösartigen Code ausführen, ohne sich einzuloggen. Von dort aus könnten sie einen verwundbaren Server übernehmen oder sensible Daten direkt aus dessen Speicher ziehen.

PHP2Shell ist mehr als nur ein Patching-Problem. KI-gestützte Forschung kann alte Fehler schneller in funktionierende Exploits verwandeln, als Teams Korrekturen testen und ausliefern können. Und ein gehackter öffentlicher Webserver kann Angreifern einen Weg zu Datenbanken, internen Anwendungen und Cloud-Workloads bieten. Das Patching muss mit einem zweiten Plan einhergehen: diese Wege sehen, Lateral Movement begrenzen und eine Sicherheitsverletzung eindämmen, bevor sie sich ausbreitet.

"Es ist fast so, als hätte jemand einen universellen Schlüssel zu all unseren Haustüren gefunden", sagte Christer Swartz, Direktor für Branchenlösungen bei Illumio.

Das Rennen um das Patchen begann mit einem Leck. Am 20. Oktober begannen die beiden CVE-Kennungen online zu zirkulieren. PHP hat seine Veröffentlichung um einen Tag vorgezogen. An diesem Abend veröffentlichte die Sicherheit Calif versehentlich ein Video eines funktionierenden Exploits. Kopien verbreiteten sich in den sozialen Medien. Am nächsten Morgen veröffentlichte Chainguard Software-Images mit der Lösung mehr als sechs Stunden vor der koordinierten Veröffentlichung. Die Angreifer konnten die Korrektur studieren, bevor die meisten Teams die Chance hatten, zu patchen.

Die Folgen erreichten die öffentlichen Dienste schnell. Regierungsbehörden, Universitäten und andere öffentliche Websites in ganz Europa gingen offline, während Teams eilig mit dem Patch beschäftigt waren. Sicherheitsbehörden forderten sofortige Updates. Cloudflare hatte Angriffsverkehr gegen seine Kunden, bevor die Patches ausgeliefert wurden. Amazon Gefahr Intelligence gibt an, am 17. Oktober einen Exploit-Versuch entdeckt zu haben, vier Tage bevor die Fehler öffentlich wurden. Heute meldet er eine umfassende Ausbeutung in freier Wildbahn. Es ist noch nicht klar, wie viele Versuche erfolgreich waren.

Die Warnung, die ungelöst blieb

Die Uhr begann lange bevor die Öffentlichkeit von PHP2Shell wusste.

Im Jahr 2024 entdeckte ein PHP-Entwickler die ersten Anzeichen des Speicherproblems , als er ein anderes Problem bei einem Sicherheitsaudit behob. Das Team überlegte mehrere Lösungen. Jede davon riskierte eine Unterbrechung der Kompatibilität, neue Denial-of-Service-Risiken zu schaffen oder Änderungen bei Drittanbieter-Erweiterungen zu erzwingen. Da kein bekannter Weg zur entfernten Codeausführung war, kam die Arbeit ins Stocken.

Dann änderten sich die Einsätze.

Im August zeigte KI-unterstützte Forschung, was der Fehler bewirken kann. Am 11. August berichteten Forscher von Calif und OpenAI getrennt von einem entfernten Code-Ausführungspfad mit derselben Ursache. Tage später nutzte Wiz Frontier-KI-Modelle , um weitere Angriffswege zu finden. Das Team zeigte funktionierende Angriffe auf WordPress-, Drupal- und Joomla-Seiten. Der Fehler war nun ein Weg in einen Live-Webserver.

Das PHP-Team und die Forscher begannen, an Patches zu arbeiten. Sie wollten den Website-Besitzern Zeit zur Vorbereitung geben. Doch der Plan scheiterte, als vor der Veröffentlichung Details herauskamen.

Der Weg von der Warnung zur Krise

• 2024: Während ein PHP-Entwickler eine Prüfungsbefindung behebt, entdeckt er den Speicherfehler. Eine Lösung bleibt hängen.
• August 2026: Calif, OpenAI und Wiz nutzen KI-unterstützte Forschung, um die Ausführung von Remote Code zu zeigen.
• August bis Oktober 2026: PHP-Betreuer und Forscher arbeiten an einer Lösung für eine Veröffentlichung am 22. Oktober.
• 17. Oktober: Amazon entdeckt einen Exploit-Versuch an einem Honigtopf.
• 20. Oktober: Die CVE-Identifikatoren leaken. PHP verschiebt die Veröffentlichung um einen Tag. Calif postet versehentlich ein Exploit-Video.
• 21. Oktober: Chainguard veröffentlicht früh fixierte Bilder. PHP veröffentlicht Patches, wenn Websites offline gehen und Exploit-Versuche stark zunehmen.

Die PHP Foundation hat inzwischen Lücken im Umgang mit der alten Warnung eingeräumt. Ihr Account zeigt auch, wie schwer es ist, eine Korrektur geheim zu halten, sobald der Beweis für einen Exploit bekannt ist. Ein Patch muss getestet werden. Angreifer brauchen nur einen Server, der noch nicht gepatcht wurde.

Nicht jede PHP-Seite ist dem gleichen Risiko ausgesetzt. Das Risiko hängt von der verwendeten Version, dem Serveraufbau und den Steuerungen ab. Doch die Krise setzte eine harte Grenze für die Zeit, die die Teams zum Handeln hatten.

Ein Webserver kann ein Pfad ins Netzwerk sein

Denken Sie an ein Kundenportal. Es kann sich mit einer Datenbank für Kontodatensätze, einer API für Zahlungen und Cloud-Apps für andere Aufgaben verbinden. Diese Links ermöglichen es, dass die Seite funktioniert. Sie können einem Eindringling auch einen Weg an der Vordertür vorweisen.

Swartz warnte, dass ein Angreifer, der einen Webserver übernimmt, den Pfaden folgen kann, die die App bereits nutzt.

"Und wenn diese Gefahr auf einem kundenorientierten ... Webserver landet und Sie sie nicht entdecken können, wird sie einfach immer tiefer in Ihr Netzwerk einschlagen, die Sie offen gelassen haben", sagte er.

Der Angreifer könnte nach API-Schlüsseln oder Login-Token im Serverspeicher suchen. Wiz zeigte, dass diese Fehler genau solche Daten durchsickern können. Der Angreifer könnte auch testen, welche Systeme der Server erreichen kann. Wenn der Zugang zu weit gefasst ist, könnte eine einzige Sicherheitsverletzung Kundendaten, interne Apps und kritische Assets gefährden.

Der Patch-Status allein sagt dir nicht, wie weit das gehen könnte. Teams müssen auch wissen, was ein Server nach einem Breach erreichen kann.

Das schließt alle Verbindungen zwischen IT und Betriebstechnologie (OT) ein, bei denen ein schlecht gesicherter Weg Anlagensysteme offenlegen könnte.

Die KI hat das Tempo des Rennens verändert

KI half Forschern, das Risiko aufzudecken. Das gab den Verteidigern die Chance, es zu beheben. Aber dieselben Werkzeuge können Angreifern helfen, Wege hineinzufinden.

Swartz sieht ein neues Problem für Teams, die auf manuelle Reaktionen angewiesen sind.

"Ich würde sagen, was es für das Verwundbarkeitsfenster bedeutet, ist, dass es jetzt viel kürzer ist, als irgendein Mensch darauf reagieren kann", sagte er. Er war direkter in Bezug auf die Kosten der Verzögerung: "Wenn du dich auf eine Person verlässt... einen Menschen, der auf einer Tastatur tippt, hast du verloren."

Das Problem ist die Geschwindigkeit. Analysten müssen weiterhin Risiken einschätzen und Angriffe untersuchen. Aber bis jemand eine unbekannte Verbindung entdeckt und darauf reagiert, könnte ein Angreifer bereits weitergezogen sein.

Wie man den Schaden begrenzt

1. Beginnen Sie mit den offenen Servern

Der erste Schritt ist, betroffene PHP-Server zu finden und die Sicherheitsupdates anzuwenden. Wenn ein öffentlich zugänglicher Server nicht gepatcht werden kann, könnte es sicherer sein, den Zugriff einzuschränken oder offline zu nehmen.

Swartz bewertete die Arbeit nach der Sichtbarkeit, nicht nur nach der Anzahl der Server. Eine Seite, die mit einer sensiblen Datenbank oder einem anderen kritischen Asset verknüpft ist, verdient besondere Aufmerksamkeit.

"Du musst patchen, aber du musst auch fragen, was dieser Server erreichen kann", sagte er. "Wenn es sich mit kritischen Assets verbindet, ist das Risiko viel größer als die Schwachstelle auf dieser einen Maschine." Für load-balancierte Seiten empfiehlt er, eine Servergruppe zu patchen, während die anderen die Seite am Laufen halten. Dann können Teams den Datenverkehr wechseln und den Rest patchen.

2. Sehen, wohin ein Angreifer als Nächstes gehen könnte

Swartz' nächste Sorge sind die Verbindungen des Webservers zu APIs, Datenbanken, internen Apps und Cloud-Workloads. Diese Wege sind für das Unternehmen oft sinnvoll. Sie können auch zu Routen für Lateral Movement werden.

"Wenn du nicht weißt, mit welchen Systemen dein Webserver kommuniziert, weißt du nicht, wie weit ein Angreifer kommen könnte", sagte er. "Kartiere zuerst diese Verbindungen. Dann kann man sehen, welche dort sein müssen und welche kritische Assets gefährden."

3. Achten Sie auf Veränderungen im Verkehr

Er würde auch nach Verkehr suchen, der das normale Muster eines Servers durchbricht: neue Workload-Verbindungen, ungewöhnliche Ziele oder ein plötzlicher Anstieg des Volumens.

Er nannte DNS als Beispiel. Ein Server, der normalerweise kleine DNS-Anfragen sendet, aber große Datenmengen bewegt, muss sich vielleicht genauer hinschauen. Es handelt sich nicht um ein PHP2Shell-spezifisches Zeichen und es beweist keine Sicherheitsverletzung. Für PHP2Shell empfiehlt Wiz, auf ungewöhnliche Upload-Anfragen zu achten, gefolgt von Speicherlimit-Fehlern oder wiederholten HTTP-500-Antworten.

"Sie wissen vielleicht nicht, welche Schwachstelle ein Angreifer genutzt hat", sagte er. "Aber du kannst dir trotzdem vorstellen, dass eine Arbeitsbelastung etwas tut, das sie noch nie zuvor getan hat. Das ist die Art von Veränderung, die man fangen muss, bevor sich der Angriff ausbreitet."

4. Unnötige Wege abschneiden

"Die beste Praxis, würde ich sagen, ist, Ihre Anwendungen unabhängig von den zugrundeliegenden Segmenten zu segmentieren", sagte Swartz. Mit anderen Worten: Setze Steuerungen rund um jede App, egal auf welchem Netzwerk sie sich befindet.

Er argumentiert, dass eine Firewall am Rand, ein VLAN oder eine Cloud-Netzwerkgrenze nicht immer den Zugriff zwischen Apps kontrolliert. Workload-Level-Segmentierung kann jeden Server auf die benötigten Dienste beschränken.

"Ein Webserver muss vielleicht mit einer Datenbank kommunizieren", sagte er. "Das heißt aber nicht, dass es in jede Datenbank gelangen sollte. Wenn der Server kompromittiert wird, können diese Begrenzungen verhindern, dass der Angreifer ihn als Brücke zum restlichen Netzwerk nutzt."

5. Angenommen, der Patch ist vielleicht nicht das Ende

Swartz warnt außerdem, dass ein Patch eine Schwachstelle schließt, aber keinen Angreifer entfernen kann, der vor dem Fix eingedrungen ist. Teams müssen weiterhin Protokolle, Prozesse, Zugriffstoken und neue Verbindungen überprüfen.

"Sobald ein Server freigelegt wurde, geh nicht davon aus, dass der Patch bedeutet, dass du fertig bist", sagte er. "Sucht nach Anzeichen, dass jemand reingekommen ist, überprüft, wohin er gegangen ist, und isoliert die Workloads, wenn ihr eine Gefahr findet."

Das Ziel, so sagt er, sei es, eine Sicherheitsverletzung einzudämmen, ohne alle benötigten Dienstleistungen abzuschneiden.

Haltet das ein, was ihr nicht rechtzeitig patchen könnt

PHP2Shell setzt zwei Uhren in Bewegung. Einer verfolgt die Zeit, wie lange Teams brauchen, um einen Patch zu testen und bereitzustellen. Das andere zeigt, wie schnell ein Angreifer einen Weg hineinfindet.

Swartz verglich PHP2Shell mit einem Universalschlüssel für die Haustüren. Teams können nicht immer die Schlösser wechseln, bevor jemand den Schlüssel ausprobiert. Aber wenn sie die Wege zwischen den Workloads kennen, den Zugang einschränken und bei ungewöhnlichem Verkehr schnell handeln, muss eine offene Tür nicht das ganze Haus öffnen.

Lassen Sie nicht zu, dass eine Schwachstelle zu einer netzwerkweiten Sicherheitsverletzung wird

Angreifer brauchen nur einen Eintrittspunkt, um deine Umgebung zu kompromittieren.

Illumio hilft Ihnen, verdächtige Lateral Movement zu erkennen, Gefahren einzudämmen und Angreifer daran zu hindern, eine einzelne Schwachstelle in eine weitverbreitete Sicherheitsverletzung zu verwandeln.

Sehen Sie, wie Illumio die Ausbreitung von Angriffen stoppt

Erhalten Sie eine kostenlose Testversion von Illumio Segmentation