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.
Installiere jetzt das Patch. Dieser Rat ist richtig, hinterlässt aber eine Lücke. 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 ( Köder-Server, die dazu dienen, Angreifer anzulocken) verzeichneten den ersten Angriff am 17. Oktober, vier Tage vor der Veröffentlichung, und bereits am 21. Oktober bezeichnete Amazon die Schwachstellen als in großem Umfang ausgenutzt. Cloudflare registrierte 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.
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.
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 bietet ein zusätzliches Ermittlungsinstrument, 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.
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.