Hell in a PHP2Shell: Wie KI das Zeitfenster für Patches von Tagen auf Stunden verkürzt hat

Was ist es an dieser Jahreszeit, das kurz vor den Feiertagen zu einem weit verbreiteten, heimtückischen Cyber-Vorfall einlädt? Gerade als Sicherheitsexperten keine Log4J/Log4Shell-Alpträume mehr hatten, taucht eine Reihe kritischer PHP-Schwachstellen auf, die für massive Störungen sorgen. Am 21. Oktober wurden Hunderte von Websites offline genommen – nicht etwa von Angreifern mit Exploits, sondern proaktiv von Regierungen, Unternehmen und Organisationen, um zu

verhindern, dass diese Websites ausgenutzt werden, während ihre Technik-Teams Patches prüften und einspielten. Die Ursache waren zwei kritische Schwachstellen in PHP, der Sprache, die schätzungsweise 70 % aller Websites zugrunde liegt. Zusammen als PHP2Shell bekannt, könnten CVE-2026-109618 und CVE-2026-109619 es einem nicht authentifizierten Angreifer unter den richtigen Bedingungen ermöglichen, Remote Code Execution (RCE) auf einem Server auszuführen.

Die Fehler selbst liegen im zugrunde liegenden C-Code von PHP. Auch wenn es faszinierend ist, in die technischen Details dieses Vorfalls einzutauchen, ist die größere Geschichte hier, dass dieser Out-of-Memory (OOM)-Fehler nicht neu ist: Er wurde erstmals 2004 gemeldet, dann erneut 2019 und wieder 2024. Und die wichtigste Erkenntnis ist wohl, warum dieser gleiche OOM-Fehler im Sommer 2026, nachdem er 12 Jahre lang nicht priorisiert wurde, plötzlich zur höchsten Priorität für das gesamte Sicherheitsteam der PHP Foundation wurde.

Was ist also passiert? KI-Modelle sind passiert.

KI hat das Zeitfenster zwischen dem Entdecken und dem Ausnutzen einer Sicherheitslücke drastisch verkürzt

Diese Fehler sind nicht trivial auszunutzen. Die Verkettung dieser Schwachstellen zu einem funktionierenden Angriffsvektor erfordert ein tiefes Verständnis dafür, wie PHP Speicher über Anfragen hinweg zuweist und wiederverwendet. Erfahrene Sicherheitsforscher wissen, dass der schwierigste Teil der Arbeit oft darin besteht, die Auswirkungen zu beweisen: Ein Fehler, der nicht erreicht werden kann, kann nicht ausgenutzt werden, und ein Fehler, der nicht ausgenutzt werden kann, erzeugt nicht genug Dringlichkeit für eine Fehlerbehebung – in einer Welt, in der Technik-Teams nur begrenzte Ressourcen und ohnehin zu lange Backlogs haben.

Diese Fehler blieben so lange unbehandelt, weil niemand herausfinden konnte, wie man sie ausnutzt. Und da die Fehlerbehebung komplex war und ernsthafte Kompromisse zwischen Abwärtskompatibilität, Denial-of-Service (DoS)-Potenzial und schwer zu koordinierenden Änderungen an Drittanbieter-Erweiterungen erforderte, gerieten die Bemühungen zur Behebung des Fehlers im Jahr 2024 ins Stocken. Dieses Szenario wird jedem Team, das Sicherheitsergebnisse triagiert, bekannt vorkommen: Ein theoretisches Problem mit einer teuren Lösung verliert meist gegen Probleme mit klaren, nachgewiesenen Auswirkungen.

Bis zu diesem Sommer, als das PHP-Projekt in das „Patch the Planet“-Programm von OpenAI aufgenommen wurde. Neue Runden KI-gestützter Sicherheitsaudits bei PHP legten nicht nur die Fehler offen, sondern erstellten auch die funktionierenden Proof-of-Concepts für Exploits, die benötigt wurden, um die Korrekturen zu priorisieren. Die Timeline von Calif zeigt weniger als 2 Wochen von dem Zeitpunkt an, als sie einen Weg zum Fehler fanden, bis sie ein funktionierendes Proof of Concept (PoC) an die PHP Foundation übergaben. In ihrem Bericht hebt Wiz explizit hervor, was den Unterschied ausmachte: „Mit modernen KI-Modellen und den richtigen Tools hat ein einzelner Forscher in einer Woche das geschafft, wofür ein Weltklasse-Team früher monatelange Arbeit gebraucht hätte.“

Was diese Schwachstelle im Kern bedeutet

