PHP2Shell: kritische PHP-Lücke – was Betriebe jetzt tun

PHP2Shell betrifft PHP auf Webservern weltweit. Was die Lücke ist, wie weit sie verbreitet ist und wie Sie in drei Schritten prüfen, ob Ihre Website sicher ist.

Michael Schott · 22. Oktober 2026 · 12 Min. Lesezeit

Ein leuchtender, aus PHP-Code-Zeichen gebauter Glas-Elefant mit rotem Riss, von dem rote Lichtfäden zu Servern ausstrahlen. — Symbolbild, KI-generiert.

Am Dienstagabend (20.10.2026) sind Details zu zwei schweren Sicherheitslücken in PHP an die Öffentlichkeit gelangt, früher als geplant. Am Mittwoch hat das PHP-Projekt Updates veröffentlicht. Noch am selben Tag hat die Stadt Mainz Webseiten vorsorglich vom Netz genommen, weitere öffentliche Angebote waren zeitweise nicht erreichbar. Die Lücken tragen den Namen PHP2Shell.

PHP ist die Programmiersprache, auf der ein Großteil aller Websites läuft, darunter WordPress, Shopware, Joomla und viele Kundenportale. Betroffen ist nicht ein einzelnes Plugin, sondern PHP selbst. Was passiert ist, wie weit das Problem reicht und was Sie als Betrieb heute prüfen sollten:

Das Wichtigste in Kürze

PHP2Shell (CVE-2026-109618 und CVE-2026-109619) steckt im Kern von PHP. Ein Angreifer kann damit ohne Anmeldung Code auf dem Server ausführen. Ein Update von WordPress oder Plugins hilft nicht.

Abgesichert sind PHP 8.5.12, 8.4.27, 8.3.36 und 8.2.35 vom 21.10.2026 oder entsprechend gepatchte Pakete Ihrer Linux-Distribution. Für PHP 8.1 und älter gibt es kein offizielles Update.

Fragen Sie heute Ihren Hoster oder Ihre Agentur, welche PHP-Version läuft und ob sie gepatcht ist. Läuft 8.1 oder älter, stellen Sie um oder nehmen Sie die Seite bis dahin vom Netz.

Was ist PHP2Shell?

PHP2Shell ist der Name für zwei kritische Lücken im PHP-Kern, die das PHP-Projekt am 21.10.2026 in seinem Sicherheitshinweis beschrieben und geschlossen hat. Beide erlauben es einem Angreifer, über das Internet eigenen Programmcode auf dem Webserver auszuführen (Remote Code Execution). Eine Anmeldung braucht er dafür nicht. Beide Lücken sind mit einem CVSS-4.0-Wert von 9,2 als kritisch eingestuft.

Die erste Lücke, CVE-2026-109618, entsteht, wenn PHP beim Verarbeiten einer Anfrage der Speicher ausgeht. Dann können halb angelegte Daten zurückbleiben, die PHP später als gültig behandelt. Ausgelöst werden kann das mit Formular-Uploads innerhalb der normalen Grenzen. Bei der zweiten Lücke, CVE-2026-109619, bleiben Daten einer Anfrage im Speicher stehen, obwohl er schon freigegeben ist. Eine spätere Anfrage an denselben Prozess greift dann darauf zu.

Für Sie als Betreiber zählt vor allem eines: Der Fehler liegt unterhalb Ihrer Anwendung. Laut PHP-Projekt ist jede Installation betroffen, die Webanfragen verarbeitet, egal ob über PHP-FPM, Apache mod_php, php-cgi, FrankenPHP oder LiteSpeed. Am größten ist das Risiko laut PHP-Projekt bei mod_php: Dort funktioniert der Angriff schon mit den Standardeinstellungen und greift, bevor Ihre Website überhaupt eine Zeile eigenen Code ausführt.

Warum ein CMS-Update nicht reicht

