PHP2Shell: Angreifer kompromittieren Behörde und setzen offenbar KI ein

Die beiden kritischen PHP-Sicherheitslücken CVE-2026-109618 und CVE-2026-109619 entwickeln sich immer mehr zu einem ernsthaften Sicherheitsproblem.

Nachdem kurz nach der Veröffentlichung bereits Millionen Angriffsversuche registriert wurden, gibt es inzwischen Hinweise auf erfolgreiche Kompromittierungen.

Besonders brisant ist ein von Palo Alto Networks Unit 42 dokumentierter Fall bei einer europäischen Regierungsorganisation.

Innerhalb von nur rund zwei Stunden nach dem ersten erfolgreichen Angriff gelangten die Angreifer laut den Sicherheitsforschern unter anderem an Passwort-Hashes und Geheimnisse für die Mehrfaktor-Authentifizierung. Anschließend wurde versucht, über Active Directory weitere Rechte zu erlangen.

Und damit nicht genug:

Das Verhalten der Angreifer weist laut Unit 42 deutliche Merkmale darauf hin, dass bei der weiteren Durchführung des Angriffs eine agentische KI-Plattform eingesetzt wurde.

PHP2Shell ist inzwischen mehr als nur theoretisches Risiko

PHP veröffentlichte am 21. Oktober 2026 Sicherheitsupdates für zwei kritische Schwachstellen.

Beide werden unter dem Namen PHP2Shell zusammengefasst:

• CVE-2026-109618

• CVE-2026-109619

Beide Schwachstellen haben einen CVSS-v4-Wert von 9,2 von 10 und ermöglichen unter bestimmten Bedingungen eine nicht authentifizierte Remote Code Execution.

Das bedeutet:

Ein Angreifer benötigt nicht zwangsläufig einen Benutzeraccount oder Zugang zum Backend einer Webseite, um Code auf dem Server auszuführen.

PHP selbst verarbeitet die präparierte Anfrage bereits, bevor der eigentliche Anwendungscode erreicht wird. Damit können auch vorgeschaltete Login-Funktionen der jeweiligen PHP-Anwendung den Angriff nicht grundsätzlich verhindern.

Europäische Behörde erfolgreich angegriffen

Der bislang besonders interessante Fall stammt aus Europa.

Unit 42 beobachtete einen Angriff auf eine Regierungsorganisation, bei dem die Täter nach dem ursprünglichen Exploit sehr schnell weitere Schritte ausführten.

Innerhalb von etwa zwei Stunden konnten sie laut Analyse:

• Passwort-Hashes erreichen

• MFA-Geheimnisse auslesen

• Informationen über Active Directory sammeln

• einen NTLM-Relay-Tunnel aufbauen

• eine Ausweitung auf Domain-Administratorrechte versuchen

Das zeigt ziemlich deutlich, warum PHP2Shell nicht einfach als weiterer Webserver-Scan abgetan werden sollte.

Ein erfolgreicher Einstieg über einen Webserver kann letztlich zum Sprungbrett in das interne Netzwerk werden.

Hinweise auf KI-gesteuerte Folgeangriffe

Besonders ungewöhnlich war allerdings die Art, wie der kompromittierte Rechner anschließend untersucht wurde.

Unit 42 beobachtete zahlreiche kurze, aufeinanderfolgende Befehle.

Dabei wurde beispielsweise nach folgenden Informationen gesucht:

• Benutzerkonten

• Passwortdatenbanken

• privilegierten Gruppen

• angemeldeten Benutzern

• internen Systemen

• DNS-Informationen

• Active-Directory-Strukturen

Das allein wäre für einen normalen Angreifer noch nichts Außergewöhnliches.

Interessant war vielmehr die Struktur der ausgegebenen Daten.

Ausgaben offenbar für Maschinen vorbereitet

Die Befehle verwendeten beispielsweise Überschriften wie:

==SHELLUSER==

oder:

==PASSWD==

Dadurch wurden die Ergebnisse in klar getrennte Abschnitte gepackt.

Für einen Menschen ist das nett.

Für eine KI ist es noch praktischer.

Die Ergebnisse lassen sich dadurch einfacher maschinell analysieren und anschließend als Grundlage für die nächste Aktion verwenden.