Wenn eine PHP-Anfrage keinen Speicher mehr hat, stoppt PHP die Anfrage sofort. Dieser abrupte Stopp führt dazu, dass ein Schritt zur Speicherbereinigung übersprungen wird, was eine Use-After-Free-Speicherkorruptionsschwachstelle erzeugt. Im genau falschen Moment könnte PHP teilweise initialisierte interne Daten hinterlassen und diese später als gültig behandeln, was den Speicher korrumpiert oder einen internen Zustand hinterlässt, der auf Speicher einer vorherigen Anfrage verweist.

Diese beiden Fehler in einen funktionierenden Angriff zu verwandeln, war komplex. Es erforderte:

• Das Erzwingen eines Out-of-Memory-Fehlers an einem exakten Punkt durch eine kleine Anfrage mit tief verschachtelten Formularfeldern, die PHP dazu bringt, weit mehr Speicher zuzuweisen als die Anfragesgröße (Calif)
• Das Anordnen von Angreifer-kontrollierten Daten im freigegebenen Speicher, sodass PHP sie als eigene interne Strukturen liest (Calif)
• In einigen Ketten die Verwendung eines zweiten Fehlers, um Speicherinhalte auszulesen und herauszufinden, wo sich Dinge befinden, was die Adress-Randomisierung aushebelt (Wiz)

Wenn Sie die technischen Details dieses Exploits verstehen möchten, besuchen Sie unsere öffentliche PHP2Shell-Anleitung, die Schritt für Schritt erklärt, wie das funktioniert: [JETZT ABSPIELEN]

Eine neue Welt: Exploit-Versuche in Echtzeit beobachten

Wären es doch nur die Sicherheitsforscher und Technik-Teams, die von KI unterstützt würden. Der PHP2Shell-Vorfall ist das erste Mal, dass wir den Quantensprung in der Geschwindigkeit sehen können, mit der Angreifer Offenlegungen und Patches in Exploits umwandeln. Da Organisationen wie AWS und Cloudflare vorab informiert wurden, konnten sie Exploit-Versuche in freier Wildbahn bei ihrer Kundenbasis beobachten. Und da PHP schätzungsweise auf 70 % aller Websites im Einsatz ist, ist die Angriffsfläche von PHP2Shell riesig.

• Cloudflare verzeichnete in den 10 Stunden vor der öffentlichen Ankündigung Tausende von Versuchen, PHP2Shell auszunutzen. Weniger als 24 Stunden nach der Ankündigung verfolgten sie Millionen von Exploit-Versuchen.
• Amazon Threat Intelligence identifizierte einen PHP2Shell-Exploit-Versuch vom 17. Oktober, vier Tage vor der öffentlichen Bekanntgabe. Innerhalb weniger Stunden nach der Veröffentlichung des Patches bestätigte AWS, „breite Exploit-Versuche in freier Wildbahn“ zu sehen.

Dies zeigt, dass sich Teams nicht mehr auf Patch- und Minderungszeitpläne von 30 oder gar 7 Tagen verlassen können. Bei kritischen Schwachstellen hat der Einsatz von KI diese Zeitpläne auf Stunden verkürzt.

Die wichtigsten Erkenntnisse

Für Technik- und Sicherheitsteams müssen zwei Annahmen überdacht werden.

Erstens: Die Aussage „keine bekannten Exploits“ bietet heute weniger Sicherheit als früher, da KI-Tools die Kosten für deren Entwicklung drastisch gesenkt haben. Früher als theoretisch eingestufte Schwachstellen sollten neu bewertet werden. Code ist günstig geworden, und damit auch Exploits.

Zweitens: Ein Fix, der Wochen dauert, konkurriert heute mit Angriffen, die in Stunden erfolgen – das verändert die ROI-Berechnung. Proaktive Prävention wird schnell zur besten Risikominderung. Wenn Ihr Team Anwendungen auf veralteten PHP-Versionen ohne Patches betreibt, könnten bei Updates ernsthafte Probleme auftreten. Ihre technischen Schulden sind zu einem kritischen Sicherheitsproblem geworden, und wir müssen davon ausgehen, dass sich dieser Trend mit leistungsfähigeren, KI-gestützten Angreifern fortsetzt. Da PHP einen Großteil der Serverinfrastruktur des Internets stützt, dürfte das Ausrollen von Patches eine Mammutaufgabe werden. Da nicht nur Webanwendungen betroffen sind, sondern auch Appliances und praktisch alle internetfähigen Systeme und Produkte, droht Sicherheitsteams ein dauerhaftes Problem. Es ist unerlässlich, dass Teams wachsam sind und nicht nur auf bekannte kritische Exploits reagieren, sondern bei der Softwareentwicklung – ob menschlich oder KI-generiert – konsequent auf Sicherheit setzen. [CHALLENGE STARTEN] [MIT EXPERTEN SPRECHEN]