Viele Betriebe halten WordPress und Plugins aktuell und fühlen sich damit sicher. Bei PHP2Shell genügt das nicht. Der Sicherheitsdienstleister Tenable fasst in seinen Fragen und Antworten zu PHP2Shell (21.10.2026) zusammen, dass die Entdecker Angriffe ohne Anmeldung gegen bestimmte Versionen von WordPress, Drupal, Joomla und Magento bestätigt haben. Der Shop-Sicherheitsdienst Sansec nennt zusätzlich Shopware, WooCommerce, Nextcloud, phpMyAdmin, Roundcube, Laravel und Symfony.

Auch Geräte können betroffen sein. Router, Firewalls und NAS-Speicher haben oft eine Verwaltungsoberfläche, die auf PHP läuft. heise nennt in seiner Analyse vom 21.10.2026 unter anderem Synology, QNAP, pfSense, OPNsense und DrayTek. Prüfen Sie deshalb auch die Firmware Ihrer Geräte, wenn deren Oberfläche aus dem Internet erreichbar ist.

Wie weit ist das Problem verbreitet?

PHP läuft laut W3Techs auf 69,3 % aller Websites, deren Programmiersprache auf dem Server bekannt ist (Datenstand 21.10.2026, abgerufen am 22.10.2026). Damit ist PHP2Shell kein Nischenthema. Nach Angaben der Entdecker reicht der Fehler bis zu PHP 5.4 zurück. Laut BSI sind alle Versionen mindestens bis zurück zu PHP 5 betroffen.

Wie viele Server erreichbar sind, haben Sicherheitsfirmen aus Internet-Scans geschätzt. Die Bedrohungsanalysten von Mallory zählten am 20.10.2026 per Shodan rund 2,24 Millionen Server im Internet, die PHP in ihren Kopfzeilen angeben. Rund 1,5 Millionen davon zeigen ihre Version an. Bei rund 884.000 dieser Server, also 59 %, läuft eine PHP-Version ohne Sicherheitsunterstützung (End of Life). So berichten es CybelAngel und Check Point auf Basis derselben Daten. Das sind Zählungen der angezeigten Version, keine bestätigt angreifbaren Systeme. Deutschland liegt in dieser Zählung auf Platz 4 hinter den USA, China und Japan.

Ein leuchtender Globus aus Linien in Cyan, umgeben von Code-Klammern, auf dem sich rote Server-Punkte über Europa und andere Kontinente ausbreiten und mit roten Bögen verbunden sind. — Symbolbild, KI-generiert.

Fast die Hälfte der PHP-Websites hat kein offizielles Update

Das größere Problem sind alte PHP-Versionen. Laut W3Techs, bezogen auf Websites mit erkennbarer PHP-Version, laufen 27,0 % der PHP-Websites noch mit PHP 7 und 7,7 % mit PHP 5. Unter den Seiten mit PHP 8 nutzen 15,2 % die Version 8.1 und 5,8 % die Version 8.0. Für all diese Versionen veröffentlicht das PHP-Projekt kein offizielles Update mehr.

Rechnet man die Anteile von W3Techs zusammen, ergibt sich: Rund 51,5 % der PHP-Websites laufen auf einer Version, für die es ein offizielles Update gibt (8.2 bis 8.5). Rund 48,5 % laufen auf 8.1 oder älter. Diese Websites lassen sich nur durch einen Wechsel der PHP-Version absichern oder über Anbieter, die alte Versionen nachweislich selbst weiterpflegen. Da viele Hoster die Version ausblenden, ist der Anteil alter Versionen in dieser Zählung eher zu hoch als zu niedrig.

Eigene Berechnung aus W3Techs-Daten (Hauptversionen und Unterversionen von PHP 8, Websites mit erkennbarer PHP-Version, Stand 21.10.2026). Werte gerundet; Summen aus ungerundeten Werten, 48,5 % einschließlich PHP 4.

Wird die Lücke schon ausgenutzt?

Es gibt Angriffsversuche, aber nach unserem Stand vom 22.10.2026 keine öffentlich bestätigten Einbrüche. Die US-Behörde CISA schrieb in ihrem Alert vom 21.10.2026, sie habe noch keine Ausnutzung beobachtet. Das BSI spricht von unbestätigten Berichten über Exploits.

