PHP2Shell wird nicht die letzte Schwachstelle sein. Hier taucht die nächste zuerst auf.

Am 17. Oktober protokollierte Amazons Honeypot-Netzwerk einen PHP2Shell-Ausnutzungsversuch von einer anonymisierten IP-Adresse. Die öffentliche Bekanntgabe ließ jedoch noch vier Tage auf sich warten.

Als PHP am 21. Oktober die Korrekturen veröffentlichte, waren die technischen Details bereits durchgesickert, Proof-of-Concept-Exploits weit verbreitet und immer mehr Ausnutzungsversuche wurden überall protokolliert. Das Problem: Zwei kritische, nicht authentifizierte Sicherheitslücken zur Remotecodeausführung steckten direkt in der PHP-Engine (CVE-2026-109618 und CVE-2026-109619, beide CVSS v4.0 9.2) – das, was wir heute als PHP2Shell kennen.

Unser Security-Research-Team hat geschildert, was passiert ist und was Sie tun sollten: auf welche Versionen Sie aktualisieren sollten, welche Maßnahmen Sie bis zum Update ergreifen konnten, um die Angriffsfläche zu verringern, und wo die einzelnen Bereiche der Snyk-Plattform das Problem erkennen.

Dieser Beitrag knüpft nun dort an, wo unser Security-Research-Team aufgehört hat. Wir möchten darüber sprechen, was wir aus der Reaktion gelernt haben: wo diese Art von Gefährdung entsteht und wie sie zustande kommt, warum eine schnelle Reaktion von der Arbeit abhängt, die wir bereits Monate zuvor geleistet hatten, und warum die nächste Sicherheitslücke bereits bevorsteht.

Warum war PHP2Shell auch für Teams mit sauberem Code ein Problem?

Weil die Sicherheitslücken unterhalb des Codes liegen. Was bedeutet das? Beide genannten CVEs treten im Request-Lebenszyklus der PHP-Engine auf und sind damit erreichbar, bevor Anwendungscode überhaupt ausgeführt wird. Bei Apache mit mod_php genügte für einen Exploit eine einzige nicht authentifizierte Anfrage.

Denken Sie kurz darüber nach. Wahrscheinlich hatten Sie sorgfältige Reviews, sauberen Code und einen übersichtlichen Abhängigkeitsbaum – und all das befand sich oberhalb des eigentlichen Problems. Die erste Frage, mit der sich jedes Team konfrontiert sah, lautete: Wo beantwortet PHP Anfragen, und kann jemand genau dort gerade einen Exploit ausführen?

Es ging um laufende Anwendungen. Genau diese Frage stellen sich Angreifer immer zuerst.

Welches Inventar zeigt Ihnen, wo PHP ausgeführt wird?

Jede Art von Inventar zeigt Ihnen nur einen Teil davon.

PHP gelangt über ein Dockerfile, ein Distributionspaket, ein Plattform-Image oder eine manuelle Installation in die Produktionsumgebung. Eine "php": ">=8.2"-Vorgabe in composer.json zeigt Ihnen, welche Version eine Anwendung akzeptiert. Welche Version tatsächlich bereitgestellt wird, hängt davon ab, welcher dieser Wege für die Installation genutzt wurde. Container-Scans erkennen PHP aus Distributionspaketen, sobald die jeweilige Distribution ihre Sicherheitshinweise veröffentlicht. Aus dem Quellcode kompiliertes PHP, einschließlich der offiziellen PHP-Docker-Images, fällt hingegen nicht in diesen Erfassungsbereich. (Noch einmal: Im Beitrag unseres Research-Teams erfahren Sie genau, welche Snyk-Ansicht welchen Teil dieser Realität abbildet.)

Dann gibt es noch die Versionszeichenfolge. VirusTotal erfasst per Fingerprinting rund 5,1 Millionen IP-Adressen, auf denen PHP läuft. Nur rund 1,1 Millionen davon geben eine Version an – etwa vier von fünf verbergen sie also. Die Zusammenfassung bringt es so treffend auf den Punkt wie kaum eine andere Aussage, die wir zu diesem Thema gelesen haben: „Wenn Sie nur nach einer Versionszeichenfolge suchen, sehen Sie nur den Teil des Problems, der freiwillig preisgegeben wird.“

Die Lücke zwischen dem, was Ihre internen Ansichten erfassen, und dem, was von außen tatsächlich antwortet, birgt das eigentliche Risiko. Angreifer rufen Ihre URL auf – und PHP2Shell ist das deutlichste Beispiel dafür, das wir bisher gesehen haben. Wer danach sucht, stellt immer dieselbe Frage: Antwortet PHP unter dieser URL?

Wie sah die Reaktion aus, wenn man sie von außen betrachtet?

