PHP2Shell: Notfallplan für IT-Verantwortliche

Das PHP-Projekt hatte die Updates am 20. Oktober angekündigt und am 21. Oktober 2026 veröffentlicht. Das BSI hat die Lage am selben Tag mit einer Cybersicherheitswarnung der Stufe 3 „Orange“ bewertet. Proof-of-Concept-Exploits sind öffentlich, und das BSI hält eine breite Ausnutzung innerhalb kurzer Zeit für wahrscheinlich. In den Medien läuft die Lücke unter dem Namen „PHP2Shell“, eine bewusste Anspielung auf Log4Shell. Der Vergleich passt: Wie damals steckt die Schwachstelle in einer Grundkomponente, die in sehr vielen Produkten verbaut ist, oft ohne dass die Betreiber es wissen.

Die Fakten im Überblick

Wer betroffen ist, auch ohne eigene Website

Bei PHP denken die meisten an die Unternehmenswebsite. Die Liste ist länger. Das BSI nennt neben WordPress, Drupal, TYPO3, Joomla und Magento ausdrücklich auch Nextcloud, pfSense und OPNsense. PHP steckt außerdem in Weboberflächen von Firewalls, NAS-Systemen, Routern und anderen Appliances, in Ticketsystemen, Warenwirtschafts-Frontends und selbst entwickelten Intranet-Anwendungen. Das niederländische NCSC sammelt auf GitHub eine Liste betroffener Produkte, die laufend wächst.

Für Appliances gilt: Sie können PHP dort meist nicht selbst aktualisieren. Hier hilft nur eine neue Firmware des Herstellers. Bis dahin sollten Verwaltungsoberflächen nicht aus dem Internet erreichbar sein.

Notfallplan in acht Schritten

1. Inventar erstellen. Alle Systeme mit PHP erfassen: Webserver, Container-Images, virtuelle Maschinen, Appliances, Entwicklungs- und Testsysteme. Zuerst die aus dem Internet erreichbaren Systeme.
2. Patchen oder trennen. Internet-exponierte Systeme sofort aktualisieren. Wo das nicht geht, die vorübergehende Trennung vom Internet prüfen. Nach dem Update alle PHP-Prozesse neu starten, sonst läuft der alte Code weiter.
3. Version richtig prüfen. php -v zeigt nur die Kommandozeilen-Version, die sich von der Version im Webserver unterscheiden kann. Prüfen Sie auch den FPM-Dienst oder lassen Sie sich die Version von der Anwendung selbst anzeigen. Bei Debian, Ubuntu oder Red Hat kann ein gepatchtes Paket eine niedrigere Versionsnummer tragen, weil die Korrektur zurückportiert wurde. Maßgeblich ist dann der Sicherheitshinweis der Distribution.
4. Container neu bauen. Ein Update auf dem Host schützt keine Anwendung im Container. Images mit gepatchtem Basis-Image neu bauen, ausrollen und die PHP-Version im laufenden Container prüfen.
5. Übergangsmaßnahmen setzen, wenn ein Update nicht sofort möglich ist. Die Konfiguration aus dem Abschnitt unten verkleinert die Angriffsfläche, schließt die Lücke aber nicht.
6. WAF ergänzend nutzen. Cloudflare, Bunny Shield und andere Anbieter haben Regeln gegen bekannte Angriffswege veröffentlicht. Das verschafft Zeit, ersetzt aber kein Update.
7. Auf Kompromittierung prüfen. Systeme, die nach dem 21. Oktober noch verwundbar und erreichbar waren, gezielt untersuchen. Verbindliche Angriffsindikatoren hat das BSI noch nicht veröffentlicht. Achten Sie auf gehäufte Speicherfehler und Abstürze von PHP-Prozessen, auffällige POST-Anfragen in großer Zahl, neue oder geänderte PHP-Dateien in Upload- und Cache-Verzeichnissen, neue Benutzerkonten, Cronjobs und unerwartete ausgehende Verbindungen.
8. Altlasten abbauen. Alle PHP-Versionen vor 8.2 haben ihr Lebensende erreicht, PHP 8.2 erhält nur noch bis zum 31. Dezember 2026 Sicherheitsupdates. Anwendungen auf diesen Versionen gehören jetzt auf die Migrationsliste.