Gleichzeitig melden Sicherheitsfirmen erste Versuche. Laut BleepingComputer sah Cloudflare ab 07:43 Uhr UTC am 21.10. erste Angriffsversuche, also Stunden bevor die Updates erschienen. Die Firma watchTowr beobachtete Angriffsversuche in ihren Köder-Systemen.

Ein Angriff ist kein einzelner Klick. Laut heise braucht ein Angreifer einige Tausend bis Zehntausende Anfragen. In einer Vorführung der Entdecker, über die heise berichtet, dauerte es 38 Sekunden bis zum Zugriff auf einen Laravel-Server. Das ist schnell genug, um viele Server automatisiert anzugreifen.

Zeitleiste nach php.net, BleepingComputer, BSI und CISA. Die beiden unteren Termine stammen aus dem Support-Plan des PHP-Projekts.

Erste Reaktionen in Deutschland

Das Bundesamt für Sicherheit in der Informationstechnik (BSI) hat am 21.10.2026 eine Cybersicherheitswarnung herausgegeben. In der Pressemitteilung schreibt BSI-Vizepräsident Thomas Caspers: „Wir halten eine kurzfristige, großflächige Ausnutzung innerhalb weniger Stunden nach Erscheinen der Sicherheitsupdates für wahrscheinlich.“ Er begründet das damit, dass Angreifer die Updates mit KI-gestützten Werkzeugen schnell analysieren und daraus Angriffswerkzeuge (Exploits) erzeugen können.

Mehrere Einrichtungen haben vorsorglich reagiert. Laut ZfK hat die Stadt Mainz mainz.de und mehrere Online-Dienste abgeschaltet. Nach demselben Bericht waren auch die Charité Berlin, das Webangebot der Landesregierung Baden-Württemberg und die Seiten der Universität Mannheim zeitweise nicht erreichbar. Der Hoster Uberspace hat laut heise alle PHP-Dienste vorübergehend abgeschaltet, bis die Updates eingespielt waren.

In drei Schritten prüfen, ob Ihre Website sicher ist

Die einzige vollständige Lösung ist ein PHP-Update. Alles andere überbrückt nur Zeit. Diese drei Schritte gelten für eine einfache Firmenwebsite genauso wie für einen Shop oder ein Kundenportal.

1. PHP-Version herausfinden

Sie finden die Version meist im Kundenbereich Ihres Hosters, oft unter einem Punkt wie „PHP-Einstellungen“. Wer Zugriff auf den Server hat, gibt dort php -v ein. Notieren Sie die genaue Versionsnummer mit allen drei Stellen, zum Beispiel 8.3.36. Bei Paketen einer Linux-Distribution wie Debian oder Ubuntu sagt die Nummer allein nicht, ob gepatcht ist; fragen Sie dann nach dem Paketstand. Betreuen Sie mehrere Websites oder Geräte, listen Sie alle auf.

2. Klären, wer für das Update zuständig ist

Wer handeln muss, hängt davon ab, wie Ihre Website betrieben wird.

Ihre Situation	Wer spielt das Update ein?	Was Sie tun
Webhosting-Paket (Shared Hosting)	In der Regel der Hoster, für PHP 8.2 bis 8.5	Nachfragen, ob gepatcht ist. Bei 8.1 oder älter selbst im Kundenbereich umstellen
Betreute Website (Agentur)	Je nach Vertrag die Agentur	Schriftlich bestätigen lassen: Version, Datum des Updates
Eigener Server, VPS oder Docker	Sie selbst oder Ihr Dienstleister	Pakete aktualisieren, Container-Images neu bauen, PHP-Prozesse neu starten
Router, NAS, Firewall	Der Gerätehersteller	Firmware-Update prüfen, Verwaltung nicht aus dem Internet erreichbar machen

Die Faustregel: Ein Hoster spielt Updates nur innerhalb der Version ein, die Sie gewählt haben. Den Wechsel von 8.1 auf 8.3 müssen Sie meist selbst anstoßen, weil er Ihre Website verändern kann.

