PHP2Shell: Kritische PHP-Sicherheitslücken – was Unternehmen jetzt tun müssen

Am 21. Oktober 2026 hat das Bundesamt für Sicherheit in der Informationstechnik (BSI) eine Cybersicherheitswarnung veröffentlicht, die in dieser Dringlichkeit selten ist: Zwei kritische Schwachstellen in der Programmiersprache PHP, vom BSI mit der Warnstufe „3 / Orange" eingestuft (öffnet in neuem Tab), bedrohen nach eigener Einschätzung der Behörde Webanwendungen weltweit. Die Schwachstellen sind inzwischen unter dem Namen „PHP2Shell" bekannt. Wer eine eigene Website, einen Onlineshop oder eine Weblösung betreibt – ob selbst gehostet oder bei einem Dienstleister – sollte diese Meldung nicht überlesen, denn PHP steckt oft tiefer im eigenen Betrieb, als vielen bewusst ist.

Was hinter PHP2Shell steckt

Die beiden Schwachstellen tragen die Kennungen CVE-2026-109618 und CVE-2026-109619 und erreichen laut BSI-Warnung (öffnet in neuem Tab) jeweils einen CVSS-v4.0-Basiswert von 9,2 von 10 möglichen Punkten – also eine Einstufung als kritisch. Laut heise online (öffnet in neuem Tab) steckt die erste Lücke in der Speicherverwaltung von PHP: Stößt die Sprache beim Erreichen des konfigurierten Speicherlimits (memory_limit) auf einen durch den Angreifer präparierten Upload oder ein verschachteltes Array, räumt sie die Überreste des fehlgeschlagenen Skripts nicht sauber auf – Angreifer können dadurch Speicher auslesen und eigenen Code im Kontext des Webservers ausführen. Die zweite Lücke liegt im Error-Handling und benötigt laut heise mindestens zwei aufeinanderfolgende HTTP-Anfragen, von denen die erste einen instabilen Zustand erzeugt und die zweite ihn ausnutzt.

Beide Angriffe laufen ohne vorherige Anmeldung – laut heise reichen „mehrere Tausend bis Zehntausend HTTP-Anfragen", bis eine der Schwachstellen zuverlässig greift. Wie schnell das in der Praxis gehen kann, zeigt ein Video der Entdecker vom Sicherheitsunternehmen Calif, das laut heise-Bericht demonstriert, wie sich auf einem Webserver mit dem PHP-Framework Laravel nach 38 Sekunden Systemkommandos ausführen lassen.

Betroffen sind laut BSI-Pressemitteilung (öffnet in neuem Tab) alle bekannten PHP-Versionen, „zurückgehend bis mindestens PHP 5". Das PHP-Projekt selbst bestätigt dies im eigenen Sicherheitshinweis (öffnet in neuem Tab): Betroffen sind alle Installationen, die Web-Anfragen bedienen – darunter PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP und LiteSpeed. Das größte Risiko sieht das PHP-Team bei mod_php, wo ein unauthentifizierter Angriff greift, bevor überhaupt Anwendungscode läuft.

Warum diese Lücke mehr Unternehmen betrifft, als „PHP" vermuten lässt

Wer selbst keine Zeile PHP schreibt, hält sich schnell für nicht betroffen – ein Trugschluss. PHP ist laut w3techs (öffnet in neuem Tab) (Stand 24. Oktober 2026) die serverseitige Sprache von 69,3 Prozent aller Websites, deren serverseitige Programmiersprache bekannt ist. Darunter fallen laut Deutschland sicher im Netz (öffnet in neuem Tab) unter anderem Content-Management-Systeme wie WordPress, Joomla oder Drupal sowie Shopsysteme wie Magento oder Shopware – Systeme, auf denen auch zahlreiche mittelständische Unternehmen ihre Website, ihren Onlineshop oder ihr Kundenportal betreiben. DSIN weist ausdrücklich darauf hin, dass die Schwachstellen in PHP selbst liegen und nicht in den genannten Anwendungen – ein Update allein des CMS oder Shopsystems reicht deshalb möglicherweise nicht aus.

Die Angriffsfläche reicht laut heise-Recherche noch weiter: Auch zahlreiche vernetzte Geräte nutzen PHP für ihre webbasierte Verwaltungsoberfläche, darunter Firewalls und Router wie pfSense, OPNsense sowie Geräte von DrayTek, ZyXEL, D-Link, TP-Link, Netgear, Tenda und Synology, dazu NAS-Systeme von QNAP sowie Security-Appliances von Citrix, Palo Alto und Ivanti und BIG-IP-Loadbalancer von F5. Wer eines dieser Produkte mit nach außen offener Verwaltungsoberfläche betreibt, sollte es laut heise als Teil der eigenen Angriffsfläche begreifen, nicht als Teil der Verteidigung.

Auch rein intern genutzte PHP-Anwendungen sind keine sichere Zone: Ein Angreifer, der bereits über einen anderen Weg – etwa Windows-Malware – ins Firmennetz gelangt ist, kann eine veraltete interne PHP-Installation nutzen, um sich dauerhaft einzunisten, warnt heise.