Übergangskonfiguration laut PHP-Advisory

Das PHP-Sicherheitsteam nennt Maßnahmen, die einzelne Angriffspfade blockieren. Das BSI weist darauf hin, dass alle davon umgesetzt sein müssen, um eine Ausnutzung spürbar zu erschweren, und dass Angreifer sie auf anderem Weg umgehen können.

; in php.ini, FPM-Pool oder Apache-Konfiguration, nicht per ini_set() oder .user.ini
memory_limit = -1                    ; möglichst per php_admin_value, damit Anwendungen es nicht überschreiben
post_max_size = 8M                   ; 32M, wenn Datei-Uploads nötig sind
upload_max_filesize = 6M             ; immer kleiner als post_max_size
session.upload_progress.enabled = 0
fatal_error_backtraces = 0           ; nur PHP 8.5
; danach alle PHP-Worker neu starten

Dazu kommen laut Advisory: Größen- und Anzahlbegrenzungen für Anfragen am Webserver oder Proxy, eine Speicherbegrenzung auf Container- oder cgroup-Ebene statt RLIMIT_AS oder RLIMIT_DATA, das Entfernen ungültiger oder veralteter PHP-Einstellungen pro Verzeichnis und das Beheben von Fehlern, die Angreifer gezielt auslösen können, etwa in Upload- und Importfunktionen. Weil memory_limit = -1 den Speicher pro Anfrage nicht mehr begrenzt, sollte die Grenze auf Container-Ebene die Verfügbarkeit absichern. Ergänzend empfiehlt das BSI, SELinux oder AppArmor zu nutzen, um die Folgen einer erfolgreichen Codeausführung zu begrenzen.

NIS2, ISO 27001 und IT-Grundschutz: was daraus folgt

Für Einrichtungen, die unter das neue BSI-Gesetz fallen, ist PHP2Shell ein Praxistest für die Risikomanagementmaßnahmen nach § 30 BSIG. Abs. 2 Nr. 5 verlangt ausdrücklich das Management von Schwachstellen, Nr. 2 die Bewältigung von Sicherheitsvorfällen. Eine Schwachstelle allein ist noch kein Vorfall. Kommt es aber zu einer erfolgreichen Ausnutzung, kann ein erheblicher Sicherheitsvorfall vorliegen. Dann gelten die Meldefristen nach § 32 BSIG: frühe Erstmeldung binnen 24 Stunden, Meldung binnen 72 Stunden, Abschlussmeldung spätestens einen Monat danach. Unsere NIS2-Beratung hilft bei der Einordnung.

In einem ISMS nach ISO 27001 greifen vor allem die Controls A.8.8 (Management technischer Schwachstellen), A.8.9 (Konfigurationsmanagement), A.8.16 (Überwachung) und A.5.24 bis A.5.26 (Umgang mit Sicherheitsvorfällen). Wer nach IT-Grundschutz arbeitet, findet die Anforderungen in OPS.1.1.3 Patch- und Änderungsmanagement, APP.3.1 Webanwendungen und APP.3.2 Webserver. Eine Übersicht aller Controls bietet unser Beitrag zu den ISO 27001 Annex A Controls.

Dokumentieren Sie den Umgang mit PHP2Shell als Fall im Schwachstellenmanagement: wann bekannt, welche Systeme betroffen, wann gepatcht, welche Übergangsmaßnahmen, welche Prüfungen auf Kompromittierung. Bei der nächsten Prüfung oder dem nächsten Audit ist das ein starker Nachweis, dass der Prozess funktioniert. Wie ein solcher Prozess dauerhaft aufgebaut wird, steht unter Schwachstellenmanagement.

Lehre aus PHP2Shell: Patch-Fenster werden kürzer

