Oktober 22, 2026
PHP2Shell: Warum zwei PHP-Lücken Behörden, Kliniken und Hochschulen vom Netz nehmen Am 21. Oktober 2026 hat PHP zwei kritische Schwachstellen
Lesezeit ca. 20 Min
Nach Angaben des PHP-Projekts wurden am 21. Oktober 2026 zwei kritische Lücken in der Skriptsprache PHP geschlossen, CVE-2026-109618 und CVE-2026-109619, gemeinsam php2shell genannt, die unauthentifizierte Codeausführung auf Webservern erlauben können. Einen ersten Ausnutzungsversuch verzeichnete Amazon nach eigenen Angaben schon am 17. Oktober; eine Kompromittierung einer Organisation bestätigten BSI und CISA in ihren Mitteilungen vom 22. und 23. Oktober nicht.
Kapitel 1 von 4
Eine Meldung wie die zu php2shell sagt, welche Lücke es gibt, aber nicht, wo sie im eigenen Netz sitzt. ProSec Networks setzt einen Test deshalb beim Scope an: Am Ende soll für jeden aus dem Netz erreichbaren Dienst feststehen, welche PHP-Version und welche Betriebsart dahinter arbeitet und ob der Weg dorthin nachgewiesen ist. Dieses erste von vier Kapiteln trennt, was die Advisories je Lücke und Betriebsart als betroffen und was sie als validiert führen, und klärt, wer davon wirklich erreichbar ist.
Das PHP-Projekt hat am 21. Oktober 2026 die Lücken CVE-2026-109618 und CVE-2026-109619 mit PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 geschlossen und nennt das Update die einzige sichere Wahl.1 Angekündigt war 14:00 UTC, die Advisories des Projekts erschienen um 13:34 UTC, der früheste belegte Zeitpunkt.2 Einen ersten Ausnutzungsversuch verzeichnete Amazon nach eigenen Angaben am 17. Oktober in seinem Honeypot-Netz, vier Tage vor der Offenlegung, und schließt bei den Versuchen vom 21. Oktober auf mehrere Akteure.3
Eine Kompromittierung einer Organisation bestätigten weder das Bundesamt für Sicherheit in der Informationstechnik (BSI) in seinem Hinweis vom 22. Oktober noch die US-Behörde CISA in ihrer Fassung vom 23. Oktober;4,5 die Zuordnung eines Falls bei einer europäischen Regierungsbehörde zu php2shell zog Unit 42 am 25. Oktober zurück.6 Codeausführung auf einem Honeypot mit Apache, mod_php und PHP 8.4.26 berichtete BleepingComputer am 26. Oktober nach Angaben eines Forschers, die ein zweiter Forscher bestätigt habe.7 Nach dem Muster, nach dem wir einen solchen Fall lesen, zählt zuerst, wie der Weg hinein verläuft und an welcher Stufe eine Kontrolle greift, nicht die Schlagzeile.
Gefährdet ist laut PHP-Projekt jede Installation, die Webanfragen bedient, ob PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP oder LiteSpeed; das höchste Risiko sieht es bei mod_php.1 Wie weit die Lücken zurückreichen, geben die Quellen verschieden an: Die amerikanische Schwachstellendatenbank NVD führt CVE-2026-109618 ab Version 7.3.0 und CVE-2026-109619 ab Version 5.4.0,8,9 das BSI nennt nach CERT-EU alle bekannten Versionen bis mindestens PHP 5.4 Nach unserer Einordnung folgt für den Scope aus beiden Angaben dasselbe: Jede noch laufende Altversion gilt als betroffen.
Die für PHP zuständige Vergabestelle bewertet beide Lücken mit CVSS v4.0 9,2, NIST nach v3.1 CVE-2026-109618 mit 9,8 und CVE-2026-109619 mit 8,1.8,9 Der Unterschied bei der zweiten Lücke liegt nach unserer Einordnung in der Angriffskomplexität; für die Frage, ob ein Server das Update braucht, genügt, dass beide kritisch sind.
Spur: CVE-2026-109618 und CVE-2026-109619 im Interpreter, betroffen in jeder Betriebsart und auf jeder noch laufenden Altversion. Eine Prüfung stellt je erreichbarem Server fest, ob PHP dort Anfragen bedient, in welcher Betriebsart und auf welchem Zweig.
Die Advisories trennen genauer als die Ankündigung: zwischen betroffen und validiert, also dort, wo die Codeausführung tatsächlich vorgeführt wurde. Für CVE-2026-109618 ist vollständige Codeausführung über HTTP gegen mod_php mit Standardlimits und normaler Prefork-Konfiguration validiert; FPM gilt nach Quellanalyse als anfällig, ein vollständiger FPM-Exploit ist nicht demonstriert.2 Für CVE-2026-109619 ist Codeausführung gegen mod_php validiert und über den Session-Lebenszyklus auch gegen FPM mit einem normalen dynamischen Pool, dort abhängig von einer passenden Operation der Anwendung. Die Ausnutzung braucht laut Advisory einen Erzeuger und einen Verbraucher in verschiedenen Anfragen an denselben Worker, also mindestens zwei Anfragen.10 Die PHP Foundation schreibt, auf FPM sei Codeausführung über anwendungsseitige Codepfade bestätigt, ohne die Lücke zu nennen;11 wir folgen den Advisories als technischer Primärquelle.
Nach unserer Einordnung entscheidet die Betroffenheit, ob ein Server das Update braucht, der Nachweis der Ausnutzung entscheidet die Reihenfolge. Zuerst kommt mod_php, wo für beide Lücken Anfragen ohne Anmeldung genügen und der Weg greift, bevor Anwendungscode läuft, dann PHP-FPM mit der zweiten Lücke über Sessions, danach die übrigen Betriebsarten.
Spur: Klasse: Betriebsart, in der die Ausnutzung nachgewiesen ist. Eine Prüfung ordnet jeden erreichbaren Server der Betriebsart zu, die seine Anfragen bedient, und stellt mod_php vor FPM und die übrigen Betriebsarten.
Eine Anmeldung in der Anwendung hält den Weg laut Datadog nicht auf, weil PHP eingehende Anfragen vor jedem Anwendungscode verarbeitet.12 Nach unserem Prüfansatz ist erreichbar deshalb nicht nur die öffentliche Startseite, sondern jeder Endpunkt, an dem eine HTTP-Anfrage ohne Anmeldung bei einem PHP-Worker ankommt: hinter einer Anmeldemaske, in einem Verwaltungsbereich, unter einer Subdomain, die im Inventar fehlt. Bei FPM entscheidet für die zweite Lücke zusätzlich die Anwendung mit, ob der Weg offen ist; das zeigt nur die Prüfung am einzelnen System.
Angreifer folgen Wegen, nicht Listen. Eine Liste der Websites zeigt die Fläche, die man kennt; ein Test fragt, welcher Weg von außen tatsächlich beim Interpreter ankommt. Ein Dienst, der nur aus dem internen Netz antwortet, fällt dabei nicht aus dem Scope, er rückt in der Reihenfolge nach hinten; welche Rolle er nach einem ersten Zugriff spielt, ist eine Frage der Reichweite.
Spur: Klasse: Endpunkt mit PHP, der Anfragen ohne Anmeldung annimmt und im Inventar mangelhaft erfasst ist. Eine Prüfung stellt je Dienst fest, ob Anfragen ohne Anmeldung einen PHP-Worker erreichen, unabhängig davon, ob die Anwendung eine Anmeldung verlangt.
Die folgenden Prüfungen setzen Server voraus, die Sie selbst betreiben; führen Sie sie nur gegen eigene Systeme aus, als root oder mit sudo, sonst bleiben Prozesse und Module unvollständig. In Containern gelten sie im Container. Welche Dienste Anfragen aus dem Netz annehmen und welcher Prozess dahinter steht:
ss -tlnp
Erwartet ist, dass nur bewusst exponierte Ports lauschen; ein Port, den niemand zuordnen kann, gehört in den Scope. Der Befehl zeigt den Host, nicht, was eine vorgeschaltete Firewall oder ein Load Balancer tatsächlich durchlässt. Die Betriebsart, für Dienste unter systemd:
apachectl -M | grep -i php
systemctl list-units --type=service --all | grep -i fpm
Steht in der ersten Ausgabe ein Modul mit php im Namen, ist mod_php geladen und gehört nach vorn; die zweite zeigt die FPM-Dienste. Die erste Zeile gibt es nur unter Apache; bei anderen Webservern zeigt deren Konfiguration, wie PHP angebunden ist.
Das zweite Kapitel nimmt die Frage, warum eine Versionsangabe oder ein Scanner die Lücke nicht zuverlässig zeigt und wie ein Test die Reihenfolge festlegt.
Kapitel 2 von 4
Die Versionsnummer im Header sagt wenig darüber, ob eine PHP-Installation den Fix trägt. Eine Priorisierung setzt bei ProSec Networks deshalb beim Paketstand an: Für jeden erreichbaren Dienst soll klar sein, welche PHP-Laufzeit seine Anfragen tatsächlich beantwortet, ob sie den Fix trägt und welcher Weg dorthin die wenigsten Voraussetzungen hat. Das zweite Kapitel zeigt, warum Versionsscans und Scanner die Lücke nicht zuverlässig anzeigen und wie ein Test die Reihenfolge festlegt.
Nach der Zählung von VulnCheck, veröffentlicht am 21. Oktober, liefen von 2.608.039 aus dem Internet erreichbaren Hosts mit PHP mehr als 1,1 Millionen, etwa 42 Prozent, auf End-of-Life-Zweigen ohne offizielles Release.13 Solche Zählungen beruhen auf der Versionsangabe. VulnCheck nennt die eigenen Zahlen Untergrenzen und weist zugleich darauf hin, dass Distributionen Korrekturen oft ohne Änderung der Versionsangabe zurückportieren;13 laut METANET bedeutet eine unveränderte Nummer nicht, dass Updates fehlen.14 Dass solche Korrekturen auch alte Zweige erreichen, beschreibt ein Hoster: Laut seiner Kundenmail, wiedergegeben bei borncity.com, verteilte all-inkl.com die Updates binnen etwa acht Stunden, auch für PHP 5.6 und 7.x.15
Die Gegenrichtung zeigt das Dashboard von Censys: Am 26. Oktober um 09:15 UTC zählte es weltweit 101.828.437 PHP-Ziele, bei 58.573.073 davon war keine Version erkennbar.16 Nach unserer Einordnung misst eine Zählung von außen damit zwei Dinge nicht: den Fix hinter einer alten Nummer und die Version hinter einem Dienst, der keine zeigt.
Spur: Klasse: Betroffenheit aus einer Versionsangabe von außen abgeleitet. Eine Prüfung stellt je erreichbarem Dienst den tatsächlichen Paketstand samt Rückport fest, nicht die Nummer, die der Server nach außen zeigt.
Laut BSI reicht es nicht, Anwendungen zu aktualisieren; gepatcht werden muss die PHP-Laufzeit darunter.4 Ein Scanner, der die Webanwendung prüft, sieht nach unserer Einordnung deshalb nicht, welcher Interpreter ihre Anfragen verarbeitet; eine Anwendung ohne Befund kann auf einem betroffenen Zweig laufen. Die belastbare Frage ist nicht die Nummer im Header, sondern welche PHP-Version und welche Betriebsart hinter jedem erreichbaren Dienst arbeiten, eingebettetes PHP in Geräten eingeschlossen.
Spur: Klasse: Prüfung der Anwendung statt der Laufzeit. Eine Prüfung stellt die PHP-Laufzeit fest, die die Anfragen eines Dienstes beantwortet, unabhängig vom Stand der Anwendung darüber.
Wie zuverlässig die Ausnutzung gelingt, ist umstritten, und das trennen wir von der Schwere. Laut Advisory zu CVE-2026-109618 können mehr Worker und fremder Verkehr die Zahl nötiger Versuche erhöhen, die Bedingung beseitigen sie aber nicht.2 Laut heise brauchen die Exploits mitunter mehrere Tausend Anfragen, Calif zeigte Systemkommandos nach 38 Sekunden auf einem Laravel-Server.17 Laut VulnCheck fluteten Hunderte Proof-of-Concept-Repositories GitHub, von denen nur sehr wenige echte Exploits seien.13 Öffentliche Exploits scheiterten nach Sansec an Standardinstallationen, wie SecurityWeek berichtet,18 während laut Censys ein aktiv entwickeltes öffentliches Repository Codeausführung gegen PHP 8.4.26 in der offiziellen Produktionskonfiguration beansprucht.19
Unsere Einordnung: Das Scheitern früher Exploits betrifft die Werkzeuge, nicht die Lücke, und ein Scanner, der nach wenigen Versuchen ohne Treffer abbricht, belegt nicht, dass ein Server geschützt ist. Für die Reihenfolge einer Prüfung zählt nicht, wie leicht ein fertiger Exploit läuft, sondern wie wenige Voraussetzungen der Weg hat; deshalb steht mod_php vorn, auch wenn ein Treffer viele Anläufe braucht.
Spur: Klasse: Zuverlässigkeit der Ausnutzung mit der Schwere verwechselt. Eine Prüfung ordnet nach den Voraussetzungen des Wegs je Betriebsart, nicht nach der Verfügbarkeit eines fertigen Exploits oder dem Ergebnis weniger Versuche.
Für 7.4, 8.0 und 8.1 gibt es laut PHP-Projekt nur Korrekturen im Quelltext, kein offizielles Release.1 Censys führte am 26. Oktober 23.695.197 betroffene Ziele auf 8.1 oder älter und 8.764.597 betroffene auf einem Zweig, für den ein Fix bereitsteht;16 Qualys zählt nach SecurityWeek in seinen Kundendaten rund 110 Millionen PHP-Instanzen auf den End-of-Life-Versionen 5.4 bis 8.1, 71 Prozent.18 Hosts, Ziele und Instanzen sind verschiedene Zähleinheiten; nach unserer Einordnung lassen sich die Werte nicht gegeneinander rechnen.
Für die Priorisierung heißt das nach unserem Prüfansatz: Ein Altzweig ohne offizielles Release ist nicht weniger betroffen, er ist schwerer zu schließen. Der Fix muss dort aus dem Quelltext gebaut oder über eine Distribution oder einen Hoster bezogen werden, und erst der Paketstand zeigt, ob das geschehen ist.
Spur: Klasse: Altzweig ohne offizielles Release, dessen Fix nur als Quelltext vorliegt. Eine Prüfung stellt je System fest, ob die Korrektur gebaut oder über eine Distribution eingespielt ist, und führt Systeme ohne belegten Fix vorne.
Nach unserem Prüfansatz ergibt sich die Reihenfolge aus drei Fragen je Dienst: Ist er ohne Anmeldung aus dem Internet erreichbar? Läuft er in einer Betriebsart, in der die Ausnutzung nachgewiesen ist? Ist der Fix im Paketstand belegt, bei Geräten mit eingebettetem PHP beim Hersteller, um die es im dritten Kapitel geht? Vorn stehen aus dem Internet erreichbare Dienste ohne belegten Fix, unter ihnen zuerst mod_php; Dienste mit belegtem Fix fallen nicht aus dem Scope, sie gehen in den Re-Test. Wo zwei Dienste gleich stehen, entscheidet der Business Impact: welche Daten und Zugänge hinter dem Dienst liegen.
Spur: Klasse: Reihenfolge nach Schlagzeile oder Scanner-Ergebnis statt nach dem Weg. Eine Prüfung legt je Dienst Erreichbarkeit, Betriebsart und belegten Fix fest und ordnet danach.
Die folgenden Prüfungen setzen Server voraus, die Sie selbst betreiben; führen Sie sie nur gegen eigene Systeme aus, als root oder mit sudo. Was eine Zählung von außen über Ihren Dienst liest, gegen den eigenen Host:
curl -s -o /dev/null -D /dev/stdout http://127.0.0.1/ | grep -i "x-powered-by"
Erscheint PHP mit Version im Header, lesen Zählungen von außen genau diese Angabe, die nach einem Rückport nicht zum Paketstand passen muss; fehlt die Zeile, sieht eine Zählung dort keine Version. Die Grenze: Ein vorgeschalteter Proxy, ein CDN oder ein anderer virtueller Host kann den Header entfernen oder selbst setzen, sodass die Sicht von außen abweicht, und der Header lässt sich ganz abschalten. Die Version der Installation, die Anfragen beantwortet (Zweig im Befehlsnamen anpassen):
php-fpm8.3 -v
php -v
Maßgeblich ist die Installation, die Anfragen beantwortet, nicht die der Kommandozeile; bei eigenem Build oder offiziellem Image steht dort mindestens 8.5.12, 8.4.27, 8.3.36 oder 8.2.35. Auf 7.4, 8.0 und 8.1 zeigt keine Nummer den Fix an. Ob eine Distribution den Fix zurückportiert hat, obwohl die Nummer gleich blieb:
zgrep -lE "CVE-2026-109618|CVE-2026-109619" /usr/share/doc/php*/changelog.Debian.gz
rpm -q --changelog php-common | grep -E "CVE-2026-109618|CVE-2026-109619"
Erwartet ist ein Treffer für jeden Zweig, der Anfragen beantwortet; ohne Treffer ist der Fix nicht belegt, und schlanke Images entfernen die Changelogs, dort klärt das Advisory der Distribution.
Das dritte Kapitel nimmt die wirkliche Prüffläche: eingebettetes PHP in Appliances und Containern und die Fragen, die ein Scope-Gespräch klärt.
Kapitel 3 von 4
PHP arbeitet nicht nur hinter Websites, sondern auch in Geräten, Verwaltungsoberflächen und Containern. Ob ein Test dort Wirkung erzeugt, entscheidet bei ProSec Networks der Scope: Er legt fest, wo PHP überall läuft und auf welchem Weg es von außen erreichbar ist. Das dritte Kapitel beschreibt diese Prüffläche und die Fragen, die ein Scope-Gespräch klären sollte.
Der Weg hinein setzt hier nur eine aus dem Internet erreichbare Verwaltungs- oder VPN-Oberfläche voraus, deren PHP der Betreiber nicht selbst aktualisieren kann; ein Test trifft ihn an dieser Oberfläche, nicht an der Website. Nach unserer Auszählung nennt das BSI in seinem Hinweis vom 22. Oktober acht Produktfamilien als mindestens teilweise betroffen, F5, Citrix NetScaler, Palo Alto, OPNsense, Netgate pfSense, QNAP, Synology und cPanel, und vier weitere mit bislang unbekannter Betroffenheit oder als nicht betroffen, Cisco, WatchGuard, Sophos und Broadcom; auch webbasierte Oberflächen von ICS-Komponenten hält es grundsätzlich für möglich. Hersteller müssen laut BSI gegebenenfalls neue Firmware veröffentlichen.4 Laut The Hacker News sah Defused Cyber am 25. Oktober php2shell-Sondierungen gegen eigene Honeypots, die VPN-Portale von Palo Alto Networks GlobalProtect nachbilden.20
Dass Angreifer php2shell binnen sechs Monaten über Verwaltungsoberflächen von Appliances nutzen, deren Hersteller Updates verzögert liefern, halten wir für möglich, 55 bis 75 Prozent, bei niedriger Konfidenz; der mögliche Schaden ist sehr hoch, weil Appliances an der Netzgrenze stehen. Für die Reihenfolge einer Prüfung heißt das: Erreichbare Verwaltungs- und VPN-Oberflächen mit eingebettetem PHP gehören in die erste Reihe, neben die Webserver mit mod_php.
Spur: CVE-2026-109618 und CVE-2026-109619 in eingebetteten PHP-Laufzeiten. Eine Prüfung gleicht jede aus dem Internet erreichbare Verwaltungs- und VPN-Oberfläche mit dem Inventar und der Herstellerangabe ab, nicht mit der Versionsangabe der Website.
Als Arbeitsliste dient die Produktliste des niederländischen Nationaal Cyber Security Centrum (NCSC-NL). Nach unserer Auszählung mit Stand 26. Oktober, 03:24 Uhr MEZ, führt sie 751 Produkteinträge mit Status in 27 Teillisten, bei höchstens 462 Anbietern; zu CVE-2026-109618 stehen 216 als verwundbar, 378 in Prüfung, 119 mit Fix und 38 als nicht verwundbar, zu CVE-2026-109619 sind es 214, 380, 118 und 39.21 Die Einträge sind laut NCSC-NL Ermittlungshinweise, bis eine Upstream- oder Herstellerquelle sie belegt; der Status mit Fix heißt, dass eine Korrektur angeboten wird, nicht dass sie eingespielt ist.21 Rund die Hälfte der Einträge ist damit noch in Prüfung. Nach unserer Einordnung ersetzt bei diesen Geräten der Status beim Hersteller die Versionsangabe, und für sie kann auch ein Scanner nichts belegen. CERT-Bund führt die Lücken in seiner Warnung des Warn- und Informationsdienstes als kritisch, mit 15 Herstellerzweigen im Produktbaum der Version 4 nach unserer Auszählung.22
Die Liste ist der Startpunkt, der Weg entscheidet sich an der erreichbaren Oberfläche. Das FBI rät in einer Mitteilung seiner Meldestelle IC3 vom 23. Oktober, Herstellerprodukte mit gebündeltem PHP zu inventarisieren;23 welche Pflichten zu einer solchen Produktliste und zu Lieferanten gehören, ist das Thema von ProSec Governance. Für den Scope zählt, dass jedes Gerät mit Weboberfläche im Inventar steht und sein Eintrag beim Hersteller geklärt ist.
Die regulatorische Perspektive
Welche Nachweise, Meldungen und Entscheidungen im Nachgang gefragt sind, ordnet unsere Schwestergesellschaft ProSec Governance regulatorisch ein.
Spur: Klasse: eingebettetes PHP, das der Betreiber nicht selbst aktualisieren kann. Eine Prüfung klärt jeden Eintrag in Prüfung beim Hersteller und belegt je Gerät, ob die Firmware mit Fix eingespielt ist.
Docker-Container mit PHP sind laut BSI zu aktualisieren oder neu zu bauen.4 Für den Scope zählt deshalb, welche PHP-Version in jedem laufenden Container Anfragen beantwortet, nicht wann sein Image gebaut wurde.
Zwei Fragen aus dem Scope-Gespräch entscheiden, wie weit ein einzelner Zugriff trägt. Erstens: Ist der Ursprungsserver hinter einer Web Application Firewall oder einem Content Delivery Network direkt erreichbar? Regeln am Rand greifen nur, solange der Verkehr über den Rand läuft; ein direkt erreichbarer Ursprung umgeht sie. Zweitens: Teilen sich mehrere Websites einen PHP-FPM-Pool und denselben Systembenutzer? Dann reicht ein Zugriff über eine dieser Seiten so weit wie dieser Benutzer, also über alle Seiten des Pools. Nach unserem Prüfansatz gehört beides in den Scope, bevor ein Test beginnt, weil es über die Wirkung eines einzigen Fundes entscheidet.
Spur: Klasse: geteilter FPM-Pool mit gemeinsamem Systembenutzer und ein hinter WAF oder CDN direkt erreichbarer Ursprung. Eine Prüfung stellt fest, wie viele Seiten ein Pool und sein Benutzer tragen und ob der Ursprung ohne den Rand erreichbar ist.
Die folgenden Prüfungen setzen eigene Systeme voraus; die Erreichbarkeit des Ursprungs prüfen Sie nur gegen den eigenen Host. Lesende Abfragen als root oder mit sudo. Welche FPM-Pools es gibt, unter welchem Benutzer sie laufen und worauf sie lauschen:
grep -rnE "^\[|^user|^group|^listen" /etc/php*/fpm/pool.d/ /etc/php-fpm.d/
Erwartet ist je Pool ein eigener, unprivilegierter Benutzer; teilen sich mehrere Seiten einen Pool und einen Benutzer, reicht ein Zugriff so weit wie dieser Benutzer. Ob der Ursprung hinter WAF oder CDN auch direkt erreichbar ist, gegen die eigene Ursprungsadresse (Adresse und Host anpassen):
curl -s -o /dev/null -w "%{http_code}\n" --resolve www.example.org:443:203.0.113.10 https://www.example.org/
Antwortet der Ursprung unter seiner eigenen Adresse mit 200, ist er ohne den Rand erreichbar, und Regeln am Rand greifen nicht zwingend. Welche PHP-Version in laufenden Containern Anfragen beantwortet (unter Podman oder Kubernetes mit podman ps oder kubectl entsprechend):
docker ps --format "{{.Names}} {{.Image}} {{.RunningFor}}"
docker exec <name> php-fpm -v
Erwartet ist je Container mit PHP die korrigierte Version des Zweigs oder ein Paketstand, den das Advisory der Distribution als korrigiert führt; das Baudatum allein belegt nichts. Für Appliances ersetzt kein Befehl die Angabe des Herstellers: Erwartet ist, dass jedes Gerät mit Weboberfläche im Inventar steht und sein Eintrag bei NCSC-NL als nicht verwundbar oder mit eingespieltem Fix geführt ist.
Das vierte Kapitel nimmt die Frage nach dem ersten Zugriff: wie weit das Konto des Webservers reicht und wann ein Befund als geschlossen gilt.
Kapitel 4 von 4
Ein offener Weg ist nur die halbe Antwort. Unter Assumed Breach misst ProSec Networks auch, wie weit ein erster Zugriff reicht: was das Konto des Webservers lesen und starten könnte, welche Systeme es von dort erreicht und ob ein Befund nach dem Re-Test wirklich geschlossen ist. Das vierte Kapitel geht diesen Schritten nach dem Einstieg nach.
Ob ein offener Weg Schaden erzeugt, entscheidet, wie weit er reicht; genau das messen wir, nicht die Lücke allein. Die Reichweite ist eine Frage der Konfiguration und der Rechte, keine Frage der Technik des Einstiegs. Unter Assumed Breach prüfen wir für Ihre eigene Umgebung: Was darf das Konto des Webservers unterhalb des Webverzeichnisses schreiben? Welche Geheimnisse in Konfigurationsdateien, also API-Schlüssel, Datenbankzugänge und Zertifikate, kann es lesen? Welche internen Systeme und welche Ziele nach außen erreicht es von dort? Und berührt der Prozess einen Container-Socket, über den er den Host erreicht?
Der IT-Grundschutz des BSI verlangt in APP.3.2.A1, den Webserver-Prozess einem Konto mit minimalen Rechten zuzuweisen, ihn gekapselt auszuführen und nicht benötigte Module und Funktionen zu deaktivieren.24 Das BSI empfiehlt zudem, SELinux und AppArmor zu konfigurieren, um die Auswirkungen von Remotecodeausführung zu begrenzen, und nennt ungewöhnliche Shells, Kindprozesse und Download-Werkzeuge wie curl oder wget, die durch Webserver gestartet werden, als verdächtig;4 die CISA nennt PHP-Worker, die Shells starten oder Werkzeuge herunterladen, als Beobachtungspunkt.5 Laut VulnCheck, wie The Hacker News berichtet, erlaubt eine erfolgreiche Ausnutzung Codeausführung mit den Rechten der Webanwendung, potenziell mit Zugriff auf API-Schlüssel und Datenbankverbindungen;25 was die Anwendung lesen kann, kann auch eingeschleuster Code lesen. Der Business Impact bemisst sich daran, nicht an der Lücke.
Spur: Klasse: Webserver-Konto mit zu weiten Rechten oder mangelhafter Kapselung. Eine Prüfung stellt fest, unter welchem Konto die PHP-Worker laufen, ob SELinux oder AppArmor sie einschränkt und welche Geheimnisse und Ziele in ihrer Reichweite liegen.
Laut Wiz gehört die Offenlegung von Worker-Speicher ohne Anmeldung zu CVE-2026-109618, und ausgelesener Prozessspeicher kann Passwörter, Authentifizierungstoken, API-Schlüssel und Zertifikate enthalten;26 die Zuordnung dieser Wirkung ist zwischen den Quellen umstritten. Für die Prüfung zählt die Reichweite: welche Geheimnisse im Speicher der Worker und in den lesbaren Konfigurationsdateien liegen und wohin sie Zugang geben.
Für Systeme, die vor dem Update erreichbar waren, gilt nach unserer Einordnung der Teil von DER.2.1.A6 des IT-Grundschutzes, nach dem alle Zugangsdaten auf betroffenen Komponenten vor der Wiederinbetriebnahme zu ändern sind.24 Die Erneuerung der Zugangsdaten als Sofortmaßnahme, der Notfall-Patch und die Schutzregeln sowie die Erkennung und die Spurensuche ab dem 17. Oktober sind das Thema von ProSec Defense.
Die defensive Perspektive
Wie Unternehmen sich gegen PHP2Shell schützen und welche Gegenmaßnahmen sinnvoll sind, zeigt unsere Schwesterfirma ProSec Defense im Beitrag zu PHP2Shell und dem WAF-Notfall-Patch.
Spur: Klasse: Geheimnisse im Lesezugriff des Webserver-Kontos, deren Erneuerung für vor dem Update erreichbare Systeme aussteht. Eine Prüfung stellt fest, welche Schlüssel, Token und Datenbankzugänge das Konto lesen kann und welche seit dem Update erneuert sind.
Patchen bereinigt laut dem neuseeländischen National Cyber Security Centre bereits kompromittierte Systeme nicht;27 ein Update schließt den Weg, es belegt nicht, dass vorher niemand da war. Nach unserem Prüfansatz gilt ein Befund erst dann als geschlossen, wenn ein Re-Test ihn unter denselben Bedingungen nicht mehr reproduziert; erst der Re-Test zeigt, ob die Übergangsmaßnahme an der richtigen Stelle sitzt oder nur im falschen Kontext gesetzt wurde.
Zum Re-Test gehören auch die Befunde aus dem Scope: der Zweig ohne belegten Fix, die Firmware, deren Fix angeboten, aber nicht eingespielt war, der geteilte Pool und der direkt erreichbare Ursprung. Jeder davon gilt erst als geschlossen, wenn die Prüfung unter denselben Bedingungen ihn nicht mehr findet.
Spur: Klasse: ein Befund ohne Nachweis seiner Behebung. Eine Prüfung schließt ihn erst, wenn ein Re-Test ihn unter denselben Bedingungen nicht mehr reproduziert.
Die folgenden Prüfungen setzen eigene Systeme voraus; lesende Abfragen als root oder mit sudo, in Containern im Container. Unter welchem Konto die Worker laufen und ob eine Kapselung greift:
ps -eo user,comm | grep -E "php|apache2|httpd|nginx" | sort | uniq -c
ps -eZ | grep -E "httpd|php-fpm|apache2"
getenforce
aa-status
Die Worker sollten unter einem eigenen Konto mit minimalen Rechten laufen, nicht unter root; entscheidend ist die zweite Zeile: unter SELinux httpd_t statt unconfined_service_t, unter AppArmor ein Profilname statt unconfined. Welche Geheimnisse das Konto der Worker lesen kann (Webverzeichnis und Benutzer anpassen):
sudo -u www-data find /etc /var/www -name "*.env" -o -name "config*.php" -o -name "*.pem" 2>/dev/null
Jede Datei in dieser Liste liegt im Lesezugriff des Webserver-Kontos; prüfen Sie, welche Schlüssel und Zugänge darin stehen und ob sie seit dem Update erneuert sind. Was das Konto unterhalb des Webverzeichnisses schreiben darf:
sudo -u www-data find /var/www -writable -type d
Erwartet sind nur bewusst beschreibbare Verzeichnisse, etwa für Uploads oder Cache; ein beschreibbares Code-Verzeichnis erweitert, was ein Zugriff erreicht. Ob der Prozess einen Container-Socket berührt:
ls -l /var/run/docker.sock 2>/dev/null
id www-data
Erreicht das Webserver-Konto den Docker-Socket, etwa über die Gruppe docker, reicht ein Zugriff bis zum Host. Protokolle nach Spuren ab dem 17. Oktober zu durchsuchen gehört zur Erkennung und steht hier nicht; dieser Kasten bleibt bei Erreichbarkeit und Rechten.
Vollständig schützt nur das Update; betroffen ist jede Betriebsart, und die Reihenfolge folgt dem, wo die Ausnutzung nachgewiesen ist, mod_php zuerst. Ob der Fix eingespielt ist, zeigt der Paketstand oder die Angabe des Herstellers, nicht die Versionsangabe, die eine Zählung von außen liest, und Altzweige ohne offizielles Release bleiben am längsten offen. Wo PHP eingebettet in Appliances und Containern steckt, entscheidet der Scope über die Prüffläche, und ein geteilter Pool oder ein direkt erreichbarer Ursprung bestimmt, wie weit ein einzelner Zugriff trägt. Wie weit eingeschleuster Code käme, misst sich an den Rechten des Webserver-Kontos und den Geheimnissen in seinem Zugriff, und ein Befund gilt erst nach dem Re-Test als geschlossen.
Welche Ihrer Systeme PHP aus dem Netz erreichbar machen, in welcher Betriebsart, auf welchem Stand und mit welchen Rechten, zeigt ein Penetrationstest, der Webserver, Appliances und Container unter echten Bedingungen prüft, unter Assumed Breach die Reichweite eines ersten Zugriffs misst und die Behebung im Re-Test erneut nachweist.
offiziell mitgeteilt amtliche Texte und Stellen · berichtet Presse und Fachmedien
Hinweis: Dieser Beitrag ist eine fachliche Einordnung und keine Rechtsberatung, Steuerberatung oder sonstige Rechtsdienstleistung. Er ersetzt keine Prüfung des Einzelfalls durch eine zugelassene Rechtsanwältin oder einen zugelassenen Rechtsanwalt. Aussagen zu Gesetzen, Pflichten, Normen und Fristen sind unsere Lesart zum genannten Informationsstand; vor einer Entscheidung im eigenen Haus sind Rechtsquellen und Fristen zu prüfen.
Informationsstand: 26.10.2026
PHP2Shell: Warum zwei PHP-Lücken Behörden, Kliniken und Hochschulen vom Netz nehmen Am 21. Oktober 2026 hat PHP zwei kritische Schwachstellen
OpenAI-Agent und Hugging Face: Was Unternehmen und Entscheider jetzt wissen sollten Ein autonomer KI-Agent von OpenAI soll während eines Cybersecurity-Tests
WordPress Supply-Chain-Angriff, IT Security für Unternehmen, Plugin-Sicherheit, Cybersecurity, Lieferkettenangriff Was auf den ersten Blick wie ein WordPress-Plugin-Problem wirkt, ist in
