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

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, die unter dem Namen „PHP2Shell“ bekannt geworden sind. Sie erlauben Angriffe auf Webserver ohne Login und ohne dass jemand etwas anklickt. Betroffen ist PHP selbst — also auch WordPress, Joomla, TYPO3, Shopware und fast jede andere PHP-Website.

Die gute Nachricht: Die Lücken sind behoben. Die schlechte: Die Details sind vor dem Patch durchgesickert, und viele KMU-Websites laufen auf PHP-Versionen, für die es keinen offiziellen Fix mehr gibt. Hier steht, was passiert ist, wie du in fünf Minuten prüfst, ob deine Seite betroffen ist — und wann ein Update nicht mehr reicht.

PHP2Shell ist der Sammelname für zwei Schwachstellen mit den Kennungen CVE-2026-109618 und CVE-2026-109619. Beide sind vom PHP-Projekt mit 9.2 von 10 Punkten (CVSS v4.0) als kritisch eingestuft. Gefunden haben sie Forschende von Calif, Wiz, OpenAI und Quarkslab.

Technisch geht es um die Art, wie PHP Speicher aufräumt, wenn eine Anfrage abbricht — etwa weil der Speicher ausgeht. In bestimmten Fällen bleiben dabei Datenreste liegen, die eine spätere Anfrage wieder aufgreift. Wer diese Reste gezielt präpariert, kann im schlimmsten Fall eigenen Code auf dem Server ausführen. Daher der Name: von PHP zur „Shell“, also zur Kommandozeile des Servers.

Der entscheidende Punkt für Website-Betreiber: Der Angriff passiert, bevor der Code deiner Website überhaupt läuft. Es spielt keine Rolle, wie sauber dein Theme programmiert ist oder welche Plugins du einsetzt. Laut Imperva kann selbst eine Seite betroffen sein, die nichts anderes tut, als „OK“ auszugeben.

Das ist kein Randthema. PHP läuft laut Cloudflare auf fast 70 Prozent aller Websites.

Für dich heisst das: Es gibt keinen Grund zur Panik, aber auch keinen, bis nächste Woche zu warten. Bei Lücken dieser Grösse scannen automatisierte Werkzeuge innert Tagen das ganze Internet nach verwundbaren Servern. Ob deine Website klein oder unbekannt ist, spielt dabei keine Rolle.

Du brauchst dafür keinen Entwickler. Drei Schritte:

1. Läuft deine Website auf PHP? Bei WordPress, Joomla, TYPO3, Drupal, Contao, Shopware, WooCommerce und Magento: ja. Bei einer statisch ausgelieferten Seite, einem modernen JavaScript-Stack oder einem gehosteten Baukasten in der Regel nicht.
2. Welche PHP-Version läuft? In WordPress unter „Werkzeuge → Website-Zustand → Bericht → Server“. Sonst im Kundenbereich deines Hosters (Plesk, cPanel o. ä.) unter „PHP-Einstellungen“.
3. Vergleiche mit der Tabelle unten. Liegt deine Version darunter, bist du verwundbar.

Achtung bei Linux-Distributionen: Wenn dein Hoster PHP über Debian, Ubuntu oder Red Hat bezieht, kann die Versionsnummer älter aussehen, obwohl der Fix eingespielt ist. Die Distributionen haben die Patches vorab erhalten. In diesem Fall hilft nur eine Nachfrage beim Hoster. Bitte um eine schriftliche Antwort mit Datum.

Wenn du Shared Hosting nutzt

Das ist der häufigste Fall bei KMU. Dein Hoster aktualisiert die PHP-Programme auf seinen Servern — aber welche Version deine Website nutzt, wählst du oft selbst. Wer vor Jahren „PHP 7.4“ eingestellt hat, läuft möglicherweise heute noch darauf. Prüfe die Einstellung und wechsle auf eine aktuelle Version. Danach die Website kurz durchklicken: Kontaktformular, Shop, Login.

Wenn du einen eigenen Server oder eine Agentur hast

Frag nach, ob PHP auf eine der gepatchten Versionen aktualisiert wurde und wann. Falls das nicht sofort möglich ist, empfiehlt das PHP-Projekt Übergangsmassnahmen, unter anderem session.upload_progress.enabled=0 und strengere Grenzen für Upload-Grössen. Diese machen eine Installation ausdrücklich nicht sicher — sie verkleinern nur die Angriffsfläche, bis das Update drauf ist.

Was nicht hilft

• WordPress, Theme und Plugins aktualisieren. Wichtig, aber die Lücke steckt in PHP selbst, nicht in WordPress.
• Ein Sicherheits-Plugin installieren. Der Angriff läuft, bevor WordPress geladen wird.
• Fehlermeldungen ausblenden. Laut PHP-Projekt ändert das nichts.

