Als PHP2Shell bekannt wurde, bat eine G7-Regierung Red Sift um jeden exponierten Host in ihrer gesamten staatlichen IT-Landschaft – und erhielt die Liste, jeder Host dem zuständigen Ressort zugeordnet.
Zwei kritische Schwachstellen in PHP betreffen jede Version seit PHP 5. Regierungen weltweit stellten dieselbe Frage: Wo betreiben wir PHP? Die meisten zogen den Stecker. Eine fragte uns – und hatte die Antwort für ihre gesamte staatliche IT-Landschaft, bevor die Patches erschienen.
Das sind die besten Daten, die wir gesehen haben.
Das PHP-Team kündigt einen Notfall-Fix einen Tag im Voraus an. Die CVE-Kennungen sind noch am selben Abend im Netz, und CERT-EU veröffentlicht einen Sicherheitshinweis, bevor es überhaupt einen Patch gibt. Die Honeypots von Amazon hatten bereits drei Tage zuvor einen Sondierungsversuch gegen die Schwachstellen erfasst.
Für alle, die staatliche Infrastruktur betreiben, ist das Problem unmittelbar. Jede Version seit PHP 5 kann betroffen sein. Ein Versionsfilter hilft nicht weiter. Der einzig sichere Ausgangspunkt ist eine vollständige Liste aller aus dem Internet erreichbaren Hosts mit PHP, in jeder Version, überall in der IT-Landschaft.
Keine Stichprobe, nicht nur ein Ressort. Alle Ministerien und Behörden in der Zuständigkeit der Regierung, aufgelöst bis auf namentlich benannte Hosts. Wer diese Liste von Hand erstellt, muss Asset-Register, Cloud-Konten, Dienstleister und Appliances durchgehen, die PHP enthalten, ohne es auszuweisen. Das sind Wochen Arbeit – und das Patch-Fenster öffnet sich am nächsten Nachmittag.
Red Sift Hardenize, unsere Lösung für Angriffsflächenmanagement (ASM), findet und überwacht laufend aus dem Internet erreichbare Server und erfasst, welche Software auf jedem von ihnen läuft. Das Inventar, das die Regierung brauchte, war bereits vorhanden. Wir haben es abgefragt, jeden PHP-Host dem zuständigen Ressort zugeordnet und die Liste für die gesamte IT-Landschaft in einer Übersicht geliefert, bevor die korrigierten Versionen am 21. Oktober um 13:30 UTC veröffentlicht wurden.
Derselbe Scan lief über alle ASM-Kunden. Alle direkt Betroffenen erhielten vor dem Patch ihre eigenen Hostnamen, den Release-Zeitpunkt und die offiziellen Sicherheitshinweise.
Andere Anbieter sagen uns, es sei unmöglich, Daten in der Detailtiefe zu bekommen, die Red Sift liefern kann.
Der Patch dauert Minuten. Jeden Host zu finden, der ihn braucht, kann Wochen dauern. Die Regierungen, die am schnellsten handelten, hatten die Liste schon.
Eine Regierung hat gefragt. Jeder betroffene Kunde von Red Sift ASM erhielt dasselbe: eine namentliche Liste seiner PHP-Hosts, bevor der Fix am 21. Oktober erschien. Dann haben wir gemessen, was die Kunden damit gemacht haben – fünf Tage lang, jeden Tag.
PHP CVE-2026-109618 / 109619 · 21.–26. Okt. 2026
10.114
weniger bekannte verwundbare Kundenserver in fünf Tagen.
Ein Rückgang um 62 %, von 16.203 auf 6.089. Die Zahl der Kundenorganisationen mit einem bekannten verwundbaren Server sank von 443 auf 254.
Jeder betroffene Kunde hatte seine namentliche Hostliste, bevor der Fix erschien.
redsift.comQuelle: tägliche Scans von Red Sift der aus dem Internet erreichbaren Kundenserver; Nettoveränderung, 21. vs. 26. Okt. 2026.
Am 26. Oktober liefen 4.909 der 6.089 weiterhin exponierten Kundenserver mit PHP 8.1 oder älter. Für diese Versionen gibt es kein offizielles PHP-Release, das sich installieren ließe. Sie brauchen einen Backport des Herstellers oder ein Upgrade. Dort liegt jetzt die Arbeit, und sie beginnt mit derselben Frage wie am ersten Tag: Welche Ihrer Server sind das?
Könnten Sie diese Übersicht heute für Ihre eigenen Server erstellen? Falls die Antwort nicht eindeutig ist, schicken wir Ihnen eine einmalige Außenansicht Ihrer Domain.
Umfang: aus dem Internet erreichbare Hosts, auf denen PHP erkannt wurde, in den Kundeninstanzen von Red Sift ASM (Hardenize), täglich verglichen vom 21. bis 26. Oktober 2026. Demo-, Sandbox- und Forschungsinstanzen sind ausgenommen. Organisationen entsprechen Kundeninstanzen.
Gepatcht bedeutet, dass der Host 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder eine spätere Version desselben Zweigs meldet; ein Host, der mehrere Versionen meldet, zählt nur, wenn alle korrigiert sind. Bekannt verwundbar bedeutet, dass er eine nicht korrigierte Version eines beliebigen Zweigs meldet. Hosts mit 8.1 oder älter haben möglicherweise bereits einen Backport, der von außen nicht sichtbar ist.
Alle Veränderungen sind Nettowerte: Ein Server fällt aus der Zählung, wenn er gepatcht, aktualisiert oder außer Betrieb genommen wird oder keine Version mehr meldet. Rund 9.185 Kunden-Hosts gaben am 26. Oktober keine Version preis und werden in keiner Richtung gezählt. Jede Version seit PHP 5 ist betroffen; behandeln Sie diese Hosts daher als potenziell exponiert.
Unsere Lösung für Angriffsflächenmanagement (ASM) findet und überwacht laufend Ihre aus dem Internet erreichbaren Server und erfasst, welche Software auf jedem von ihnen läuft. Wenn eine Schwachstelle wie diese auftaucht, lautet die erste Frage nicht mehr „Wo fangen wir überhaupt an?“, sondern „Hier ist die Liste“.
Bevor das PHP-Team die Fixes veröffentlichte, haben wir jeden überwachten Host unserer gesamten ASM-Kundenbasis gescannt, um die Hosts mit PHP zu finden.
Wir haben jeden betroffenen Host dem verantwortlichen Kunden, Ressort oder der zuständigen Behörde zugeordnet, sodass jede Benachrichtigung genau eine IT-Landschaft betraf.
Alle direkt Betroffenen erhielten die möglicherweise exponierten Hostnamen, den Release-Zeitpunkt und Links zu den offiziellen Sicherheitshinweisen, bevor die korrigierten Versionen veröffentlicht wurden.
Kundenbenachrichtigung · 21. Oktober 2026 · vor dem PHP-Sicherheitsrelease
Angekündigter Release-Zeitpunkt: 21. Okt., 14:00 UTC. Korrigierte Versionen: 8.5.12 · 8.4.27 · 8.3.36 · 8.2.35. Patchen Sie zuerst öffentlich erreichbare Hosts und starten Sie jeden Worker neu.
Die Hostnamen sind Beispiele. Echte Benachrichtigungen enthalten die eigenen Hosts des Kunden.
Externe Scans sehen, was ein Host preisgibt, und decken die Assets in Ihrem Konto ab. Interne Systeme, Hosts außerhalb Ihres überwachten Umfangs und Produkte, die ihre PHP-Laufzeitumgebung verbergen, müssen Sie weiterhin selbst prüfen.
Wenn Sie Kunde von Red Sift ASM sind und keine Benachrichtigung erhalten haben, haben wir auf den für Sie überwachten Hosts kein PHP gefunden. Wir empfehlen dennoch eine kurze Prüfung auf Ihrer Seite.
Der Wert liegt in der Genauigkeit: namentlich benannte Hosts, in Ihrer IT-Landschaft, bevor sich das Patch-Fenster öffnet.
Unabhängig von Ihrem Ausgangspunkt ist der erste Schritt derselbe: Sie müssen jeden aus dem Internet erreichbaren Host kennen, der Ihnen gehört, und wissen, was darauf läuft. So können wir Ihnen helfen, je nachdem, wo Sie stehen.
Sie haben unsere vorläufigen Informationen bereits erhalten: die für Sie überwachten Hosts mit PHP, samt Release-Zeitpunkt und Sicherheitshinweisen. Gern gehen wir mit Ihnen weiter – über die gesamte IT-Landschaft, einschließlich Bereichen, die Sie noch nicht hinzugefügt haben – und helfen Ihnen, den Long Tail an Hosts zu priorisieren, die sich nicht schnell patchen lassen.
Wenn Sie eine nationale Regierung oder eine Stelle des öffentlichen Sektors sind und unser Angriffsflächenmanagement noch nicht nutzen, sprechen Sie mit uns. Wir erstellen bereits Expositionslisten für ganze IT-Landschaften auf nationaler Ebene, aufgelöst bis auf namentlich benannte Hosts – und diese Daten werden daran gemessen, was andere Anbieter liefern können.
PHP betreibt den Großteil des Webs, steckt in Produkten, die Sie nicht selbst entwickelt haben, und der Angriff greift, bevor Ihre Anwendung ihn überhaupt sieht. Wenn Sie heute nicht sagen können, wie viele aus dem Internet erreichbare PHP-Hosts Sie haben, ist das das erste Problem, das Sie lösen sollten – und dabei können wir Ihnen noch diese Woche helfen.
Zusammengestellt aus dem PHP-Sicherheitshinweis, der Warnung des britischen NCSC und unserem eigenen technischen Beitrag.
Beginnen Sie mit aus dem Internet erreichbaren Hosts. Filtern Sie nicht nach Version. Beziehen Sie Container, Basis-Images und alles ein, was aus dem Quellcode gebaut wurde.
8.5.12, 8.4.27, 8.3.36 oder 8.2.35 oder das gepatchte Paket Ihrer Distribution. Für 8.1 und älter: Backport des Herstellers oder Upgrade.
Eine gepatchte Binärdatei nützt nichts bei FPM-Pools oder Apache-Kindprozessen, die noch den alten Code ausführen.
Setzen Sie memory_limit=-1 administrativ, senken Sie post_max_size, setzen Sie session.upload_progress.enabled=0 und unter 8.5 fatal_error_backtraces=0. Starten Sie die Worker erneut neu. Diese Einstellungen blockieren die bestätigten Angriffswege und sind nur als Überbrückung bis zum Patch gedacht.
CERT-EU und das NCSC raten beide, eine aus dem Internet erreichbare Anwendung vom Netz zu nehmen, bis sie korrigiert ist.
Suchen Sie nach Anzeichen einer Kompromittierung auf allem, was Sie nicht schnell aktualisieren konnten, und lesen Sie die Sicherheitshinweise der Hersteller zu Produkten, die PHP mitliefern.
PHP2Shell ist der Name für CVE-2026-109618 und CVE-2026-109619, zwei Schwachstellen in der zentralen PHP-Engine, die Remote Code Execution ohne Authentifizierung ermöglichen. Sie liegen in dem Code, der ausgeführt wird, wenn einem Worker der Speicher ausgeht oder ein fataler Fehler auftritt. Sie hängen also nicht von der Anwendung darüber ab. WordPress, Drupal, Laravel, Eigenentwicklungen und Appliance-Konsolen sind gleichermaßen betroffen.
Jede PHP-Installation, die Webanfragen verarbeitet, kann betroffen sein – unter PHP-FPM, Apache mod_php, php-cgi, FrankenPHP und LiteSpeed. Das höchste Risiko trägt mod_php, weil der demonstrierte Exploit schon beim Parsen der Anfrage greift, bevor eine an Anwendungsrouten gebundene Regel einer Web Application Firewall ihn sehen würde.
Kompilierte Fixes gibt es für vier Zweige. Ältere Zweige erhielten nur Backports im Quellcode oder gar nichts. Eine verwandte dritte Schwachstelle, CVE-2026-115560, wurde am 23. Oktober offengelegt und ist durch die bestehende Mitigation abgedeckt.
| Zweig | Korrigiert in | Status |
|---|---|---|
| 8.5 | 8.5.12 | Unterstützt |
| 8.4 | 8.4.27 | Unterstützt |
| 8.3 | 8.3.36 | Nur Sicherheitsfixes |
| 8.2 | 8.2.35 | Support-Ende 31. Dez. 2026 |
| 8.1 · 8.0 · 7.4 | Nur Backports im Quellcode | Kein kompiliertes Release. Backport des Herstellers oder Upgrade. |
| 7.3 und älter | Keine | Einschließlich PHP 5. Upgrade nötig. |
Korrigierte Versionen veröffentlicht am 21. Oktober 2026 um 13:30 UTC. Quelle: php.net und GitHub Security Advisories.
Appliances und Konsolen bringen es mit. Palo Alto Networks, Fortinet und Cisco prüften ihre Produkte binnen Stunden.
Jede Version seit PHP 5 kann betroffen sein. Die erste Maßnahme laut NCSC: alle Systeme identifizieren, auf denen irgendeine Version läuft.
Rund 42 % der aus dem Internet erreichbaren PHP-Hosts laufen auf Zweigen ohne Support und ohne kompilierten Fix (VulnCheck).
Eine gepatchte Binärdatei nützt FPM-Pools oder Apache-Kindprozessen nichts, bis jeder Worker neu gestartet ist.
Binnen 48 Stunden forderten nationale Cyberbehörden auf vier Kontinenten Organisationen auf, sofort zu patchen oder Systeme vom Netz zu nehmen. Mehrere Regierungen schalteten zuerst ihre eigenen öffentlichen Dienste ab, weil sie noch nicht sagen konnten, welche davon exponiert waren.
NCSC-Warnung und mehr als 50.000 direkte Warnhinweise. Jedes PHP-System identifizieren, patchen oder eine Abschaltung erwägen. 32 Regierungsdienste waren nicht verfügbar und vier nur teilweise, überwiegend als Vorsichtsmaßnahme, wie der Minister am 22. Oktober dem Parlament mitteilte. Das grundlegende Monitoring der Domains des öffentlichen Sektors durch die Government Cyber Unit nutzt Hardenize, das Tool für Angriffsflächenmanagement von Red Sift, das .gov.uk alle acht Stunden scannt.
Regierungsdienste auf Anraten des NCSC-NL vom Netz genommen, darunter DigiD und die Website des Parlaments. Das NCSC-NL pflegt das öffentliche Verzeichnis der Produkte, die PHP enthalten.
Alle öffentlichen Webdienste der Regierung abgeschaltet durch Valtori, die staatliche IT-Behörde, während die Patches eingespielt wurden.
Der Premierminister rief Website-Betreiber auf, sich vorzubereiten und eine Abschaltung zu erwägen. Finanzministerium, Wetterbehörde und nationale Steuerbehörde setzten Dienste aus. JPCERT veröffentlichte Indikatoren für eine Kompromittierung.
Kritische Warnung des BSI. Das ITZBund, der IT-Dienstleister des Bundes, nahm Websites des Bundes rein vorsorglich vom Netz.
Warnung von CERT-FR: betroffene Systeme isolieren. Das Innenministerium nahm die Websites der Präfekturen vom Netz.
CISA und NSA: jetzt patchen oder das System vom Netz nehmen. Laut NSA werden Cyberakteure die Schwachstellen wahrscheinlich als Waffe einsetzen; sie forderte sofortiges Patchen in allen Ministerien und Behörden der US-Regierung.
Sicherheitshinweis 2026-018 von CERT-EU noch vor den Patches, gefolgt von einer gemeinsamen Erklärung von Kommission, ENISA, CERT-EU und Europol.
Warnung AL26-026 des Cyber Centre. Einige Websites der kanadischen Regierung waren vorübergehend nicht erreichbar; die Warnung wurde am 23. Oktober um die dritte CVE ergänzt.
Kritische Warnung des ACSC: jetzt handeln. PHP-Systeme identifizieren, auf bösartige Aktivitäten überwachen, Updates einspielen, sobald sie verfügbar sind.
Einen Dienst vom Netz zu nehmen, ist das letzte Mittel – und Regierungen auf vier Kontinenten griffen binnen Stunden dazu. So groß ist das Inventarproblem, selbst für gut ausgestattete Teams.
Das Angriffsflächenmanagement von Red Sift erfasst jeden aus dem Internet erreichbaren Host in Ihrer IT-Landschaft und was darauf läuft – damit die Antwort schon bereitliegt, wenn die nächste kritische Schwachstelle kommt.
Alle Angaben auf dieser Seite stammen aus öffentlichen Quellen mit Stand 23. Oktober 2026, mit Ausnahme der Ergebnisse in Abschnitt 02, die auf Kundendaten von Red Sift ASM bis 26. Oktober 2026 beruhen. Ausnutzungsstatus und Expositionszahlen ändern sich stündlich; prüfen Sie die Primärquellen, bevor Sie auf Grundlage einer Zahl handeln.