Radar

PHP2Shell: Was die kritische PHP-Lücke für deine Website bedeutet

22. Oktober 2026 · 7 Min. Lesezeit

Am 21. Oktober 2026 hat PHP zwei kritische Lücken geschlossen, die fast jede WordPress-, Shopware- oder JTL-Seite betreffen. Wer betroffen ist, wie die Hoster reagiert haben und was du jetzt prüfen solltest.

Artikel lesen

Die Kurzantwort

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, zusammen bekannt als PHP2Shell. Angreifer können darüber ohne Login fremden Code auf einem Webserver ausführen. Betroffen ist praktisch jede Website, die mit PHP läuft, also WordPress, WooCommerce, Shopware, JTL und viele mehr.

Schützen kann dich nur ein PHP-Update auf dem Server. Ein Update von WordPress oder deinen Plugins hilft nicht. Bei normalem Webhosting spielt dein Hoster das Update ein. Wir haben den 21. und 22. Oktober mit unseren Kunden durchgestanden, Hoster abgeklopft und einige Seiten vorsorglich offline genommen. Was passiert ist und was du jetzt prüfen solltest, steht hier. Stand: 22. Oktober 2026.

Was ist PHP2Shell?

PHP ist die Programmiersprache, mit der ein Großteil aller Websites läuft. Jedes Mal, wenn jemand deine Seite aufruft oder ein Formular abschickt, verarbeitet PHP diese Anfrage auf dem Server.

PHP2Shell ist der Sammelname für zwei Fehler in diesem Kern, geführt als CVE-2026-109618 und CVE-2026-109619. Das PHP-Sicherheitsteam bewertet beide mit 9,2 von 10 Punkten, der höchsten Stufe.

Vereinfacht passiert Folgendes. Läuft PHP mitten in der Verarbeitung einer Anfrage der Speicher voll, bricht es ab, behandelt beim Aufräumen die halb fertigen Daten aber trotzdem als gültig. Der zweite Fehler ist ein Verwandter davon: Reste einer Anfrage bleiben im Speicher liegen, und eine spätere Anfrage greift darauf zu, obwohl sie längst ungültig sind. Ausgelöst wird beides über präparierte Formular- und Upload-Anfragen, und zwar bevor der Code deiner Website überhaupt startet. Deine Seite kann sauber programmiert sein und ist trotzdem angreifbar.

Warum das so ernst ist

Normalerweise läuft so etwas still ab. Forschende melden die Lücke vertraulich, PHP baut einen Fix, und Details werden erst mit dem Update veröffentlicht. Diesmal sind die Informationen am 20. Oktober vorab durchgesickert, und PHP hat das Update um einen Tag vorgezogen. Angreifer wussten also früh Bescheid. Cloudflare und watchTowr haben Angriffsversuche gemeldet, zum Teil schon vor dem Update; erfolgreiche Einbrüche waren bis zum Abend des 21. Oktober nicht öffentlich dokumentiert.

Gelingt ein Angriff, kann der Angreifer auf dem Server alles, was deine Website auch kann. Er liest Zugangsdaten aus, greift auf die Datenbank mit Kunden- und Bestelldaten zu, legt eine Hintertür ab oder verschickt Spam über deine Domain. Dass dein Betrieb klein ist, hilft dabei nicht, denn solche Angriffe laufen automatisiert. Bots durchsuchen das ganze Internet nach verwundbaren Servern, und ob dahinter ein Konzern steckt oder ein Handwerksbetrieb, sehen sie gar nicht erst nach.

Wer ist betroffen?

Jeder, dessen Website mit PHP läuft und noch nicht aktualisiert ist. Sicher sind erst diese Versionen:

PHP 8.5 ab 8.5.12
PHP 8.4 ab 8.4.27
PHP 8.3 ab 8.3.36
PHP 8.2 ab 8.2.35
PHP 8.1 und älter: kein offizielles Update mehr

Es trifft also nicht nur alte Installationen. Auch die aktuellen Versionen sind verwundbar, bis das Update eingespielt ist. Wer noch auf PHP 8.1 oder älter läuft, bekommt vom PHP-Projekt keinen Fix mehr und muss auf eine aktuelle Version wechseln.

Nicht betroffen sind Systeme ohne PHP, etwa Shopify, Webflow oder statische Seiten, zum Beispiel mit Astro gebaut.

Zwei Karten: Websites mit PHP brauchen ein Update, Websites ohne PHP sind nicht betroffen — PHP-Seiten brauchen das Server-Update. Shopify, Webflow und Astro nicht.

Wie die Hoster reagiert haben

Bei normalem Webhosting bist du auf deinen Hoster angewiesen. Wir arbeiten mit mehreren zusammen, und die Unterschiede am 21. Oktober waren deutlich.

