Kritische Sicherheitslücke PHP2Shell: Was Unternehmen jetzt prüfen sollten

Was ist PHP2Shell?

PHP2Shell ist der Name, den Forscher und Medien zwei Lücken im PHP-Interpreter gegeben haben, angelehnt an Log4Shell. Die PHP Group hat sie am 21.10.2026 als CVE-2026-109618 und CVE-2026-109619 veröffentlicht und mit 9,2 von 10 Punkten bewertet (CVSS 4.0). Über präparierte Anfragen an den Webserver kann ein Angreifer im ungünstigen Fall eigenen Code auf dem Server ausführen, ohne Login und bevor die eigentliche Anwendung überhaupt läuft. Der Angriff ist technisch anspruchsvoll, die Folgen wären aber gravierend: Zugriff auf Daten, Passwörter und alles, was der Webserver erreicht.

Nicht verwechseln: wp2shell war im Juli 2026 eine Lücke in WordPress selbst. PHP2Shell betrifft die Programmiersprache darunter.

Bin ich betroffen?

Wenn eure Website, euer Shop, euer Kundenportal oder ein internes Werkzeug auf einer PHP-Version ohne den Fix läuft, besteht Handlungsbedarf. Betroffen sind alle Varianten, mit denen PHP Webanfragen verarbeitet (Apache mit mod_php, PHP-FPM, CGI, FrankenPHP, LiteSpeed). Die wichtigste Frage ist, wer bei euch patcht:

Wie läuft eure Website?	Wer patcht?	Was ihr tun solltet
Shared Hosting oder Managed WordPress (z. B. IONOS, Strato, All-Inkl, Hetzner Webhosting)	der Hoster	Statusseite des Hosters ansehen oder beim Support nachfragen
Website von einer Agentur betreut	je nach Vertrag Agentur oder Hoster	Agentur fragen: „Ist PHP auf unserem Server auf dem Stand vom 21.10.?“
Eigener virtueller oder Root-Server, Docker	ihr bzw. euer Dienstleister	selbst patchen, siehe unten
Software im eigenen Netz (z. B. Nextcloud, Warenwirtschaft mit Weboberfläche)	ihr bzw. euer Dienstleister	selbst patchen, siehe unten

Was große Hoster melden, steht in der Übersicht weiter unten.

Welche Produkte sind betroffen? Eine Übersicht

Die Lücke steckt in PHP, nicht in den Anwendungen. Betroffen ist deshalb alles, was PHP für Webanfragen nutzt, auch Geräte mit einer PHP-Weboberfläche. Was Hersteller und Behörden bisher sagen:

Stand: 22.10.2026, 19:00 Uhr. Wir nennen nur, was Hersteller und staatliche Stellen (BSI, CERT-EU, NCSC-NL) selbst veröffentlicht haben, verlinkt auf die jeweilige Quelle. Die Lage ändert sich laufend. Die Übersicht ist eine Hilfestellung, sie ist nicht vollständig, und wir können Richtigkeit und Aktualität nicht garantieren. Sie ersetzt nicht die Prüfung eurer konkreten Installation. Maßgeblich ist immer die aktuelle Sicherheitsmeldung eures Herstellers.

Laut Hersteller betroffen

Diese Produkte bringen PHP selbst mit, das Update muss vom Hersteller kommen.

• Firewalls: Palo Alto PAN-OS 10.2–12.2 und Panorama: Verwaltungsoberfläche betroffen, noch kein Update (Termin offen). Der Hersteller rät, die Verwaltung nur aus dem internen Netz erreichbar zu machen. pfSense und OPNsense: Updates verfügbar.
• Laut BSI: Das BSI nennt außerdem F5 und Citrix NetScaler als „mindestens teilweise betroffen“.
• NAS: QNAP (QTS, QuTS hero u. a.): betroffen, Update angekündigt. Synology: PHP-Pakete, Calendar und Mail Station betroffen, Updates verfügbar (PHP 7.3 bekommt keins mehr). Das in DSM eingebaute PHP stuft Synology als sehr geringes Risiko ein.
• Hosting-Oberflächen: cPanel hat Updates veröffentlicht.
• Server-Software: Univention UCS 4.4/5.0 (Update nur mit erweitertem Support), ownCloud Classic: Die Docker-Images 11.0.1 und 10.16.6 enthalten das gepatchte PHP, alle anderen Installationen aktualisieren PHP selbst. ownCloud oCIS ist nicht betroffen.
• Linux-Distributionen: Debian, Ubuntu, Red Hat und SUSE: Updates verfügbar bzw. teils noch in Arbeit.

Läuft auf PHP: betroffen, solange PHP darunter nicht gepatcht ist