Der Vorsprung: Noch vor der Veröffentlichung durch PHP am 21. Oktober um 14:00 UTC hatte Snyk Sicherheitshinweise zu beiden CVEs veröffentlicht. So wurden überwachte Projekte sofort erfasst, sobald die korrigierten Versionen bekannt waren. Rund 30 Minuten nach der Veröffentlichung enthielten die Hinweise bereits die betroffenen Versionsbereiche und die korrigierten Versionen. Die Hinweise der Distributionen folgten, sobald diese sie veröffentlichten. Damit war abgedeckt, was Ihnen Snyk Container und Scans nicht verwalteter Komponenten mitteilen konnten.

Bei Snyk API & Web standen drei Fragen im Mittelpunkt:

1. Wo wird PHP ausgeführt? Discovery ermittelt die Assets Ihrer Domains und identifiziert deren Technologie-Stack. Wählen Sie im Tech-Filter PHP aus, erhalten Sie alle gefundenen Hosts und Endpunkte, auf denen PHP erkannt wurde – samt Risikobewertung, Score und Datum der letzten Erkennung. Versionsnummern werden später von den Hosts selbst ermittelt. Wie unser Research-Team es formuliert hat: Bevor Sie patchen können, brauchen Sie die Liste.

2. Kann jemand die Sicherheitslücke ausnutzen? Innerhalb von 24 Stunden nach der Veröffentlichung durch PHP prüfte das vollständige Scan-Profil auf PHP2Shell. Teams konnten diese Prüfung auch selbst als benutzerdefiniertes Profil ausführen und so schnell alle PHP-Ziele überprüfen.

3. Hat die Korrektur gegriffen? Führen Sie nach dem Patchen dasselbe benutzerdefinierte Profil erneut aus und gleichen Sie das Ergebnis mit dem Sicherheitshinweis oder Patch-Level Ihrer Distribution ab, da ein gepatchter Distributions-Build weiterhin eine ältere Versionsnummer anzeigen kann.

Also: Discovery → gezielte Prüfung → Patch → erneuter Test: Sondieren, beobachten und Schlüsse ziehen – und das gegen die Uhr, die inzwischen in Stunden tickt. Genau das ist der besorgniserregendste Punkt und für uns besonders wichtig. Für Teams, die bereits Snyk API & Web nutzten, war die schwierige Arbeit schon vor dem 21. Oktober erledigt: Ihre Domains waren erfasst und ihre Anwendungen als Ziele eingerichtet. Sobald die Prüfung verfügbar war, brauchte es nur noch einen Filter und einen schnellen Scan.

Für uns ist das einer der größten Vorteile kontinuierlicher Tests von außen: Die Arbeit, die Ihnen am ersten Tag die Antworten liefert, wird Monate vorher erledigt.

Wenn PHP2Shell von außen erkennbar ist, was war dann die schwierige Aufgabe?

Die Zeit.

Im Mai haben wir den Unterschied erläutert, auf dem COS basiert. Heuristisch erkennbare Sicherheitslücken lassen sich mit deterministischen Tools aufspüren: Sie senden Payloads an eine laufende Anwendung oder API, beobachten die Antworten und leiten daraus Erkenntnisse ab. Kontextabhängige Sicherheitslücken (BOLA, mandantenübergreifende Datenlecks und verkettete Geschäftslogikfehler) haben dagegen keine eindeutige Signatur. Sie liegen in der Lücke zwischen dem, was eine Anwendung tun soll, und dem, was sie tatsächlich tut.

Sobald PHP2Shell bekannt war, ließ sich die Sicherheitslücke von außen testen. Sie gehört damit eindeutig zur ersten Kategorie der heuristisch erkennbaren Schwachstellen. Die schwierige Aufgabe und der Engpass waren die Zeit zwischen einer Bekanntgabe und einer Prüfung, die alles testet, was Sie nach außen freigeben. In diesem Zeitfenster können Angreifer die Sicherheitslücke ausnutzen – bei diesem Vorfall begann es vier Tage vor der späteren Bekanntgabe.

Auch nach der Bekanntgabe gab es neue Entwicklungen. Am 23. Oktober beschrieb das PHP-Projekt einen teilweisen Bypass (CVE-2026-115560), der auftritt, wenn eine Anwendung vor dem Start der Sitzung mit ini_set() den Session-Serialisierungs-Handler wechselt und der Upload-Fortschritt aktiviert ist. Diese Voraussetzungen sind selten. Trotzdem musste man die Schlussfolgerungen vom Mittwoch am Freitag noch einmal überprüfen. Eine Momentaufnahme veraltet innerhalb weniger Tage.

Warum wird PHP2Shell nicht die letzte Sicherheitslücke dieser Art sein?

Dafür gibt es drei Gründe – die mit der Art und Weise zusammenhängen, wie die Sicherheitslücken gefunden wurden:

1. Sie wurden mit Unterstützung von KI gefunden – und zwar in einer Engine, die seit drei Jahrzehnten das Web antreibt. Unser Research-Team brachte es auf den Punkt: „In einer Welt voller LLMs und Agenten laufen trotzdem überall noch Server.“ Und die Art von Modell, die diese Sicherheitslücken gefunden hat, steht inzwischen auch Angreifern zur Verfügung.