Gefunden wurden die Lücken bei einer Code-Prüfung, an der die Sicherheitsfirmen Calif und Wiz gemeinsam mit OpenAI beteiligt waren. Das BSI weist in seiner Warnung darauf hin, dass Angreifer mit KI-gestützten Werkzeugen Patches inzwischen sehr schnell analysieren und daraus Exploits entwickeln können. Für Unternehmen bedeutet das: Ein Patch-Zyklus von mehreren Wochen reicht für kritische, aus dem Internet erreichbare Systeme nicht mehr aus. Wer noch keinen beschleunigten Notfallprozess für kritische Updates hat, sollte ihn jetzt festlegen, mit klaren Zuständigkeiten, Rufbereitschaft und einer Liste der Systeme, die zuerst drankommen. Was die Entwicklung für KI-Verantwortliche bedeutet, beschreibt unser Ratgeber zu KI-gefundenen Schwachstellen.

Die Datenschutzseite des Vorfalls, also Meldepflicht nach Art. 33 DSGVO und Pflichten gegenüber Hostern, behandelt der Beitrag PHP2Shell und Datenschutz. Wie unser Entwicklerteam Anwendungen auf eine aktuelle PHP-Version bringt, steht unter PHP2Shell: PHP-Update und Absicherung.

Häufige Fragen

Was ist PHP2Shell?

PHP2Shell ist die Bezeichnung für zwei kritische Schwachstellen in der PHP-Laufzeitumgebung, CVE-2026-109618 und CVE-2026-109619. Sie erlauben es Angreifern, ohne Anmeldung Code auf Webservern auszuführen. Der Name spielt auf die Log4Shell-Lücke von 2021 an.

Welche PHP-Versionen schließen die Lücke?

PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35, veröffentlicht am 21. Oktober 2026. Für ältere Versionen gibt es nur Quellcode-Backports für 7.4, 8.0 und 8.1 sowie Sicherheitspakete einzelner Linux-Distributionen und LTS-Anbieter.

Hilft ein Update von WordPress oder anderen Anwendungen?

Nein. Die Schwachstellen stecken in PHP selbst und nicht in der Anwendung. Das BSI betont, dass die PHP-Laufzeitumgebung aktualisiert werden muss. Anwendungsupdates bleiben trotzdem sinnvoll, schließen diese Lücke aber nicht.

Schützt eine Web Application Firewall vor PHP2Shell?

Nur teilweise. Anbieter wie Cloudflare haben Regeln für bekannte Angriffswege bereitgestellt. Laut BSI bieten aber nur das Update oder die Trennung vom Internet vollständigen Schutz. Eine WAF ist eine Überbrückung, kein Ersatz.

Muss ich PHP2Shell nach NIS2 melden?

Die Schwachstelle selbst ist nicht meldepflichtig. Meldepflichtig nach § 32 BSIG ist ein erheblicher Sicherheitsvorfall, etwa eine erfolgreiche Ausnutzung mit Auswirkungen auf Ihre Dienste. Dann gilt eine frühe Erstmeldung binnen 24 Stunden und eine Meldung binnen 72 Stunden.

Wie lange wird PHP 8.2 noch unterstützt?

PHP 8.2 erhält nach Angaben des PHP-Projekts nur noch bis zum 31. Dezember 2026 Sicherheitsupdates. Anwendungen auf 8.2 und älter sollten zeitnah auf PHP 8.3 oder 8.4 umgestellt werden.

Sie brauchen schnell Klarheit, ob und wie stark Ihre Systeme betroffen sind? Als externer Informationssicherheitsbeauftragter übernehmen wir Lagebewertung, Priorisierung, Prüfung auf Kompromittierung und die Dokumentation für NIS2 und ISO 27001. Updates und Code-Anpassungen setzt unser Entwicklerteam direkt um, in Dresden, Sachsen und bundesweit. Telefon 0351 79 59 35 13 oder über unser Kontaktformular.

Quellen: PHP-Projekt, Security Advisory zu CVE-2026-109618 und CVE-2026-109619, 21. Oktober 2026 · BSI-IT-Sicherheitshinweis „PHP: Kritische Schwachstellen bedrohen Webanwendungen weltweit“, Version 1.1 vom 21. Oktober 2026 · NCSC-NL, Liste betroffener Produkte · § 30 BSIG · § 32 BSIG