Die Anwendung selbst hat keinen Fehler, aber sie läuft auf PHP. Ist das PHP auf eurem Server nicht aktualisiert, ist sie angreifbar. Ein Update der Anwendung hilft nicht, PHP muss aktualisiert werden.

• Mit eigener Stellungnahme des Herstellers: JTL-Shop 5 (bei JTL gehostete Shops sind laut JTL bereits aktualisiert), WordPress, WooCommerce, TYPO3, Drupal, PrestaShop, Matomo, GLPI, Kimai.
• Ohne eigene Stellungnahme, laufen aber auf PHP (laut Systemanforderungen): Joomla, Contao, Shopware 6, Magento/Adobe Commerce, Nextcloud (für Nextcloud AIO gibt es gepatchte Images), phpMyAdmin, Roundcube.

Laut Hersteller nicht betroffen

• Sophos: keine Produkte betroffen. Ein älteres Lizenzportal von Sophos lief auf betroffenem PHP, die Prüfung dazu läuft.
• Fortinet: FortiOS/FortiGate, FortiProxy, FortiWeb, FortiMail, FortiManager, FortiAnalyzer, FortiADC, FortiSIEM, FortiClient (Windows, macOS, Linux, iOS, Android, EMS) und weitere nicht betroffen. Noch in Prüfung: FortiDDoS, FortiSOAR und FortiClient Cloud Services.
• LANCOM (Rohde & Schwarz Networks & Cybersecurity): Hard- und Softwareprodukte nicht betroffen.
• Palo Alto: Prisma Access, Cloud NGFW und GlobalProtect nicht betroffen.
• WatchGuard: nach erster Bewertung nicht betroffen, Prüfung läuft.
• Barracuda: einige Produkte nicht betroffen, andere (u. a. CloudGen Firewall) noch in Prüfung.
• Cisco: bisher kein Produkt als betroffen bekannt, mehrere noch in Prüfung.

Gehostete Dienste: laut Anbieter gepatcht

Webhosting und Cloud-Dienste haben die Lücke selbst geschlossen, wenn der Anbieter das meldet: IONOS, Hetzner Webhosting und Managed Server, Mittwald, Hostinger, domainfactory, WordPress.com, Azure App Service (Kanäle Latest und Standard), GLPI Network Cloud und Kimai Cloud. Eigene virtuelle oder Root-Server bei diesen Anbietern patcht ihr selbst.

Noch keine Aussage gefunden

AVM (FRITZ!Box), Zyxel, Securepoint, SonicWall, Ubiquiti, Strato, All-Inkl und DATEV. Dass wir keine Meldung gefunden haben, heißt nicht, dass ein Produkt betroffen ist, und auch nicht, dass es sicher ist. Seht auf der Sicherheitsseite des Herstellers nach.

Wie prüfe ich, ob PHP aktualisiert ist?

• Im Hosting-Kundenbereich steht meist die PHP-Version. Ab 8.2.35, 8.3.36, 8.4.27 bzw. 8.5.12 ist der Fix drin.
• Achtung bei Linux-Distributionen und vielen Hostern: Sie spielen den Fix oft ein, ohne die Versionsnummer zu ändern (Backport). Dann zählt die Sicherheitsmeldung des Anbieters bzw. das Änderungsprotokoll des installierten Pakets: Dort müssen beide CVEs stehen, CVE-2026-109618 und CVE-2026-109619. Das Paketdatum allein reicht nicht.
• Auf dem eigenen Server: Paket aktualisieren und danach alle PHP-Prozesse neu starten (PHP-FPM, Apache), sonst läuft der alte Code weiter. Bei Docker das aktualisierte Basis-Image ziehen, neu bauen und die laufenden Container ersetzen. Achtung: Offizielle Images ziehen manchmal erst Tage später nach. Dann bleibt nur, selbst zu bauen, oder die Übergangsmaßnahmen, bis das Image da ist. Danach prüfen, welche PHP-Version der Webserver tatsächlich verwendet (z. B. über eine phpinfo-Seite, die ihr anschließend wieder löscht). Bei Distributionspaketen mit Backport zählt das Änderungsprotokoll, nicht die Versionsnummer.
• PHP 7.x oder 8.1: Offiziell gibt es dafür keine Updates mehr. Einige Distributionen und Paketquellen liefern Backports, die eigentliche Lösung ist aber das Upgrade auf eine unterstützte Version. Auch 8.2 läuft Ende 2026 aus.

Und wenn ich nicht sofort aktualisieren kann?