Auch Docker-Container sind betroffen, wenn das darin enthaltene Basis-Image eine verwundbare PHP-Version mitbringt. Laut heise-Bericht reicht es in diesem Fall nicht, nur den eigenen Anwendungscode zu aktualisieren – das Container-Image selbst muss neu gezogen werden, etwa mit dem Befehl docker compose pull && docker compose up -d. Wer PHP-Anwendungen containerisiert betreibt, sollte das Basis-Image also ausdrücklich in die eigene Prüfung einbeziehen, nicht nur den Quellcode im Repository.

Wie ernst die Lage eingestuft wird

Die Dringlichkeit, mit der das BSI reagiert hat, ist ungewöhnlich hoch. BSI-Vizepräsident Thomas Caspers wird in der Pressemitteilung der Behörde (öffnet in neuem Tab) mit den Worten zitiert: „Wir halten eine kurzfristige, großflächige Ausnutzung innerhalb weniger Stunden nach Erscheinen der Sicherheitsupdates für wahrscheinlich: Angreifer können diese mittels KI-gestützter Werkzeuge innerhalb kurzer Zeit analysieren und entsprechende Exploits generieren. Es besteht also unverzüglicher Handlungsbedarf!" Die Veröffentlichung der Patches war laut heise ursprünglich für den 22. Oktober geplant und wurde wegen eines Lecks vorgezogen – was dem PHP-Team weniger Vorlaufzeit für eine koordinierte Kommunikation ließ.

Wie ernst andere Betreiber die Lage genommen haben, zeigt die Reaktion in Berlin und Brandenburg: Laut rbb24 (öffnet in neuem Tab) schalteten unter anderem die Charité, die Freie Universität Berlin, die Universität Potsdam sowie mehrere Bundesbehörden vorsorglich Teile ihrer Webauftritte ab, bis die Updates eingespielt waren – nicht wegen eines bereits erfolgten Angriffs, sondern als reine Vorsichtsmaßnahme. Bestätigte Ausnutzungen in der Breite waren dem BSI laut eigener Warnung zum Stand 22. Oktober 2026 noch nicht bekannt.

Was jetzt konkret zu tun ist

Die gepatchten Versionen sind laut PHP-Sicherheitsankündigung (öffnet in neuem Tab) 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Einige Einschränkungen dabei:

1. Version prüfen und aktualisieren. Wer PHP 8.2 oder neuer einsetzt, aktualisiert auf die jeweils gepatchte Version. Für PHP 7.4, 8.0 und 8.1 – die regulär keine Updates mehr erhalten – hat das PHP-Team laut eigener Ankündigung ausnahmsweise Backports bereitgestellt, weil die Schwachstellen so schwerwiegend sind.
2. PHP 8.1 und älter als Übergangslösung behandeln, nicht als Dauerzustand. PHP 8.2 selbst erreicht laut PHP-Sicherheitsankündigung (öffnet in neuem Tab) am 31. Dezember 2026 das reguläre Lebensende und erhält danach keine weiteren Sicherheitsfixes vom PHP-Projekt.
3. Bei externem Hosting oder Managed-CMS beim Anbieter nachfragen. DSIN empfiehlt ausdrücklich, bei extern gehosteten Websites und Onlineshops den Hosting-Anbieter zu kontaktieren und den Patchstatus zu verifizieren, statt sich allein auf ein CMS-Update zu verlassen.
4. Server auf Auffälligkeiten prüfen, insbesondere ungewöhnliche Prozesse, unbekannte Dateien oder unerwartete Änderungen an der Website – ein Hinweis, den sowohl BSI als auch DSIN geben.
5. Netzwerkgeräte mit PHP-basierter Verwaltungsoberfläche nicht vergessen. Firewalls, NAS-Systeme und Router aus der oben genannten heise-Liste gehören in dieselbe Prüfung wie der eigentliche Webserver.
6. Funktionierende, getestete Backups sicherstellen. Eine Datensicherung, deren Wiederherstellbarkeit nie geprüft wurde, hilft im Ernstfall nicht – auch das zählt DSIN zu den Sofortmaßnahmen.

Das PHP-Team selbst benennt eine Reihe von Konfigurationsänderungen, die das Risiko bei Verzögerungen etwas mindern – etwa memory_limit=-1, ein reduziertes post_max_size oder das Deaktivieren von session.upload_progress. Es stellt aber klar, dass diese Einstellungen laut eigener Formulierung „als nichts Anderes als eine temporäre Krücke" zu betrachten sind und ein echtes Update nicht ersetzen.

Was danach bleibt

PHP-Release-Manager Volker Dusch sagte gegenüber heise security nach der Veröffentlichung: „Nach vielen Wochen Arbeit bin ich sehr froh, dass wir den Release geschafft haben." Der Fall zeigt, mit welcher Geschwindigkeit sich eine Schwachstelle im Fundament des halben Internets heute von der Ankündigung zum potenziellen Massenangriff entwickeln kann – und wie wenig es dabei hilft, sich für „nicht betroffen" zu halten, nur weil man selbst kein PHP programmiert. Wer eine Website, einen Onlineshop oder ein Kundenportal betreibt, trägt die Verantwortung für den Patchstatus seiner gesamten technischen Lieferkette – auch wenn ein Dienstleister die eigentliche Umsetzung übernimmt. Eine Bestandsaufnahme, welche Systeme im eigenen Betrieb PHP nutzen und wer für deren Patchstand zuständig ist, ist unabhängig vom aktuellen Fall eine Übung, die sich lohnt, bevor die nächste Schwachstelle dieser Größenordnung bekannt wird.