Am schnellsten war nach unserer Beobachtung Raidboxes. Die dort gehosteten WordPress-Seiten waren innerhalb kürzester Zeit abgesichert, und auch gegenüber anderen Agenturen hat Raidboxes noch am 21. Oktober bestätigt, dass PHP 8.2 bis 8.5 gepatcht sind. JTL hat seine Kunden aktiv per E-Mail informiert; laut JTL waren alle gehosteten Shops zügig auf gepatchte Versionen aktualisiert, bei uns war die Lücke nach rund 30 Minuten zu.

All-inkl hat vorsorglich eine PHP-Funktion für Upload-Fortschrittsanzeigen auf allen Servern abgeschaltet, über die nach damaligem Kenntnisstand einer der Angriffswege führt. Gleichzeitig waren Kundenmenü, Webmail und Web-FTP offline. Eine Meldung auf der eigenen Website haben wir nicht gefunden; die Information kursierte vor allem über Kunden in Foren. IONOS meldete auf seiner Statusseite eine Sicherheitswartung mit Abschluss innerhalb von 24 Stunden, Alfahosting informierte ebenfalls über die Statusseite und arbeitete am 21. Oktober noch an den Updates.

Für uns als Kreativstudio war damit oft nicht eindeutig zu prüfen, ob eine bestimmte Kundenseite schon abgesichert war. Die Informationslage war bei vielen Hostern dürftig.

Was wir gemacht haben

Wenn wir nicht sicher sagen können, dass ein Server gepatcht ist, gehen wir vom Schlimmsten aus. Deshalb haben wir etliche Kundenseiten und auch eigene Projekte vorübergehend offline genommen. Statt der Website lieferte der Server eine einfache Wartungsseite aus reinem HTML aus, die ohne PHP läuft und damit nicht angreifbar ist.

Das betraf auch Seiten, bei denen man es nicht sofort vermutet. Reine HTML-Seiten mit Kontaktformular zum Beispiel: Die Seite selbst ist statisch, aber das Formular verschickt seine Daten über ein kleines PHP-Script, und dieses Script ist ein möglicher Angriffspunkt. Ähnlich bei Webflow. Webflow selbst nutzt kein PHP und ist nicht betroffen, wir binden bei unseren Kunden aber oft einen eigenen Mailversand per PHP ein, damit die Formulardaten nicht bei Webflow in den USA landen, sondern unter Kontrolle des Kunden bleiben. Gut für den Datenschutz, an diesem Tag aber ein Grund, den PHP-Teil bis zum Patch zu sperren. Das galt auch für die Seite unserer Beratungsfirma Cozmoo.

Unsere eigene Website blieb online. Wir haben sie vor Kurzem von Webflow auf Astro mit Sanity umgezogen, gehostet bei Cloudflare, und sie läuft komplett ohne PHP. Warum wir diesen Schritt gegangen sind, erklären wir in einem eigenen Artikel: Webflow oder Astro mit Sanity. Sicherheit war nicht der Hauptgrund, hat sich an diesem Tag aber ausgezahlt.

Was du jetzt tun solltest

Hast du normales Webhosting, spielt dein Hoster das Update ein. Drei Dinge bleiben trotzdem bei dir:

Prüf, welche PHP-Version deine Website nutzt. Bei WordPress steht sie unter Werkzeuge → Website-Zustand → Bericht → Server.
Läuft noch PHP 8.1 oder älter, stell im Kundenmenü deines Hosters auf 8.3 oder 8.4 um und teste danach Startseite, Formulare und Checkout.
Frag deinen Hoster, ob der Fix für CVE-2026-109618 und CVE-2026-109619 auf deinem Server installiert ist. Die Versionsnummer allein beweist wenig, weil manche Hoster Fixes einspielen, ohne die Nummer zu ändern.

Hast du einen eigenen Server, musst du selbst aktualisieren und alle PHP-Prozesse neu starten. Bis dahin ist offline die bessere Wahl.

Der Patch schließt nur die Tür, und was vorher hereingekommen ist, bleibt. Prüf deshalb, ob seit dem 20. Oktober neue Admin-Konten oder unbekannte PHP-Dateien aufgetaucht sind, vor allem in Upload-Ordnern. Bei einem Shop mit Kundendaten empfehlen wir, vorsorglich alle Passwörter zu wechseln.

Nicht helfen werden dir Sicherheits-Plugins, der Wartungsmodus von WordPress oder Shopware und Updates von Themes oder Plugins. All das läuft erst, nachdem PHP die gefährliche Anfrage schon verarbeitet hat.

Unsicher, ob deine Website abgesichert ist?

Wir betreuen Websites und Shops auf WordPress, Shopware, JTL, Webflow und Astro. Bei PHP2Shell haben wir für unsere Kunden den Stand bei den Hostern geprüft, Seiten vorsorglich gesperrt und nach dem Update wieder freigegeben. Wenn du nicht weißt, ob deine Seite betroffen ist, oder beim Umstieg auf eine aktuelle PHP-Version Hilfe brauchst, melde dich für ein unverbindliches Erstgespräch. Wir schauen nach.