Unit 42 bezeichnet diese und weitere Verhaltensmuster als starke Indikatoren für einen agentischen Angreifer.

Was bedeutet „agentische KI“ in diesem Zusammenhang?

Damit ist nicht einfach gemeint, dass jemand ChatGPT geöffnet und nach einem Linux-Befehl gefragt hat.

Agentische Systeme können Aufgaben in mehreren Schritten bearbeiten.

Ein theoretischer Ablauf könnte beispielsweise so aussehen:

1. Systeminformationen abrufen.

2. Ergebnis analysieren.

3. Interessante Konten erkennen.

4. Active Directory untersuchen.

5. Fehlgeschlagenen Versuch auswerten.

6. Strategie anpassen.

7. nächsten Befehl ausführen.

Der Mensch gibt dabei eher Ziel und Rahmen vor.

Die KI übernimmt einen größeren Teil der einzelnen Zwischenschritte.

Genau diese kurzen, strukturierten Aufgaben und schnellen Richtungswechsel nach fehlgeschlagenen Aktionen sind Unit 42 aufgefallen.

Trotzdem würde ich hier vorsichtig formulieren:

Die Beobachtungen sprechen für KI-Unterstützung. Sie beweisen nicht, dass der gesamte Angriff autonom von einer KI durchgeführt wurde.

PHP2Shell wird weltweit gescannt

Parallel zu gezielten Angriffen läuft weiterhin eine enorme Scanaktivität.

Unit 42 hatte nach eigenen Telemetriedaten zuletzt mehr als 22,6 Millionen potenziell exponierte Instanzen identifiziert. Bitsight zählt derzeit je nach Messzeitpunkt mehr als 35 Millionen öffentliche PHP-Beobachtungen weltweit, wobei solche Werte nicht automatisch mit eindeutig verwundbaren einzelnen Servern gleichgesetzt werden dürfen.

Besonders viele PHP-Installationen werden unter anderem in den USA und Deutschland beobachtet.

Das erklärt auch, warum solche Schwachstellen unmittelbar nach ihrer Veröffentlichung für Angreifer interessant werden.

PHP läuft auf einem erheblichen Teil der öffentlich erreichbaren Web-Infrastruktur.

Verdächtige Nordkorea-Kampagne beobachtet

Zusätzlich berichtet CYFIRMA über eine gezieltere Kampagne, die mit moderater Sicherheit dem Umfeld der nordkoreanischen Lazarus Group zugerechnet wird.

Dabei sollen koreanischsprachige Akteure PHP-Systeme weltweit systematisch erfassen und mögliche Ziele priorisieren.

Im Fokus stehen insbesondere:

• Behörden

• Banken und Finanzunternehmen

• Produktionsunternehmen

• Logistik und Schifffahrt

• Flughäfen und Luftfahrt

• Handelsplattformen

• Online-Zahlungssysteme

Die Aktivitäten betreffen unter anderem Ziele in den USA, Japan, Südkorea, mehreren asiatischen Staaten, dem Nahen Osten sowie der Europäischen Union.

Keine vorschnelle Lazarus-Zuschreibung

Auch hier ist die Einordnung wichtig.

CYFIRMA bewertet die beobachtete Kampagnenaktivität selbst mit hoher Sicherheit.

Die konkrete Verbindung zum Lazarus-Umfeld wird dagegen nur mit moderater Sicherheit eingestuft.

Das ist ein großer Unterschied.

Bei staatlich orientierten Angriffen sollte aus einer möglichen Verbindung nicht plötzlich ein zweifelsfreier Täter werden.

Interessant ist die Beobachtung trotzdem, denn sie zeigt, wie schnell hochrangige Akteure auf neue Schwachstellen reagieren.

Angreifer scannen bewusst langsam

Besonders auffällig ist laut CYFIRMA die Vorgehensweise beim Scanning.

Statt tausende Anfragen in kurzer Zeit auf ein Ziel zu feuern, sollen die beteiligten Systeme relativ langsam arbeiten.

Die verwendeten Scanner werden gewechselt und bei Anzeichen von Blockierungen oder Rate-Limits aufgegeben.

Das erschwert klassische Erkennungsmechanismen, die vor allem auf große Mengen verdächtiger Anfragen reagieren.