Die PHP-Entwickler und das BSI nennen Übergangsmaßnahmen, die bekannte Angriffswege verengen, aber nicht ersetzen, was das Update leistet. Die PHP-Entwickler schreiben selbst: Es gibt keine vollständige Abhilfe, nur das Update ist sicher. Dazu gehört, die Funktion für den Upload-Fortschritt in der PHP-Konfiguration abzuschalten (session.upload_progress.enabled = 0, in der php.ini bzw. der Pool-Konfiguration, nicht per .htaccess) und die Größe von Anfragen am Webserver zu begrenzen. Bei Systemen, die wirklich wichtig sind und die sich nicht patchen lassen, rät das BSI, sie vorübergehend vom Internet zu trennen.

Wird die Lücke schon ausgenutzt?

Die Lage ist unübersichtlich. Amazon hat erste Angriffsversuche schon am 17.10. beobachtet, also vor der Veröffentlichung, und seit dem 21.10. viele weitere. Das BSI hatte am 21.10. noch keine bestätigten Angriffe, erwartet aber eine breite Ausnutzung. Sicherheitsforscher von Sansec weisen darauf hin, dass die öffentlich kursierenden Angriffswerkzeuge gegen eine Standardinstallation bisher nicht funktionieren. Erfolgreiche Einbrüche hat noch niemand bestätigt. Unser Rat: nicht in Panik verfallen, aber auch nicht abwarten. Patchen kostet wenig, aufräumen nach einem Einbruch viel.

Warum KI bei solchen Lücken eine Rolle spielt

Der fehlerhafte Code steckte seit über zehn Jahren in PHP. Gefunden haben ihn mehrere Teams unabhängig voneinander, darunter Calif, OpenAI und Wiz. Calif schreibt, dafür hätten allgemein verfügbare KI-Modelle gereicht. Wiz ergänzt, aktuelle KI-Modelle hätten die Hürde deutlich gesenkt, aus einem alten Fehler einen funktionierenden Angriff zu machen.

Das ist kein Einzelfall. Google, Anthropic und der DARPA-Wettbewerb AIxCC berichten von Lücken, die KI-Systeme in seit Jahren genutzter Software gefunden haben. Auch Angreifer nutzen KI: Google hat im Mai 2026 erstmals einen Angriffscode dokumentiert, der nach eigener Einschätzung mit KI entwickelt wurde. Das BSI rechnet damit, dass Angreifer Sicherheitsupdates mit KI-Werkzeugen schnell auswerten, und hielt bei PHP2Shell eine großflächige Ausnutzung innerhalb weniger Stunden für wahrscheinlich. Eingetreten ist das nach BSI-Stand vom 22.10. bisher nicht, es gab Angriffsversuche, aber keine Ausnutzung in der Breite.

Zur Einordnung: Die meisten erfolgreichen Angriffe gehen laut Mandiant (M-Trends 2026) weiterhin auf bekannte Versäumnisse zurück, etwa fehlende Updates. Google schreibt, Angreifer hätten mit KI noch keinen Durchbruch erzielt. Die frühen Angriffsversuche vor dem 21.10. lassen sich bisher nicht auf KI zurückführen.

Unsere Einschätzung: KI hilft beiden Seiten. Für Betriebe heißt das: Die Zeit zwischen Update und Angriff wird eher kürzer als länger. Updates für Website, Shop und Server sollten deshalb nicht mehr wochenlang liegen bleiben.

Gepatcht, und jetzt? Warnsignale, die ihr prüfen solltet

Ein Update schließt die Tür, wirft aber niemanden hinaus, der schon drin ist. Wer einen eigenen Server betreibt, sollte deshalb für die Zeit ab dem 17.10. auf diese Warnsignale achten:

• auffällig viele POST-Anfragen mit Datei-Upload (der Hinweis PHP_SESSION_UPLOAD_PROGRESS ist nur sichtbar, wenn Anfrageinhalte protokolliert werden, was normale Zugriffslogs meist nicht tun),
• Webserver-Prozesse, die Programme starten oder Dateien nachladen,
• neue oder geänderte PHP-Dateien im Webverzeichnis, die niemand angelegt hat,
• neue Administratorkonten in WordPress oder im Shop.

Jedes davon kann auch harmlose Gründe haben, muss aber geklärt werden. Umgekehrt beweisen fehlende Spuren nicht, dass nichts passiert ist.

Findet ihr etwas, nicht einfach löschen. Den Server vom Netz nehmen, aber nicht ausschalten, ein Abbild und die Logs sichern, erst dann sauber neu aufsetzen und Zugangsdaten von einem sauberen Gerät aus ändern. Sind personenbezogene Daten betroffen, muss der Vorfall in der Regel unverzüglich, möglichst binnen 72 Stunden ab Kenntnis, an die Datenschutzaufsicht gemeldet werden, es sei denn, es besteht voraussichtlich kein Risiko für die Betroffenen. Bei hohem Risiko sind auch die Betroffenen zu informieren. Diese Prüfung beginnt sofort, nicht erst nach Abschluss der Ursachensuche.

