Stand: 22. Oktober 2026 Die Lage zu PHP2Shell entwickelt sich weiter. Wir aktualisieren diesen Artikel, sobald gesicherte Informationen vorliegen, insbesondere zu bestätigten Angriffen. Am 21. Oktober 2026 nahmen Landesportale, Städte, Kliniken, Universitäten und Bundesbehörden ihre Websites vom Netz. Der Grund waren zwei kritische Lücken in PHP, der Skriptsprache hinter WordPress, TYPO3, Drupal und einem großen Teil aller Websites. Das BSI warnte mit Stufe Orange und bewertete das Risiko als außerordentlich hoch. Ein erfolgreicher Massenangriff ist bis heute nicht bestätigt, weil viele Verantwortliche innerhalb von Stunden reagiert haben. Um diese Reaktionszeit geht es in diesem Beitrag. Wir zeigen, was der Fall über Ihren Patchprozess verrät und was Sie vorbereiten sollten, bevor die nächste kritische Lücke kommt. Zeitleiste und technische Details finden Sie weiter unten zum Aufklappen. Was PHP2Shell über Ihren Patchprozess verrät 01 Sie können nur patchen, was Sie kennen Bei PHP2Shell: Die Lücke steckt in der PHP-Laufzeitumgebung, ein Update von TYPO3, WordPress oder Drupal schließt sie nicht. Betroffen sind auch Systeme, die PHP verdeckt mitbringen: Firewalls wie pfSense und OPNsense, NAS-Geräte, Nextcloud-Instanzen. Für Sie: Führen Sie ein Inventar aller Systeme mit Verbindung ins Internet, mit PHP-Version, Betriebsart und verantwortlicher Person. Eine Exposure-Management-Plattform wie Tenable One, die wir im Vulnerability Management einsetzen, liefert diese Übersicht laufend. Was ein Angreifer von außen sieht, zeigt ein externer Pentest: vergessene Microsites, veraltete PHP-Versionen, offene Admin-Logins. 02 Fristen richten sich nach der Exposition, nicht nach dem Wartungsfenster Bei PHP2Shell: Zwischen dem Leak eines Exploits und dem Update lagen weniger als 24 Stunden, das BSI hielt eine breite Ausnutzung binnen Stunden für wahrscheinlich. Kein Einzelfall: Nach einer Auswertung von VulnCheck wurden 28,96 Prozent der Schwachstellen, die 2025 erstmals aktiv ausgenutzt wurden, am Tag ihrer Veröffentlichung oder bereits davor angegriffen. Für Sie: Legen Sie Patchfristen nach Risiko fest. Kritische Lücken an Systemen, die aus dem Internet erreichbar sind, gehören in Stunden geschlossen, nicht im nächsten Monatszyklus. Priorisieren Sie nach tatsächlicher Ausnutzung, denn ein CVSS-Wert allein sagt nicht, ob gerade angegriffen wird. 03 Zeit kaufen, ohne sich darauf zu verlassen Bei PHP2Shell: Cloudflare und Bunny spielten Filterregeln ein, die veröffentlichten Übergangslösungen wie ein geändertes Speicherlimit wirkten nur teilweise. Das BSI stellt klar, dass nur das Update oder die Trennung vom Netz vollständig schützen. Für Sie: Eine Web Application Firewall mit virtuellem Patching verschafft Ihnen maximal Stunden. Nutzen Sie diese Zeit für das Update, als Ersatz taugt sie nicht. 04 Abschalten ist eine Entscheidung, die vorher feststehen muss Bei PHP2Shell: Das BSI empfahl, Webserver bis zum Update vom Netz zu nehmen. Landesportale, Kliniken und Bundesbehörden taten genau das, der Hoster Uberspace schaltete seine PHP-Dienste vorübergehend komplett ab. Für Sie: Klären Sie vorab, wer auch nachts und am Wochenende einen Dienst abschalten darf, welche Systeme Vorrang haben und was Kunden dann sehen. Ein geübter Incident-Response-Prozess und ein geplanter Notbetrieb aus dem Business Continuity Management machen aus dieser Entscheidung Routine. 05 Erkennen, wenn der Angriff vor dem Patch kommt Bei PHP2Shell: AWS registrierte bereits am 17. Oktober einen Exploit-Versuch, vier Tage vor der öffentlichen Bekanntgabe der Schwachstelle. Nach der Veröffentlichung beobachteten auch Cloudflare und watchTowr Angriffsversuche. Wer zu diesem Zeitpunkt noch nicht aktualisiert hatte, musste wissen, ob ein Versuch erfolgreich war. Für Sie: Ein Managed SOC überwacht Webserver auf ungewöhnliche Prozesse, ausgehende Verbindungen und neue Dateien im Webverzeichnis. So fällt ein erfolgreicher Exploit auf, bevor Angreifer sich festsetzen. 06 Langsames Patchen ist eine Risikoentscheidung der Leitung Was auf dem Spiel steht: Ein Sicherheitsvorfall mit Datenabfluss kostet ein Unternehmen in Deutschland im Durchschnitt 4,25 Millionen Euro, in der Fertigung 7,02 Millionen Euro (IBM, Cost of a Data Breach 2026). Nach dem NIS2-Umsetzungsgesetz müssen Geschäftsleitungen Risikomanagementmaßnahmen umsetzen und überwachen, der Umgang mit Schwachstellen gehört ausdrücklich dazu (§ 30 und § 38 BSIG). Für Sie: Machen Sie Patchfristen und das Budget für Schwachstellenmanagement zum Leitungsthema. Wer einen kritischen Patch tagelang liegen lässt, trifft eine Risikoentscheidung, die die Geschäftsleitung verantworten muss. Die neue Realität heißt 119 Lücken am Tag „Bei uns ist noch nie etwas passiert“ beschreibt die Vergangenheit. Die Gegenwart sieht anders aus: Das BSI zählte im Lagebericht 2025 durchschnittlich 119 neue Schwachstellen pro Tag, rund 24 Prozent mehr als im Vorjahreszeitraum, teils methodisch bedingt. Wie dicht diese Folge ist, zeigte dieselbe Woche: Am 21. Oktober schloss auch Node.js vier schwere Lücken, und bei der Zertifizierungsstelle eMudhra wurden acht Zwischenzertifikate kompromittiert. Ähnlich war es Anfang Oktober bei Citrix NetScaler: Auch dort entschied die Reaktionszeit über den Schaden. Es trifft keineswegs nur Konzerne. 80 Prozent der 950 Ransomware-Angriffe, die dem BKA im Berichtszeitraum gemeldet wurden, richteten sich gegen kleine und mittlere Unternehmen. Für die gesamte deutsche Wirtschaft beziffert der Bitkom den Schaden durch Diebstahl, Spionage und Sabotage für 2026 auf 211 bis 270,8 Milliarden Euro, 76 Prozent davon durch Cyberangriffe. 45 Prozent der befragten Unternehmen sehen ihre Existenz durch einen erfolgreichen Angriff bedroht. Wie das im Einzelfall aussieht, zeigt die Einhaus-Gruppe aus Hamm. Nach einem Ransomware-Angriff im Jahr 2023 kam der Betrieb nicht mehr in Gang, mehrere Gesellschaften meldeten Insolvenz an. Berichten zufolge schrumpfte die Belegschaft am Hauptsitz von über 100 auf acht Beschäftigte. Dem gegenüber steht die Prävention: Im Schnitt fließen laut Bitkom 18 Prozent des IT-Budgets in IT-Sicherheit, BSI und Bitkom empfehlen mindestens 20 Prozent. PHP2Shell im Detail Lücke, Zeitleiste und betroffene Systeme zum Aufklappen Was ist PHP2Shell? Unter dem Namen PHP2Shell laufen zwei Schwachstellen im PHP-Interpreter (CVE-2026-109618 und CVE-2026-109619). Das PHP-Projekt bewertet beide mit 9,2 von 10 Punkten im Common Vulnerability Scoring System (CVSS). Angreifer können damit ohne Anmeldung eigenen Code auf dem Webserver ausführen, im ungünstigsten Fall bereits bevor die eigentliche Anwendung startet. Betroffen sind laut PHP-Team alle Versionen seit PHP 5. Entdeckt haben die Lücken die Sicherheitsunternehmen Wiz und Calif gemeinsam mit OpenAI. Das BSI weist auf einen Punkt hin, der über diesen Fall hinausreicht: Angreifer übersetzen veröffentlichte Patches inzwischen mit KI-Unterstützung schneller in funktionierende Angriffswerkzeuge. Wie lief der Fall ab? 20.10.2026: Das PHP-Projekt kündigt Sicherheitsupdates für den 22. Oktober an. Kurz darauf tauchen im Netz ein Screenshot und ein Video eines funktionierenden Exploits auf.21.10.2026: Wegen des Leaks erscheinen die Updates einen Tag früher: PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Denn ein vorzeitig verfügbarer Patch lässt sich heute mithilfe von KI schnell analysieren. So können Schwachstellen innerhalb kürzester Zeit identifiziert und für Exploits genutzt werden. Das BSI veröffentlicht eine Cybersicherheitswarnung.21.10.2026: Betreiber nehmen Websites vorsorglich vom Netz. Der Hoster Uberspace schaltet seine PHP-Dienste vorübergehend ab, Cloudflare und Bunny spielen Filterregeln ein.22.10.2026: Cloudflare und das Sicherheitsunternehmen watchTowr beobachten erste Angriffsversuche. Erfolgreiche Angriffe in der Breite sind nicht bestätigt. Welche Systeme sind betroffen, und was hilft kurzfristig? Betroffen ist jede Installation mit PHP, also auch TYPO3, WordPress, Drupal, Joomla, Magento und Nextcloud. Die Updates tragen die Versionsnummern 8.5.12, 8.4.27, 8.3.36 und 8.2.35, für ältere Zweige sind Backports angekündigt. Am stärksten gefährdet sind Server, auf denen PHP als Apache-Modul (mod_php) läuft. Aber auch Systeme mit PHP-FPM können betroffen sein. Wer nicht sofort aktualisieren kann, sollte den Server nach Empfehlung des BSI vorübergehend vom Netz nehmen. Ob Übergangslösungen wie ein geändertes Speicherlimit oder das Abschalten von Session Upload Progress schützen, ist fraglich. Für Interessierte, die die Technik dahinter verstehen wollen, erklärt der Kanal Hood Informatik die beiden Lücken in einem achtminütigen Video. Wie wir Sie unterstützen Wissen, wo PHP läuft Eine Exposure-Management-Plattform wie Tenable One erfasst Server, Webanwendungen, Cloud-Ressourcen und Appliances und priorisiert Lücken nach tatsächlicher Ausnutzung. So sehen Sie schnell, welche Systeme ein Update brauchen. Angriffsfläche von außen prüfen Ein externer Pentest findet vergessene Microsites, veraltete PHP-Versionen und offene Admin-Logins, bevor Angreifer sie finden. Gegen unbekannte Lücken hilft kein Test, gegen vergessene Systeme schon. Continuous Pentesting hält das Bild aktuell. Zeit gewinnen mit der WAF Eine Web Application Firewall mit virtuellem Patching blockt bekannte Angriffsmuster, bis das Update eingespielt ist. Den Patch ersetzt sie nicht. Angriffe erkennen, bevor es ein Update gibt Kommt der Exploit vor dem Patch, entscheidet die Erkennung. Unser Managed SOC achtet rund um die Uhr auf ungewöhnliche Prozesse und Verbindungen auf Webservern. Entscheidungen vorher klären Wer darf nachts einen Server vom Netz nehmen, wer informiert Kunden und Behörden? Ein geübter Incident-Response-Prozess legt das fest, bevor es eilt. Notbetrieb planen Was läuft weiter, wenn die Website einen Tag offline ist? Business Continuity Management legt fest, welche Abläufe Vorrang haben und wie lange Sie ohne sie auskommen. Notbetrieb planen Was läuft weiter, wenn die Website einen Tag offline ist? Business Continuity Management legt fest, welche Abläufe Vorrang haben und wie lange Sie ohne sie auskommen. Unsere Einschätzung Wie glimpflich PHP2Shell tatsächlich ausgeht, wird sich erst noch zeigen. Entscheidend ist jetzt, wie schnell Betreiber reagieren, Updates einspielen oder gefährdete Systeme gegebenenfalls vom Netz nehmen. Denn aus unserer Erfahrung im Schwachstellenmanagement und in der Incident Response ist die Lücke selbst selten das eigentliche Problem. Den Ausschlag gibt die Zeit zwischen Veröffentlichung und Reaktion. Aus unserer Erfahrung kann sich diese Reaktionszeit bei Unternehmen ohne vollständiges Inventar, feste Abläufe und klare Zuständigkeiten erheblich verlängern.Nicht in Cyber Security zu investieren ist ebenfalls eine Entscheidung. Sie fällt nur weniger auf, weil ihre Kosten erst mit dem Vorfall fällig werden. Quellen BSI: Cybersicherheitswarnung „PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit“ (21. Oktober 2026)PHP Group: Security Releases PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 (21. Oktober 2026)heise online: php2shell: Kritische Sicherheitslücken erlauben Codeeinschleusung in PHP (21. Oktober 2026)Bitkom: Wirtschaftsschutz 2026, Presseinformation (26. August 2026)IBM: Cost of a Data Breach Report 2026, Pressemitteilung (29. Juli 2026)VulnCheck: State of Exploitation 2026 (21. Januar 2026) Wie lange bräuchten Sie für den nächsten kritischen Patch? Sprechen Sie mit unserem Cyber-Security-Team. Wir prüfen mit Ihnen, welche Ihrer Systeme aus dem Internet erreichbar sind, wie schnell kritische Updates heute bei Ihnen ankommen und wo eine Lücke wie PHP2Shell Sie treffen würde. Jetzt Gespräch vereinbaren. < Zurück zur Übersicht IT Security Incident Response
01 Sie können nur patchen, was Sie kennen Bei PHP2Shell: Die Lücke steckt in der PHP-Laufzeitumgebung, ein Update von TYPO3, WordPress oder Drupal schließt sie nicht. Betroffen sind auch Systeme, die PHP verdeckt mitbringen: Firewalls wie pfSense und OPNsense, NAS-Geräte, Nextcloud-Instanzen. Für Sie: Führen Sie ein Inventar aller Systeme mit Verbindung ins Internet, mit PHP-Version, Betriebsart und verantwortlicher Person. Eine Exposure-Management-Plattform wie Tenable One, die wir im Vulnerability Management einsetzen, liefert diese Übersicht laufend. Was ein Angreifer von außen sieht, zeigt ein externer Pentest: vergessene Microsites, veraltete PHP-Versionen, offene Admin-Logins.
02 Fristen richten sich nach der Exposition, nicht nach dem Wartungsfenster Bei PHP2Shell: Zwischen dem Leak eines Exploits und dem Update lagen weniger als 24 Stunden, das BSI hielt eine breite Ausnutzung binnen Stunden für wahrscheinlich. Kein Einzelfall: Nach einer Auswertung von VulnCheck wurden 28,96 Prozent der Schwachstellen, die 2025 erstmals aktiv ausgenutzt wurden, am Tag ihrer Veröffentlichung oder bereits davor angegriffen. Für Sie: Legen Sie Patchfristen nach Risiko fest. Kritische Lücken an Systemen, die aus dem Internet erreichbar sind, gehören in Stunden geschlossen, nicht im nächsten Monatszyklus. Priorisieren Sie nach tatsächlicher Ausnutzung, denn ein CVSS-Wert allein sagt nicht, ob gerade angegriffen wird.
03 Zeit kaufen, ohne sich darauf zu verlassen Bei PHP2Shell: Cloudflare und Bunny spielten Filterregeln ein, die veröffentlichten Übergangslösungen wie ein geändertes Speicherlimit wirkten nur teilweise. Das BSI stellt klar, dass nur das Update oder die Trennung vom Netz vollständig schützen. Für Sie: Eine Web Application Firewall mit virtuellem Patching verschafft Ihnen maximal Stunden. Nutzen Sie diese Zeit für das Update, als Ersatz taugt sie nicht.
04 Abschalten ist eine Entscheidung, die vorher feststehen muss Bei PHP2Shell: Das BSI empfahl, Webserver bis zum Update vom Netz zu nehmen. Landesportale, Kliniken und Bundesbehörden taten genau das, der Hoster Uberspace schaltete seine PHP-Dienste vorübergehend komplett ab. Für Sie: Klären Sie vorab, wer auch nachts und am Wochenende einen Dienst abschalten darf, welche Systeme Vorrang haben und was Kunden dann sehen. Ein geübter Incident-Response-Prozess und ein geplanter Notbetrieb aus dem Business Continuity Management machen aus dieser Entscheidung Routine.
05 Erkennen, wenn der Angriff vor dem Patch kommt Bei PHP2Shell: AWS registrierte bereits am 17. Oktober einen Exploit-Versuch, vier Tage vor der öffentlichen Bekanntgabe der Schwachstelle. Nach der Veröffentlichung beobachteten auch Cloudflare und watchTowr Angriffsversuche. Wer zu diesem Zeitpunkt noch nicht aktualisiert hatte, musste wissen, ob ein Versuch erfolgreich war. Für Sie: Ein Managed SOC überwacht Webserver auf ungewöhnliche Prozesse, ausgehende Verbindungen und neue Dateien im Webverzeichnis. So fällt ein erfolgreicher Exploit auf, bevor Angreifer sich festsetzen.
06 Langsames Patchen ist eine Risikoentscheidung der Leitung Was auf dem Spiel steht: Ein Sicherheitsvorfall mit Datenabfluss kostet ein Unternehmen in Deutschland im Durchschnitt 4,25 Millionen Euro, in der Fertigung 7,02 Millionen Euro (IBM, Cost of a Data Breach 2026). Nach dem NIS2-Umsetzungsgesetz müssen Geschäftsleitungen Risikomanagementmaßnahmen umsetzen und überwachen, der Umgang mit Schwachstellen gehört ausdrücklich dazu (§ 30 und § 38 BSIG). Für Sie: Machen Sie Patchfristen und das Budget für Schwachstellenmanagement zum Leitungsthema. Wer einen kritischen Patch tagelang liegen lässt, trifft eine Risikoentscheidung, die die Geschäftsleitung verantworten muss.