Am 21. Oktober um 16 Uhr deutscher Zeit hat das PHP-Projekt Patches für zwei kritische Schwachstellen veröffentlicht. Am selben Abend war das Internet voll mit Artikeln, deren Überschrift im Wesentlichen aus „JETZT PATCHEN!" bestand.
Das ist jetzt gut drei Wochen her. Die Aufregung hat sich gelegt, die Überschriften sind weitergezogen. Die verwundbaren Server leider nicht alle.
Deshalb hier kein weiterer Alarmartikel, sondern eine freundliche Nachfrage: Na, schon gepatcht? Und wenn nicht – woran hängt es eigentlich?
Was passiert ist, in kurz
Die Lücken laufen unter CVE-2026-109618 und CVE-2026-109619, in der Berichterstattung hat sich der Spitzname PHP2Shell durchgesetzt – eine nicht ganz zufällige Anspielung auf Log4Shell. Beide sind mit 9,2 von 10 nach CVSS 4.0 bewertet. Übersetzt: Angreifer können auf Webservern mit PHP-Anwendungen Code ausführen, ohne sich anzumelden und ohne dass irgendjemand irgendwo klicken muss.
Betroffen sind alle bekannten PHP-Versionen bis mindestens PHP 5 zurück, und zwar überall dort, wo PHP Web-Anfragen verarbeitet: PHP-FPM, Apache mit mod_php, php-cgi, FrankenPHP, LiteSpeed. Das PHP-Security-Team sieht bei mod_php das höchste Risiko, weil ein Angriff dort schon greifen kann, bevor überhaupt eine Zeile Anwendungscode läuft. Gefunden wurden die Lücken unter Beteiligung von Wiz.io und Calif.io, gemeinsam mit OpenAI.
Das BSI hat dazu einen Sicherheitshinweis mit Kritikalität 3, also Orange, herausgegeben und inzwischen zweimal aktualisiert. Die gute Nachricht aus dem letzten Update: Erfolgreiche Kompromittierungen in regulierten Branchen oder der Bundesverwaltung sind dem BSI bisher nicht bekannt. Die weniger gute: Automatisierte Angriffsversuche wurden beobachtet, und laut Suchmaschinen ist die Zahl verwundbarer Systeme weltweit weiterhin sehr hoch.
Die Fakten zur Lücke stammen aus dem Sicherheitshinweis des BSI (Version 1.2 vom 22.10.2026). Stand dieses Artikels: 13.11.2026.
Der Selbsttest in zwei Minuten
Die Versionen mit Fix sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Alles darunter im jeweiligen Zweig ist verwundbar, sofern niemand nachgebessert hat.
Der erste Blick geht auf den Server:
php -v
Das ist allerdings nur die halbe Wahrheit, denn php -v zeigt die Kommandozeilen-Version. Der Webserver benutzt nicht zwingend dasselbe Binary. Auf Debian und Ubuntu lohnt deshalb auch der Blick auf FPM und die installierten Pakete:
php-fpm8.3 -v # Versionsnummer an die eigene Installation anpassen
dpkg -l | grep php # Debian / Ubuntu
rpm -qa | grep php # Red Hat & Co.
Und hier kommt der Haken, über den viele stolpern: Distributionen patchen gern, ohne die Versionsnummer zu ändern. Ein Debian- oder Ubuntu-Paket kann also eine „alte" Versionsnummer tragen und trotzdem den Fix enthalten, weil er zurückportiert wurde. Die PHP-Versionsnummer allein reicht deshalb nicht. Maßgeblich ist das Sicherheits-Advisory der eigenen Distribution – bei Ubuntu, Debian und Red Hat steht dort, welche Paketversion den Fix enthält.
Docker ist ein eigenes Kapitel. Das PHP im Container ist das PHP aus dem Base-Image, und zwar in dem Zustand, in dem es beim letzten Build war. Ein neues Deployment der Anwendung ändert daran nichts. Das Image muss neu gebaut werden, mit frisch gezogenem Base-Image:
docker build --pull -t meine-app .
docker exec <container> php -v # danach im laufenden Container prüfen
Wer im Dockerfile eine exakte Patch-Version festgenagelt hat, muss sie natürlich auch hochziehen. --pull holt nur, was der Tag hergibt.
Und dann gibt es noch die Geräte, an die bei „PHP" niemand denkt. Laut BSI sind auch Produkte von F5, Citrix NetScaler, Palo Alto, OPNsense, Netgate pfSense, QNAP, Synology und cPanel zumindest teilweise betroffen, weil deren Weboberflächen auf PHP laufen. Die Firewall im Serverschrank und das NAS im Büro gehören also mit auf die Liste. Dort hilft kein apt upgrade, sondern nur das Firmware-Update des Herstellers.
„Warum ist es noch nicht gepatcht?"
Jetzt der unterhaltsame Teil. In zwanzig Jahren Webentwicklung habe ich jede dieser Begründungen schon gehört.
„Läuft doch."
Stimmt. Ein verwundbarer Server läuft genauso gut wie ein gepatchter. Er merkt es nicht, du merkst es nicht. Das ist ja gerade das Problem. „Läuft" ist der Normalzustand eines Servers, kein Sicherheitsnachweis.
„Das macht der Hoster."
Kann sein. Bei klassischem Shared Hosting oder echtem Managed Hosting kümmert sich der Anbieter in der Regel um die PHP-Laufzeit. Zwei Fragen lohnen trotzdem: Ist das wirklich Managed Hosting oder ein VPS, bei dem der Hoster nur den Strom bezahlt? Und hast du im Kundenmenü vielleicht irgendwann eine ältere PHP-Version ausgewählt, weil das Plugin von 2017 sonst nicht lief? Dann patcht der Hoster möglicherweise alles, nur nicht das, was du benutzt.
„Der Container ist doch aktuell."
Der Code im Container ist aktuell. Das PHP darunter ist so alt wie das Base-Image beim letzten Build. Das BSI schreibt es ziemlich deutlich: Die Anwendung zu aktualisieren reicht nicht, die PHP-Laufzeit selbst muss gepatcht werden. Wenn das letzte docker build vor dem 21. Oktober war, ist der Container nicht aktuell, sondern nur frisch deployt.
„Wir haben doch eine WAF."
Gut so. Cloudflare, Bunny Shield und andere haben Regeln veröffentlicht, und die halten einiges ab. Volle Sicherheit gibt es laut BSI aber nur durch Patchen oder Abschalten. Dasselbe gilt für die kursierenden Konfigurations-Workarounds: Sie verkleinern die Angriffsfläche, mehr nicht. Eine WAF ist ein Sicherheitsgurt, kein Grund, die Bremsen nicht zu reparieren.
„Wir sind auf PHP 7.2, da gibt's keinen Patch."
Das ist die ehrlichste Ausrede auf der Liste, denn sie stimmt. Das PHP-Security-Team hat Backport-Patches für die schon nicht mehr unterstützten Versionen 7.4, 8.0 und 8.1 bereitgestellt. Für alles davor gibt es keinen offiziellen Fix. Manche Linux-Distributionen und LTS-Anbieter liefern für ältere Versionen nach – ob das für die eigene Umgebung gilt, muss man konkret prüfen. Darauf verlassen sollte man sich nicht.
„An das Laravel-Update traut sich keiner."
Mein persönlicher Favorit, weil ich ihn so gut verstehe. Die Anwendung ist acht Jahre alt, der Entwickler von damals ist weg, Tests gibt es eher symbolisch. Und eine alte Framework-Version läuft eben nur auf einer alten PHP-Version. Also bleibt alles, wie es ist, und jeder hofft, dass es nicht ausgerechnet in seiner Schicht auffällt.
Das ist keine Faulheit. Das ist ein völlig rationales Verhalten, wenn ein Update sich anfühlt wie Jenga im Dunkeln. Es ändert nur nichts an der Lücke.
Der eigentliche Punkt
Wer genau hinschaut, merkt: Die meisten Ausreden haben mit dem Patch selbst wenig zu tun. Ein PHP-Update auf eine neue Patch-Version ist, wenn die Infrastruktur sauber ist, eine Sache von Minuten. Manche Betreiber haben am Patch-Tag sogar vorsorglich Server vom Netz genommen, bis das erledigt war.
Das eigentliche Problem liegt eine Ebene tiefer. Ein Patch hilft nur, wenn die eigene Version überhaupt noch Patches bekommt. Und das BSI benennt ziemlich klar, wo die vielen verwundbaren Systeme herkommen: Entweder sie wurden nicht gepatcht, oder sie laufen auf Versionen, die längst aus dem Support sind und keine Updates mehr bekommen.
Wer auf einer Version sitzt, für die es einen Fix gibt, hat ein Ticket mit zehn Minuten Aufwand. Wer auf 7.2 festhängt, hat ein Projekt. Und dieses Projekt wird mit jedem Monat nicht kleiner, sondern größer.
Genau da lohnt es sich, das Thema einmal richtig anzugehen statt von Lücke zu Lücke zu zittern: alte Anwendung auf eine unterstützte PHP-Version heben, das Framework schrittweise nachziehen, Tests dort einziehen, wo es knirscht. Das ist keine Raketenwissenschaft, aber es braucht jemanden, der sich traut und weiß, wo die typischen Fallen liegen. Wenn das bei dir gerade der Engpass ist: Genau dafür gibt es meine Laravel- und PHP-Entwicklung – inklusive Versions-Upgrades für Anwendungen, die schon ein paar Jahre auf dem Buckel haben.
Die nächste kommt bestimmt
Bemerkenswert an PHP2Shell finde ich weniger die Lücken selbst als die Art, wie sie gefunden wurden: von Sicherheitsfirmen gemeinsam mit OpenAI. Das BSI schreibt in seinem Update ausdrücklich, dass durch die erhöhte Aufmerksamkeit für PHP und die KI-gestützte Schwachstellensuche weitere Lücken gefunden werden könnten.
Das heißt nicht, dass jetzt jede Woche die Welt untergeht. Es heißt, dass „wir patchen, wenn mal was ist" als Strategie schlechter altert als früher. Die Frage ist nicht mehr, ob die nächste kritische Lücke kommt, sondern ob du sie dann in einer Stunde schließen kannst oder erst eine Migration planen musst.
Also: php -v eintippen, mit der Liste oben vergleichen, das Advisory der Distribution checken, Container neu bauen, an die Firewall denken. Wenn danach alles grün ist – sehr gut, Kaffee holen. Wenn nicht, und du nicht weißt, wo du anfangen sollst: schreib mir. Ohne Alarm, versprochen.
Ein Patch ist schnell eingespielt. Teuer wird es erst, wenn es für die eigene Version keinen mehr gibt.