3. Updaten oder vorübergehend abschalten

Abgesichert sind die Versionen 8.5.12, 8.4.27, 8.3.36 und 8.2.35 oder ein entsprechend gepatchtes Paket Ihrer Linux-Distribution. Läuft Ihre Website auf 8.1 oder älter, empfiehlt heise den Wechsel auf mindestens PHP 8.3. Diese Version bekommt laut Support-Plan des PHP-Projekts Sicherheitsupdates bis Ende 2027. PHP 8.2 erhält nur noch bis zum 31.12.2026 Updates, ein Wechsel dorthin verschiebt das Problem um zwei Monate.

Lässt sich nicht sofort updaten, rät CISA, betroffene Systeme bis zum Update vom Netz zu nehmen. Eine Web Application Firewall (WAF) kann als Zwischenlösung helfen. Cloudflare hat laut BleepingComputer Regeln auch im kostenlosen Tarif aktiviert und bezeichnet sie selbst als vorübergehende Notlösung. Sie schützen nur Verkehr, der tatsächlich über Cloudflare läuft.

Eine schwebende Glasfläche mit PHP-Code-Zeichen in Cyan, durch die eine rot glühende, gerissene Zeile läuft, die ein Lichtstrahl aus einem Schild in Cyan versiegelt. — Symbolbild, KI-generiert.

Für Ihren Dienstleister gibt es Notmaßnahmen bis zum Update. Diese Einstellungen nennt das PHP-Projekt in seinem Sicherheitshinweis als Überbrückung. Sie ersetzen das Update nicht und gehören in die Hände der Person, die Ihren Server betreut:

session.upload_progress.enabled=0 in der php.ini oder im FPM-Pool setzen und alle PHP-Prozesse neu starten. Eine Einstellung per ini_set oder .user.ini reicht nicht.
post_max_size auf 8M begrenzen, bei nötigen Uploads auf 32M.
Bei PHP 8.5 zusätzlich fatal_error_backtraces=0 setzen.

Woran Sie einen Angriff erkennen

Ein erfolgreicher Angriff fällt oft nicht sofort auf. Die Sicherheitsfirmen watchTowr und Patchstack sowie die CISA nennen typische Spuren. Lassen Sie Ihren Dienstleister gezielt danach suchen:

Unbekannte Dateien im Webverzeichnis, vor allem neue PHP-Dateien, die niemand angelegt hat.
Neue Administrator-Konten im CMS oder unbekannte geplante Aufgaben (Cronjobs) auf dem Server.
Auffällige Fehler im Protokoll, etwa viele Upload-Anfragen, gefolgt von Speicherfehlern oder Fehlermeldungen mit Code 500.
PHP-Prozesse, die Programme starten, die mit Ihrer Website nichts zu tun haben.

Findet sich eine dieser Spuren, gilt der Server als kompromittiert. Dann reicht das Update allein nicht. Ändern Sie alle Zugangsdaten, die auf dem Server gespeichert sind: Datenbank, Mail-Konten, Schnittstellen-Schlüssel. Denn laut Patchstack können über die Lücke auch Inhalte aus dem Speicher ausgelesen werden, etwa Passwörter oder Sitzungsdaten.

Was PHP2Shell über Wartung lehrt

PHP2Shell zeigt ein Muster, das sich wiederholen wird: Zwischen dem Bekanntwerden einer Lücke und den ersten Angriffsversuchen liegen heute Stunden, nicht Wochen. Das BSI begründet seine Einschätzung in der Pressemitteilung damit, dass Angreifer Updates mit KI-Hilfe schnell auswerten. Wer erst prüft, wer zuständig ist, wenn die Warnung kommt, verliert genau diese Stunden.

Bei Studio-Schott konnten wir die PHP-Installationen auf unseren eigenen Servern sofort nach Erscheinen der Updates aktualisieren. Das ist der Zustand, den Sie für Ihre Website anstreben sollten: Wenn die Warnung kommt, ist klar, wer handelt, und das Update ist eingespielt, bevor eine großflächige Ausnutzung einsetzt, wie sie das BSI erwartet.