Nach PHP2Shell: Patchmanagement als Routine

Die nächste Lücke kommt sicher, nur nicht wann. Wer dann ruhig bleiben will, braucht keine große Sicherheitsabteilung, aber eine feste Routine. Das BSI beschreibt sie im IT-Grundschutz-Baustein „Patch- und Änderungsmanagement“ (OPS.1.1.3). Für ein kleines Unternehmen heißt das im Kern:

1. Wissen, was läuft. Eine Liste aller Systeme und Programme mit Version, die am Internet hängen oder wichtige Daten verarbeiten, inklusive Website, Shop, Router, Firewall, NAS.
2. Zuständigkeit klären. Für jedes System steht fest, wer Updates einspielt: ihr selbst, der Hoster oder ein Dienstleister. Was niemandem gehört, wird nicht gepatcht.
3. Informiert werden. Sicherheitsmeldungen der Hersteller abonnieren oder ein Werkzeug nutzen, das eure Software automatisch mit neuen Schwachstellen abgleicht.
4. Feste Fristen. Kritische Lücken in Systemen, die am Internet hängen, innerhalb von Stunden bis wenigen Tagen, nicht beim nächsten Wartungstermin in drei Monaten. Normale Updates in einem festen Rhythmus.
5. Prüfen, ob es geklappt hat. Nach dem Update kontrollieren, dass die neue Version wirklich läuft.
6. Protokolle einschalten, bevor man sie braucht. Zugriffe auf Website und Server aufzeichnen und einige Wochen aufbewahren. Nur so lässt sich nach einer Lücke wie dieser später sagen, ob jemand eingedrungen ist.

Mit Dienstleistern: Wer Website, Server oder Netzwerk betreuen lässt, sollte im Wartungsvertrag festhalten, dass Sicherheitsupdates enthalten sind, in welcher Frist kritische Lücken geschlossen werden und wie ihr darüber informiert werdet. Ein Vertrag, der nur „Pflege nach Aufwand“ sagt, regelt das nicht.

Überwachung: Ein Monitoring, das Versionen, Erreichbarkeit und auffällige Änderungen im Blick behält, meldet Probleme, bevor Kunden sie bemerken. Das kann der Dienstleister übernehmen oder ihr lasst es einrichten.

Was wir daraus mitnehmen

Auch wir betreiben Systeme auf PHP, für uns und für unsere Kunden. Wir haben sie innerhalb kürzester Zeit erst gehärtet und dann gepatcht:

1. Meldung: Wir lassen uns automatisch benachrichtigen, sobald zu Software, die wir einsetzen, eine Lücke (CVE) gemeldet wird.
2. Erst sichern, dann härten: Vor jeder Änderung haben wir die Daten gesichert und dann die Übergangsmaßnahmen aus der PHP-Sicherheitsmeldung gesetzt, auf Serverebene, wie dort empfohlen.
3. Dann patchen: Das Update haben wir vor dem Umstieg auf einer Kopie getestet und danach eingespielt.
4. Nachsehen, nicht nur schließen: Nach dem Patch haben wir für die Zeit ab dem 17.10. Dateien, Datenbank, Benutzerkonten und Server auf Spuren eines Eindringens geprüft. Hinweise haben wir keine gefunden. Ganz ausschließen lässt sich so etwas nie, denn prüfen kann man nur, was vorher aufgezeichnet wurde.

Das klappt nur, wenn man vorher weiß, welche Software wo läuft und wer sie aktualisiert. Bei Log4Shell 2021 haben wir das als Softwarehersteller gelernt, bei PHP2Shell hat es sich wieder gezeigt: Schnell durch waren die, die diese Frage schon vorher beantworten konnten. Verhindern kann man solche Lücken nicht, aber man kann sich so aufstellen, dass man geordnet und schnell reagiert.

Drei Fragen, die jeder Betrieb nach dieser Woche beantworten können sollte:

1. Welche unserer Systeme hängen am Internet, und auf welcher Software laufen sie?
2. Wer spielt Sicherheitsupdates ein, und woran merken wir, dass es passiert ist?
3. Wen rufen wir an, wenn doch etwas passiert?

Wenn ihr darauf noch keine Antwort habt: Genau dabei helfen wir, vom Sicherheitskonzept bis zum Notfallablauf, und auf Wunsch mit einem Penetrationstest, der zeigt, wo ihr heute steht. → IT-Sicherheit bei materium software