Eine Web-Application-Firewall wie die von Cloudflare blockiert bekannte Angriffsmuster und ist eine sinnvolle zusätzliche Schicht. Sie ersetzt das PHP-Update aber nicht — Angreifer haben ihre Muster bereits angepasst, um die Regeln zu umgehen.

Wenn deine Seite seit dem 20. Oktober ungepatcht online war

Dann lohnt sich ein Blick auf Anzeichen eines Einbruchs: unbekannte Admin-Konten, neue PHP-Dateien in Upload-Ordnern, Weiterleitungen auf fremde Seiten, ungewöhnliche Last auf dem Server. Im Zweifel gilt: Ein kompromittierter Server wird nicht „geputzt“, sondern sauber neu aufgesetzt.

Für eine gepflegte Website ist PHP2Shell ein Update am Nachmittag. Für viele KMU-Websites ist es mehr — und zwar nicht wegen der Lücke, sondern wegen dem, was sie sichtbar macht. Diese Fälle sehen wir regelmässig:

• Das Update bricht die Seite. Ein Theme von 2018, ein Plugin, das seit Jahren keine Updates mehr bekommt: Auf PHP 8.2 oder neuer kommt nur noch eine weisse Seite. Die Website zwingt dich, auf einer verwundbaren Version zu bleiben.
• Niemand ist mehr zuständig. Die Agentur gibt es nicht mehr, der Neffe hat studiert, die Zugangsdaten liegen irgendwo in einem E-Mail-Verlauf. Wer heute nicht innert einer Stunde sagen kann, wer die PHP-Version ändern darf, hat ein Betriebsproblem, kein Technikproblem.
• Die nächste Pflichtrunde steht schon an. PHP 8.2 bekommt ab dem 31. Dezember 2026 keine Sicherheitsupdates mehr. Wer jetzt mit Mühe auf 8.2 hochzieht, steht in zehn Wochen vor derselben Frage.
• Die Seite tut ohnehin nicht mehr, was sie soll. Langsam, auf dem Handy schwer bedienbar, bei Google kaum sichtbar. Dann kostet eine aufwändige Rettung der alten Technik Geld, das in einer neuen Seite besser angelegt ist.

Treffen zwei oder mehr dieser Punkte zu, ist PHP2Shell ein guter Anlass, die Website grundsätzlich neu zu denken — nicht als Notfallmassnahme, sondern als geplanten Schritt. Heute zuerst patchen oder vom Netz nehmen, danach in Ruhe entscheiden.

Die Websites, die wir bauen, sind von PHP2Shell nicht betroffen — nicht weil wir besser aufgepasst hätten, sondern weil sie anders gebaut sind. Das Prinzip ist simpel:

• Vorgefertigte Seiten statt Live-Berechnung. Die meisten Seiten werden einmal erzeugt und dann als fertige Datei ausgeliefert. Beim Besuch läuft kein Programm, das jede Anfrage neu zusammensetzt und dabei angreifbar wäre.
• Kein Plugin-Zoo. Funktionen, die du brauchst, sind Teil des Projekts — nicht zwanzig Erweiterungen von zwanzig Herstellern, die alle einzeln aktuell gehalten werden müssen.
• Ein modernes CMS, getrennt von der Website. Du pflegst Inhalte selbst, ohne dass das Redaktionssystem direkt im öffentlichen Auftritt hängt.
• Updates sind unsere Aufgabe. Wenn eine Lücke wie diese auftaucht, erfährst du es von uns, mit der Information, ob du betroffen bist — nicht aus der Zeitung.

Unverwundbar macht das keine Website. Auch Node.js und JavaScript-Bibliotheken haben Sicherheitslücken. Aber es gibt deutlich weniger bewegliche Teile, und die, die es gibt, liegen in einer Hand. Auf Wunsch liegen Hosting und Daten vollständig in der Schweiz.

Was eine neue Website kostet, haben wir offen aufgeschlüsselt: „Was kostet eine Website in der Schweiz?“. Wie wir bauen und was du selbst pflegen kannst, steht unter Websites. Und wenn du unsicher bist, ob deine Seite betroffen ist: Schick uns die Adresse — wir sagen dir ehrlich, ob ein Update genügt oder ob sich ein Neubau lohnt.

• PHP-Projekt: Sicherheitshinweis und Releases vom 21. Oktober 2026
• Cloudflare: Schutzregeln gegen PHP2Shell
• Imperva: Technische Analyse von PHP2Shell
• Help Net Security: PHP2Shell gepatcht

Stand: 22. Oktober 2026. Wir aktualisieren diesen Artikel, sobald sich die Lage ändert.