Am 20. Oktober wurden Details zu zwei kritischen Sicherheitslücken in PHP im Internet bekannt, noch bevor die Korrekturen fertig waren. PHP, die Skriptsprache, auf der ein großer Teil des Internets basiert, zog die Veröffentlichung des Patches um einen Tag vor und veröffentlichte ihn am 21. Oktober. Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 (mit dem Spitznamen „php2shell“) ermöglichten es einem Angreifer, über PHP selbst Befehle auf einem Webserver auszuführen, ohne sich anmelden zu müssen.
Installieren Sie jetzt das Patch. Die CISA hat beide Schwachstellen am 26. Oktober in ihre Liste der ausgenutzten Sicherheitslücken aufgenommen. Diese Empfehlung ist richtig, lässt jedoch eine Lücke offen. In diesem Beitrag geht es um diese Lücke.
Angreifer haben die Sicherheitslücke getestet, noch bevor es einen Patch gab.
Für PHP 8.2 bis 8.5 sind bereits Korrekturen verfügbar, und laut PHP werden für PHP 8.1 und ältere Versionen keine Updates mehr bereitgestellt. Einer Schätzung zufolge sind noch etwa 884.000 solcher Server online – eine grobe Zahl aus einer einzigen Quelle.
Die Honeypots von Amazon ( als Köder dienende Server, die Angreifer anlocken sollen) verzeichneten den ersten Versuch am 17. Oktober, vier Tage vor der Veröffentlichung, und bereits am 21. Oktober stellte Amazon zahlreiche Ausnutzungsversuche in freier Wildbahn fest. Cloudflare beobachtete erste Angriffe, und das britische National Cyber Security Centre warnte Unternehmen, sofort Updates durchzuführen oder ihre Systeme offline zu nehmen. Wie viele echte Server übernommen wurden, ist noch unklar. Amazon gibt an, nicht zu wissen, ob die beobachteten Angriffe außerhalb eines Honeypots erfolgreich gewesen wären.
Am 23. Oktober meldeten CrowdStrike und Flare weiterhin lediglich Sondierungsversuche und fehlgeschlagene Angriffe, von denen viele PHP zum Absturz brachten, anstatt einem Angreifer die Kontrolle zu verschaffen. Am nächsten Tag dokumentierte Adel Karimi von Perplexity eine erfolgreiche Remote-Code-Ausführung auf einem Honeypot, und am 26. Oktober nahm die CISA beide Schwachstellen in ihre Liste bekannter, ausgenutzter Schwachstellen auf, mit einer Frist für die Bereitstellung eines Patches durch die Bundesbehörden bis zum 29. Oktober. Karimis Test nutzte eine bewusst günstige Konfiguration, sodass er zwar zeigt, dass die Schwachstelle funktioniert, aber nicht, wie oft solche Angriffe erfolgreich sind.
Jeder Fehler ist schon eine Weile bekannt, bevor jemand darauf aufmerksam macht.
Eine Sicherheitslücke wird an dem Tag zum Thema in den Medien, an dem sie bekannt gegeben wird, nicht an dem Tag, an dem sie auftritt. Die PHP-Entwickler selbst haben erste Anzeichen dieses Problems bereits bei einer Überprüfung im Jahr 2024 entdeckt, und Angreifer haben die Lücke ausgenutzt, noch bevor die Öffentlichkeit davon erfuhr.
Dieses Muster haben wir schon einmal gesehen. Als im Dezember 2021 die Log4j-Sicherheitslücke bekannt wurde, schrieb Vectra, dass das erste Anzeichen eines Angriffs schwer zu erkennen sei und dass man am sichersten davon ausgehen könne, dass mindestens ein Server in einer Infrastruktur bereits kompromittiert sei. Andere Schwachstellen in der Software, die Ihr Unternehmen einsetzt, befinden sich heute sehr wahrscheinlich in derselben Situation: Sie sind jemandem bekannt, wurden aber noch niemandem gemeldet. Durch das Installieren von Patches werden die Schwachstellen behoben, von denen Sie erfahren. Bei den übrigen kann das jedoch nicht helfen.
Die PHP-Server, die dir fehlen, sind am wichtigsten
PHP betreibt WordPress-, Drupal-, Joomla- und Magento-Websites, Hosting-Control-Panels und eine Vielzahl von Programmen, bei denen PHP nicht einmal erwähnt wird. Die Server, die Sie kennen, werden gepatcht. Diejenigen, von denen Sie nichts wissen, sind genau die, die Angreifer als Erstes finden, weil niemand ein Auge auf sie hat.
Geräte und Verwaltungsschnittstellen, auf denen PHP vorinstalliert ist, sind die wahrscheinlichsten Angriffspunkte, und sie werden im Gegensatz zu Webservern nur selten überwacht. Flare berichtet unter Berufung auf den Bericht eines Forschers, dass einige Geräte PHP ohne Adressrandomisierung ausliefern, wodurch das größte Hindernis für einen Angreifer beseitigt wird. Fragen Sie Ihre Anbieter, welche ihrer Produkte PHP enthalten.
Kein Team behebt alle Probleme am Tag der Veröffentlichung eines Patches. Wenn man weiß, welche Server mit dem Internet verbunden sind und welche die wertvollsten Daten enthalten, lässt sich der Rückstand auf eine kurze Liste von Entscheidungen reduzieren – darunter auch die Frage, welche Dienste bis zur Behebung der Probleme abgeschaltet werden sollen. Auf jedem Server, bei dem der Verdacht besteht, dass er betroffen ist, sollten vor dem Neustart die Protokolle und ein Speicherabbild gesichert werden, da ein Neustart die Spuren löscht.
Was passiert, wenn ein PHP-Server ausfällt?
Ein Angreifer, der Code über PHP ausführen kann, benötigt in der Regel keine „ malware “. Der Webserver verfügt bereits über eine Shell, eine Netzwerkverbindung und Zugriff auf Dateien, sodass er die auf dem Rechner bereits installierten Tools nutzen kann, um sich umzusehen, Anmeldedaten zu finden und von einem System zum nächsten zu gelangen. Nichts sieht verdächtig aus, da der Webserver seine üblichen Aufgaben mit leicht abgewandelten Befehlen ausführt. Das ist die erste der drei Erkennungslücken, über die ich schreibe: Nichts sieht verdächtig aus.
Was sich ändert, ist, mit wem der Server kommuniziert. Ein Webserver, der seit Jahren dieselben Seiten bereitstellt, greift plötzlich auf Orte zu, mit denen er zuvor noch nie in Verbindung stand, sendet Anfragen an unbekannte Adressen oder beginnt, mit internen Systemen zu kommunizieren. Dieses Verhalten zeigt sich im Netzwerkverkehr, nicht im Patch-Status. Anhand einer Netzwerkansicht lässt sich erkennen, mit wem ein Server tatsächlich verbunden ist – unabhängig davon, ob jemand den Server selbst überwacht oder nicht.
Was „ Vectra AI “ sehen kann und was nicht
Vectra AI Es geht nicht wirklich darum, wie der ursprüngliche Angriffsvektor aussieht. Was für uns zählt, ist das, was danach passiert.
Heute dreht sich alles um PHP. Nächste Woche wird es etwas anderes sein: eine weitere Sicherheitslücke, ein Anruf beim Helpdesk, ein Insider. Was wir untersuchen, hängt nicht davon ab, durch welche Tür der Angreifer eingedrungen ist. Wir beobachten, was ein System tut, sobald sich ein Angreifer im System befindet. Daher müssen wir weder den Eintrittsweg kennen noch muss die Sicherheitslücke veröffentlicht worden sein. Das ist vor allem dann wichtig, wenn der Einstiegspunkt unbekannt ist oder die Sicherheitslücke noch nicht bekannt gegeben wurde.
Aufdeckung potenzieller PHP-Server und Schatten-IT
Eine der Herausforderungen bei der Absicherung der PHP-Infrastruktur besteht darin, überhaupt erst einmal zu wissen, wo sie sich befindet. Vergessene Anwendungen, nicht verwaltete Server und Schatten-IT können Sicherheitslücken verursachen, selbst nachdem bekannte Schwachstellen bereits behoben wurden.
Vectra AIDas Dashboard zur PHP-Server-Transparenz (verfügbar für Kunden mit einer Metadaten-Aufbewahrungsdauer von mindestens 14 Tagen) bietet ein zusätzliches Ermittlungswerkzeug, das Sicherheitsteams dabei unterstützt, potenziell übersehene PHP-Server anhand von Indikatoren zu identifizieren, die im unverschlüsselten HTTP-Datenverkehr beobachtet werden, wie beispielsweise .php Endpunkte und PHPSESSID Cookies. Analysten können dann untersuchen, ob diese Hosts auch verschlüsselten Datenverkehr von externen Quellen empfangen, was dabei hilft, potenziell gefährdete Systeme für weitere Untersuchungen zu priorisieren.
Das Dashboard ist nicht dazu gedacht, eine vollständige Bestandsaufnahme der PHP-Server zu liefern. Es kann lediglich Systeme identifizieren, die erkennbare PHP-bezogene Indikatoren aufweisen, wobei verschlüsselter Datenverkehr oder eingeschränkte Netzwerksichtbarkeit dazu führen können, dass einige Server unentdeckt bleiben. Stattdessen dient es als Unterstützung für bestehende Workflows zur Erkennung von Systemen und zur Bedrohungssuche und hilft Analysten dabei, potenzielle Schatten-IT aufzudecken, Sicherheitslücken zu untersuchen und Systeme zu identifizieren, die auch nach der Installation von Patches einer genaueren Prüfung bedürfen.
Erkennungsregeln für bekannte php2shell-Exploit-Versuche
Vectra Match enthält nun Regeln zur Erkennung des Angriffsverhaltens von PHP2Shell, sofern der Angreiferverkehr ordnungsgemäß sichtbar ist. Sie kennzeichnen bekannte Exploit-Versuche im Netzwerkverkehr, sobald dieser für uns sichtbar ist, und fangen so Versuche bereits im Ansatz ab, während die oben genannten Erkennungsmechanismen die nachfolgenden Ereignisse erfassen. Ein Versuch ist noch kein Sicherheitsverstoß. Ein Treffer ist ein Grund, den betreffenden Server genauer zu untersuchen, aber kein Beweis dafür, dass er übernommen wurde. Diese Funktion steht allen Kunden von Vectra Match zur Verfügung.
Die Regeln, nach ET-Regelnummer:
- 2072548: ET-Exploit PHP php2shell – Session-Injection durch Handler-Diskrepanz (CVE-2026-109619)
- 2072549: ET-Exploit PHP php2shell – Multipart-Header-Amplifikation – OOM (CVE-2026-109618)
- 2072550: ET-Exploit PHP php2shell – Verschachtelte Steuerung leerer Dateien – OOM (CVE-2026-109618)
- 2072551: ET-Exploit PHP php2shell – Chunked-Multipart-Anfrage ohne „Content-Length“ (CVE-2026-109618)
- 2072552: ET-Exploit PHP php2shell – URL-kodierter POST-Befehl zur Manipulation von $_POST (CVE-2026-109618), im Regelsatz auskommentiert, daher standardmäßig deaktiviert
- 2072553: ET-Exploit PHP php2shell – Multipart-Anfrage ohne „Content-Length“ (CVE-2026-109618)
- 2072554: ET-Exploit für PHP – „php2shell“-Code-Injektion in Dateinamen (CVE-2026-109619)
- 2072555: ET HUNTING PHP Generic Upload Progress Session Manipulation – eine Suchregel, keine Exploit-Regel; behandeln Sie einen Treffer daher als Hinweis
- 2072556: ET-Exploit PHP php2shell – Übermäßige Anzahl von Multipart-Teilen (CVE-2026-109618)
- 2072557: ET-Exploit PHP php2shell – Unzureichende Überprüfung leerer Multipart-Dateien (CVE-2026-109618)
Was ein kompromittierter PHP-Server über Ihre Ausfallsicherheit verrät
Früher wurde der Erfolg daran gemessen, ob Angreifer eindringen konnten. Heute geht es darum, wie weit sie vordringen. Patches, ein solides Netzwerkdesign, die Aufteilung des Netzwerks in Zonen, das Prinzip der geringsten Berechtigungen und das Wissen darüber, auf welchen Systemen Ihre wichtigsten Geschäftsprozesse laufen – all das begrenzt diese Reichweite. Anhand der Netzwerkprotokolle lässt sich nachvollziehen, ob jemand die Tür passiert hat, bevor sie sich geschlossen hat, und wohin er sich anschließend bewegt hat.
In dem Whitepaper „Mind Your Gaps in the Age of AI-Powered Attacks “ werden diese drei Lücken ausführlich behandelt.