2. Die höhere Frequenz. Manoj Nair, Snyks CTO und Chief Innovation Officer, beschrieb sie im September: „Schwerwiegende Schwachstellen, die KI jetzt in weit verbreiteter Software aufspürt – Funde, die früher ein- oder zweimal im Jahr auftraten und die Planungen für das ganze Quartal auf den Kopf stellten –, treten meiner Beobachtung nach inzwischen mehrmals pro Woche auf.“

3. Die deutlich kürzere Reaktionszeit. CJ Moses, CISO von Amazon Integrated Security, leitete zwei Lehren aus PHP2Shell ab, die weit darüber hinaus gelten. Verteidiger „sollten nicht davon ausgehen, dass der Tag der öffentlichen Bekanntgabe auch der früheste Zeitpunkt ist, zu dem die Sicherheitslücke ausgenutzt wird.“ Und „die Zeitspanne zwischen einem Patch und einem funktionierenden Exploit schrumpft aus strukturellen Gründen“, weil KI-gestützte Analysen es einfacher machen, aus einem Patch-Diff oder einem Sicherheitshinweis einen funktionierenden Exploit zu entwickeln. Sein Rat zu kritischen Sicherheitslücken in internetfähigen Systemen: „Bemessen Sie Patch- und Abhilfefristen in Stunden.“

Was müssen Sie tun, um für die nächste Sicherheitslücke gerüstet zu sein?

Lassen Sie die Produktnamen weg, und es bleiben vier entscheidende Eigenschaften. Beurteilen Sie jeden Ansatz daran – auch unseren. Konzentrieren Sie sich nicht auf Produktnamen, sondern auf diese vier Eigenschaften. Jeder Ansatz sollte daran gemessen werden – auch unserer!

1. Ein Inventar, das bereits vor der Bekanntgabe existiert. Von außen aufgebaut und stets aktuell gehalten, damit Sie bei einer neuen Bekanntgabe sofort einen Filter setzen können.

2. Prüfungen, die innerhalb weniger Stunden verfügbar sind. Die Zeit zwischen einem Sicherheitshinweis und einem laufenden Test ist das Zeitfenster für Angreifer. Messen Sie es.

3. Tests auf Abruf. Führen Sie dieselbe gezielte Prüfung wiederholt aus, bis die Korrektur greift.

4. Tests, die keine Signatur benötigen. Heuristiken erkennen, was bereits beschrieben wurde. Alles andere erfordert Schlussfolgerungen: Tests müssen ermitteln, was Ihre Anwendung tun soll, und dann die Lücke zwischen diesem Soll und dem tatsächlichen Verhalten aufdecken.

So lässt sich das auf unser Angebot übertragen.

Snyk API & Web deckt die ersten drei Punkte ab: Discovery, eine Engine, die das Team bei neuen Bekanntgaben aktuell hält, sowie gezielte Profile, die Sie wiederholt ausführen können. Evo Continuous Offensive Security ergänzt den vierten Punkt: AI Pentesting analysiert Ihre Anwendung wie ein Pentester. Agent Red Teaming wird aktiv, sobald die Reconnaissance ein LLM im Stack erkennt. Dynamic Testing, die Engine von Snyk API & Web, deckt kontinuierlich die zugrunde liegenden heuristisch erkennbaren Schwachstellenklassen ab. In der Terminologie unserer Plattform heißt das Validate: Ihre Anwendungen kontinuierlich angreifen, um nachzuweisen, dass Korrekturen greifen, und aufzuzeigen, was sich weiterhin ausnutzen lässt.

Dann ist da noch die Sicherheitslage. Bei The AI Security Panel: Unfiltered am 14. Oktober stellte Manoj die Frage, auf die wir immer wieder zurückkommen: „Wenn ein autonomer Angreifer Sie angreifen wird, warum greifen Sie sich dann nicht selbst an?“ Diese Frage ist der Grundgedanke von COS. Bei uns geht es darum, jede einzelne Lücke in diesem Ablauf zu schließen: vom Sicherheitshinweis bis zur laufenden Prüfung und von der Prüfung bis zur bestätigten Korrektur.

Wo wird die nächste Sicherheitslücke zuerst auftauchen?

Welche Engine sie aufspürt und wann, lässt sich kaum vorhersagen. Wo sie zuerst sichtbar wird, lässt sich leichter sagen: unter Ihrer URL. Dort sollten Ihre Tests längst laufen.

Möchten Sie sehen, was ein Angreifer heute unter Ihrer URL finden würde? Demo von Evo Continuous Offensive Security buchen und erfahren Sie, wie Ihre Angriffsfläche von außen erfasst, die Ausnutzbarkeit von Findings nachgewiesen und die Korrektur so lange erneut getestet wird, bis sie greift.