Unsere Einordnung der W3Techs-Zahlen: Ein großer Teil des Risikos liegt nicht in der Lücke selbst, sondern in alten PHP-Versionen. Nach den W3Techs-Daten (Websites mit erkennbarer PHP-Version) läuft fast die Hälfte der PHP-Websites auf einer Version, für die es kein offizielles Update wie dieses gibt. Und am 31.12.2026 fällt mit PHP 8.2 der nächste Block weg.

Klären Sie deshalb drei Dinge schriftlich, auch wenn Ihre Website heute abgesichert ist:

Wer ist zuständig? Hoster, Agentur oder Sie selbst, mit Namen und Vertretung.
Wie schnell? Eine Frist für kritische Updates, zum Beispiel innerhalb von 24 Stunden nach Erscheinen.
Welche Version? Ein Plan, wann Ihre Website auf die nächste unterstützte PHP-Version wechselt, bevor die alte ausläuft.

Das ist dieselbe Logik wie bei jedem anderen Ablauf im Betrieb: feste Zuständigkeit, klare Frist, eine Person, die freigibt. Wie Sie solche Abläufe aufsetzen, beschreiben wir im Beitrag Prozessautomatisierung mit KI: der erste Ablauf mit Freigabe.

Häufige Fragen

Ist meine WordPress-Website betroffen?

Ja, solange auf dem Server keine abgesicherte PHP-Version läuft: 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder ein gepatchtes Paket Ihrer Distribution. Die Lücke steckt in PHP, nicht in WordPress. Entscheidend ist die PHP-Version auf dem Server, nicht die WordPress-Version.

Reicht es, wenn mein Hoster das Update einspielt?

Für PHP 8.2 bis 8.5 meistens ja. Fragen Sie trotzdem nach, ob es erledigt ist. Läuft Ihre Seite auf 8.1 oder älter, gibt es kein offizielles Update. Dann müssen Sie meist die Version wechseln, sofern Ihr Anbieter die alte Version nicht nachweislich selbst absichert.

Was passiert beim Wechsel der PHP-Version?

Ältere Plugins, Themes oder eigener Code laufen auf neuen Versionen manchmal nicht mehr. Testen Sie den Wechsel möglichst zuerst auf einer Kopie der Website. Ein Dienstleister kann prüfen, welche Teile angepasst werden müssen.

Muss ich meine Website abschalten?

Nur, wenn Sie nicht zeitnah updaten können. CISA rät in diesem Fall, betroffene Systeme bis zum Update vom Netz zu nehmen. Eine Wartungsseite, die als statische Datei ausgeliefert wird, ist besser als eine ungepatchte Website.

Nächster Schritt

Fragen Sie heute bei Ihrem Hoster oder Ihrer Agentur nach: Welche PHP-Version läuft, ist das Update vom 21.10.2026 eingespielt, und wann steht der nächste Versionswechsel an? Halten Sie die Antworten schriftlich fest.

Wenn Sie unsicher sind oder Ihre Website auf einer alten PHP-Version läuft, prüfen wir das gern mit Ihnen. Sie können ein Gespräch vereinbaren oder uns über das Kontaktformular schreiben. Einen Überblick über unsere Arbeit in Webentwicklung und Betrieb finden Sie auf der Startseite.

Über den Autor

Michael Schott verantwortet bei Studio-Schott Webentwicklung, SEO, die Sichtbarkeit in KI-Suchsystemen und Google Ads. Er entwickelt individuelle Softwarelösungen und betreut Websites und Server auf PHP-Basis. Mehr über das Team lesen Sie unter Über uns, die Angaben zum Anbieter im Impressum.

Quellen

Alle Quellen abgerufen am 22.10.2026. Die Lage entwickelt sich weiter; Stand dieses Beitrags ist der 22.10.2026.

Bildnachweis: Titelbild und beide Bilder im Text sind Symbolbilder, KI-generiert mit Google Gemini. Die Diagramme hat Studio-Schott erstellt.