„Low and slow“ ist zwar keine neue Angriffstechnik.

Bei einer derart stark beobachteten Schwachstelle kann sie aber ziemlich effektiv sein.

Welche PHP-Versionen sind sicher?

Die PHP-Entwickler haben die beiden kritischen Sicherheitslücken in folgenden Versionen korrigiert:

PHP fordert Betreiber ausdrücklich dazu auf, ihre Systeme unmittelbar zu aktualisieren.

Betroffen sind grundsätzlich PHP-Installationen, die Webanfragen verarbeiten – darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed.

Nach dem Update PHP-Prozesse neu starten

Ein Punkt wird gerne vergessen:

Nur die Pakete zu aktualisieren reicht nicht zwangsläufig.

Laufende PHP-Worker können weiterhin den alten Code im Speicher verwenden.

Nach dem Update sollten deshalb die entsprechenden Dienste beziehungsweise Worker neu gestartet werden.

Bei Container-Umgebungen müssen außerdem die betroffenen Images neu gebaut und ausgerollt werden.

Ein kurzer Blick auf:

php -v

ist dabei hilfreich, reicht aber nicht immer.

Die PHP-Version der Kommandozeile kann sich von der Version unterscheiden, die tatsächlich hinter dem Webserver läuft.

Gerade bei Hosting-Systemen sind mehrere PHP-Versionen parallel keine Seltenheit.

WAF und Workarounds ersetzen den Patch nicht

Web Application Firewalls oder Reverse Proxies können bestimmte Angriffsversuche abfangen.

Das kann als zusätzliche Schutzschicht sinnvoll sein.

Die eigentliche Schwachstelle steckt allerdings im PHP-Runtime selbst.

Datadog kommt deshalb zu einem sehr klaren Ergebnis:

Der vollständige Fix ist das Update von PHP.

Temporäre Konfigurationsänderungen können einzelne Angriffspfade erschweren, beseitigen die zugrunde liegende Schwachstelle aber nicht vollständig.

Was Administratoren jetzt prüfen sollten

Wer einen öffentlich erreichbaren PHP-Server betreibt, sollte aus meiner Sicht nicht mehr nur kontrollieren, ob ein Update verfügbar ist.

Jetzt geht es zusätzlich darum, mögliche Angriffsspuren zu suchen.

Interessant sind beispielsweise ungewöhnliche:

• große POST-Anfragen

• Speicherfehler von PHP

• Abstürze von Apache-Workern

• Shell-Prozesse unterhalb eines Webserver-Prozesses

• ausgehende Netzwerkverbindungen vom Webserver

• neu angelegte Dateien

• Veränderungen an Benutzerkonten oder SSH-Schlüsseln

ReliaQuest konnte CVE-2026-109618 in einer kontrollierten Umgebung reproduzieren und beschreibt eine mögliche Kombination aus HTTP-Fehlern, PHP-Speicherfehlern und anschließend abstürzenden Apache-Workern als hilfreiches Erkennungsmuster.

Ein erfolgreicher Angriff muss aber nicht abstürzen

Darauf sollte man sich allerdings nicht vollständig verlassen.

Datadog konnte zeigen, dass eine erfolgreiche Ausnutzung nicht zwangsläufig einen Worker zum Absturz bringen muss.

Auch eine HTTP-200-Antwort bedeutet nicht automatisch, dass nichts passiert ist.

Ein deutlich stärkeres Signal ist beispielsweise ein Shell-Prozess, der direkt von Apache, PHP-FPM oder einem anderen PHP-Webprozess gestartet wird.

Zusätzlich gibt es inzwischen noch CVE-2026-115560

Als wäre die Lage nicht schon unübersichtlich genug, hat PHP inzwischen noch vor einer dritten RCE-Schwachstelle gewarnt:

CVE-2026-115560

Diese hat allerdings andere Voraussetzungen.

Damit sie ausgenutzt werden kann, muss eine Anwendung eine ungewöhnliche Kombination verschiedener Session-Einstellungen verwenden und ihren Serialisierungsmechanismus während der Laufzeit ändern.

PHP selbst hält dieses Szenario für eher selten und will die Lücke deshalb im normalen Release-Zyklus schließen.

Diese dritte Schwachstelle sollte deshalb nicht mit den aktuell breit angegriffenen PHP2Shell-Lücken gleichgesetzt werden.

Mein Eindruck

Die Entwicklung zeigt ziemlich gut, wie schnell sich das Zeitfenster bei kritischen Serverlücken inzwischen geschlossen hat.

Vor einigen Jahren hatte man nach einer Sicherheitsmeldung vielleicht noch das Gefühl, man könne am nächsten Wartungstag aktualisieren.

Bei PHP2Shell begann die reale Angriffstätigkeit offenbar schon vor der öffentlichen Bekanntgabe.

Nach der Veröffentlichung stiegen die Scans innerhalb kürzester Zeit massiv an.

Und inzwischen sehen wir nicht nur automatisierte Scanner, sondern offenbar auch erfolgreiche Folgeangriffe auf Behörden und möglicherweise KI-gestützte Post-Exploitation.

Wer einen öffentlich erreichbaren PHP-Server betreibt, sollte deshalb nicht mehr überlegen, ob er aktualisiert.

Die interessante Frage ist inzwischen eher:

Ist das Update bereits vollständig ausgerollt – und war jemand vorher schneller?

Fazit

PHP2Shell ist inzwischen kein theoretisches Sicherheitsproblem mehr.

Die beiden kritischen Schwachstellen CVE-2026-109618 und CVE-2026-109619 werden weltweit gescannt und aktiv angegriffen.

Unit 42 dokumentiert inzwischen einen erfolgreichen Angriff auf eine europäische Regierungsorganisation. Innerhalb weniger Stunden erreichten die Angreifer Passwort-Hashes und MFA-Geheimnisse und versuchten, ihre Rechte bis zum Domain Administrator auszuweiten.

Besonders interessant sind die Hinweise auf den Einsatz einer agentischen KI-Plattform bei den Folgeaktivitäten.

Parallel werden weitere gezielte Kampagnen beobachtet, darunter Aktivitäten, die mit moderater Sicherheit dem nordkoreanischen Lazarus-Umfeld zugerechnet werden.

Für Serverbetreiber bleibt die wichtigste Maßnahme deshalb unverändert:

PHP aktualisieren, alle PHP-Worker neu starten und anschließend nach möglichen Angriffsspuren suchen.

Aktuell gepatcht sind:

• PHP 8.5.12

• PHP 8.4.27

• PHP 8.3.36

• PHP 8.2.35

Wer noch eine ältere beziehungsweise nicht unterstützte PHP-Version verwendet, sollte die Sicherheitsinformationen seines Distributors prüfen oder möglichst auf einen unterstützten PHP-Zweig wechseln.

Bei PHP2Shell würde ich mich jedenfalls nicht darauf verlassen, dass ein WAF, ein CMS-Update oder irgendein Plugin das Problem schon irgendwie auffängt.

Die Schwachstelle steckt in PHP selbst – und genau dort muss sie auch geschlossen werden.

Quellen

The Hacker News – PHP2Shell Exploitation Hits Government Entity Amid Global Scanning and Signs of AI-Assisted Hacking
https://thehackernews.com/2026/10/php2shell-exploitation-hits-government.html

Palo Alto Networks Unit 42 – Threat Brief zu CVE-2026-109618 und CVE-2026-109619
https://unit42.paloaltonetworks.com/cve-2026-109618-cve-2026-109619/

PHP – Offizielle Sicherheitsinformationen
https://www.php.net/

CYFIRMA – Suspected DPRK Campaign staging PHP2Shell Targeting against Global PHP infrastructure
https://www.cyfirma.com/research/cyfirma-threat-advisory-suspected-dprk-campaign-staging-php2shell-targeting-against-global-php-infrastructure/

Datadog Security Labs – PHP2Shell: Detection, Analysis and Remediation
https://securitylabs.datadoghq.com/articles/php2shell-critical-vulnerabilities-in-php/

ReliaQuest – PHP2Shell Threat Spotlight
https://reliaquest.com/blog/threat-spotlight-php2shell-responding-to-critical-php-vulnerabilities/

Bitsight – PHP Observation Footprint
https://www.bitsight.com/groma-explorer/php/php