PHP2Shell erklärt: Wie eine Sicherheitslücke Millionen Webseiten gefährdet – und was Betreiber tun müssen

Am 21. Oktober 2026 passierte etwas, das es so selten gibt: Städte nahmen ihre Webseiten freiwillig vom Netz. Mainz, Düsseldorf, Bochum, dazu Hochschulen, Kliniken und die Online-Dienste mehrerer Polizeibehörden. Nicht, weil sie angegriffen wurden. Sondern weil sie es nicht ausschließen konnten.

Der Grund heißt PHP2Shell: zwei Sicherheitslücken in PHP, der Software, auf der ein großer Teil aller Webseiten der Welt läuft. Das Bundesamt für Sicherheit in der Informationstechnik – das BSI, die oberste Cyber-Behörde des Bundes mit Sitz in Bonn – gab dafür Warnstufe 3 von 4 heraus und riet zu einem Schritt, den man von dort selten liest: Server im Zweifel vom Internet trennen.

Dieser Artikel erklärt, was da technisch passiert ist, warum es strukturell mehr als ein Update-Thema ist, wie du prüfst, ob deine eigene Seite betroffen ist – und was von diesem Fall bleibt, wenn die Aufregung vorbei ist. Denn das Muster wird sich wiederholen.

Was ist PHP – und warum hängt daran so viel?

PHP ist eine Skriptsprache, die auf dem Server arbeitet, nicht in deinem Browser. Stell dir eine unsichtbare Maschine im Hintergrund vor: Sie baut die Seite in dem Moment zusammen, in dem du sie aufrufst. Die Artikelliste, der Warenkorb, das Login, das Kontaktformular, die Terminbuchung – alles, was auf einer Webseite nicht starr ist, läuft über solchen Code.

Wie verbreitet das ist, zeigt ein Blick auf die Systeme, die darauf aufsetzen. Das BSI nennt in seiner Warnung unter anderem WordPress, TYPO3, Joomla, Drupal, Magento, Nextcloud, pfSense und OPNsense. Allein für WordPress – das Redaktionssystem hinter Blogs, Firmenseiten und Vereinsauftritten – gehen Branchenschätzungen von 400 bis 500 Millionen Webseiten aus. Die Sicherheitsfirma Wiz titelte zu PHP2Shell schlicht: betroffen seien 70 Prozent des Internets.

PHP ist damit das, was Fachleute kritische Infrastruktur nennen, ohne dass es je so geplant war. Es ist über Jahrzehnte gewachsen, es steckt in Millionen Installationen – und gepflegt wird es von einer überschaubaren Zahl von Menschen. Dazu später mehr.

Was genau ist die Lücke?

Es sind zwei Fehler, eingetragen als CVE-2026-109618 und CVE-2026-109619 – CVE ist der weltweite Katalog für Sicherheitslücken, damit alle über dieselbe Schwachstelle reden. Beide wurden mit 9,2 von 10 Punkten bewertet. Das ist nah am Maximum.

Technisch sitzen die Fehler in der Speicher- und der Fehlerverwaltung von PHP. Und das ist der entscheidende Punkt: nicht in WordPress, nicht in einem Plugin, nicht in einem Theme, sondern im Motor selbst. Wer die Lücken ausnutzt, kann eigene Befehle auf dem fremden Server ausführen. Fachleute nennen das Remote Code Execution – die Übernahme aus der Ferne.

Dafür braucht es weder ein Passwort noch irgendeine Handlung des Betreibers. Es braucht Geduld: mehrere tausend bis zehntausend Anfragen, bis die Maschine an der richtigen Stelle stolpert. Genau das macht die Sache gefährlich, denn Geduld lässt sich automatisieren. Ein Skript schafft das in Sekunden bis Minuten.

Was ein Angreifer danach tun kann: Datenbanken auslesen, also Kundendaten, Mitgliederlisten, Bestellungen. Die Seite manipulieren. Schadsoftware ablegen. Oder den Server als Sprungbrett für weitere Angriffe nutzen.

Betroffen sind praktisch alle PHP-Versionen, zurück bis mindestens PHP 5 – eine Version, die seit über 20 Jahren aus dem Verkehr ist. Verwundbar sind alle Installationen, die Webanfragen verarbeiten: PHP-FPM, Apache mit mod_php, php-cgi, LiteSpeed, FrankenPHP. Das PHP-Sicherheitsteam hält das Risiko bei mod_php für am höchsten, weil ein Angriff dort greifen kann, bevor überhaupt eigener Anwendungscode läuft.

Warum reicht es nicht, WordPress zu aktualisieren?

Das ist der häufigste Denkfehler bei dieser Art von Lücke – und er kostet Zeit, die man nicht hat.

Dein Redaktionssystem ist der Aufbau. PHP ist das Fundament. Ein Update von WordPress, TYPO3 oder Shopware ändert nichts daran, dass die darunterliegende PHP-Laufzeitumgebung verwundbar ist. Das BSI formuliert es unmissverständlich: Ein Update der Anwendungen ist nicht ausreichend, die PHP-Laufzeitumgebung muss ebenfalls gepatcht werden.

Dasselbe gilt für Docker-Container: Läuft darin eine verwundbare PHP-Version, muss der Container neu gebaut oder aktualisiert werden – unabhängig davon, was außen herum passiert.

Wie finde ich heraus, ob meine Seite betroffen ist?

Drei Wege, von einfach nach technisch:

1. Beim Hoster nachsehen. Bei Shared Hosting – also dem günstigen Paket, bei dem viele Seiten auf einem Server liegen – steht die PHP-Version im Kundenmenü, oft unter „PHP-Einstellungen“ oder „PHP-Version“. Dort lässt sie sich meist auch umschalten. Ebenso lohnt der Blick auf die Status- oder Wartungsseite des Anbieters: Seriöse Hoster haben in solchen Lagen längst informiert.

2. Direkt fragen. Ein kurzer Satz an den Support reicht: „Welche PHP-Version läuft auf meinem Paket, und sind die Patches gegen CVE-2026-109618 und CVE-2026-109619 eingespielt?“ Wer darauf keine klare Antwort bekommt, hat ein zweites Problem.

3. Auf dem eigenen Server. Mit Zugang per SSH zeigt php -v die Version an. Wichtig: Linux-Distributionen pflegen ihre eigenen, zurückportierten Pakete. Die Versionsnummer kann also abweichen und der Fehler trotzdem behoben sein – das Advisory der Distribution gibt Auskunft.

Diese Versionen enthalten die Korrektur: 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für die offiziell ausgelaufenen Versionen 7.4, 8.0 und 8.1 hat das PHP-Sicherheitsteam zusätzlich Backports bereitgestellt.

Und eine Zahl zum Vormerken: Bei PHP 8.2 endet die Sicherheitsunterstützung Ende 2026. Alles darunter ist schon jetzt ohne Pflege. Wer gerade sowieso Hand anlegt, sollte deshalb gleich auf einen Stand wechseln, der noch Jahre unterstützt wird.

Was tun, wenn sich nicht sofort patchen lässt?

Hier liegt der ungewöhnlichste Teil der BSI-Empfehlung. Die Behörde schreibt: Sollten Patches nicht umgehend installiert werden können, empfiehlt das BSI eine vorübergehende Trennung vom Internet zu erwägen, da alle Workarounds keinen vollständigen Schutz vor Angriffen bieten.

Genau das haben die Städte getan. Eine abgeschaltete Seite ist ärgerlich, ein übernommener Server mit Bürgerdaten ist eine andere Größenordnung.

Für alle, die sich eine Abschaltung nicht erlauben können, gibt es Zwischenstufen:

• Eine Web Application Firewall – ein Filter, der Anfragen prüft, bevor sie den Server erreichen. Anbieter wie Cloudflare und Bunny Shield haben Regeln gegen die bekannten Angriffswege veröffentlicht.
• Die vom PHP-Team genannten Konfigurationsanpassungen, etwa ein stark reduziertes post_max_size, ein abgeschaltetes session.upload_progress oder gesetzte memory_limit-Werte.
• Auf Linux-Systemen SELinux oder AppArmor konfigurieren, um den Schaden einer erfolgreichen Übernahme zu begrenzen.

Entscheidend ist die Einordnung, die sowohl das PHP-Team als auch das BSI mitgeben: Diese Maßnahmen erschweren einen Angriff, sie verhindern ihn nicht. Das PHP-Team nennt sie wörtlich eine temporäre Krücke. Sie überbrücken die Zeit bis zum Update – sie ersetzen es nicht.

Die vergessene Technik: NAS, Router, Appliances

Der Punkt, der in solchen Lagen regelmäßig untergeht: PHP steckt nicht nur auf Webservern. Viele Geräte bringen für ihre Verwaltungsoberfläche eine eigene PHP-Installation mit. Auf den Listen stehen unter anderem QNAP und Synology (Netzwerkspeicher), DrayTek, ZyXEL, D-Link, TP-Link, Netgear und Tenda (Router), dazu pfSense und OPNsense (Firewalls).

Auch Sicherheitsprodukte von Citrix, Palo Alto und Ivanti sowie Loadbalancer von F5 nutzen PHP. Die Niederländische Cyber-Behörde NCSC-NL sammelt betroffene Produkte in einem öffentlichen Verzeichnis, das laufend wächst.

Für diese Geräte gilt eine Regel, die über diesen Fall hinaus trägt: Die Verwaltungsoberfläche hat im offenen Internet nichts zu suchen. Wer sie nur im Heim- oder Firmennetz erreichbar macht, nimmt sich aus der Schusslinie – bei dieser Lücke und bei der nächsten.

Woran erkenne ich, dass etwas passiert ist?

Konkrete Angriffsindikatoren gab es zum Zeitpunkt der BSI-Warnung noch nicht. Die üblichen Warnzeichen gelten aber immer:

• unbekannte Dateien im Webverzeichnis, besonders mit PHP-Endung an ungewöhnlichen Stellen
• Prozesse auf dem Server, die niemand gestartet hat
• plötzlich ausgehender Datenverkehr, etwa Massen-Mails aus dem eigenen System
• geänderte Inhalte, neue Benutzerkonten mit Adminrechten, unerklärliche Weiterleitungen
• Logeinträge mit auffällig vielen Anfragen aus wenigen Quellen in kurzer Zeit

Bei einem Verdacht gilt: nicht einfach weiterarbeiten. Backup des Ist-Zustands für die Spurensuche, dann Fachleute dazuholen. Und daran denken, dass ein Backup nur hilft, wenn es vom Produktivsystem getrennt liegt und sich tatsächlich zurückspielen lässt. Das lässt sich übrigens in einer ruhigen Stunde testen, nicht erst im Ernstfall.

Die eigentlich interessante Geschichte: Wer die Lücken gefunden hat

Und damit zum Teil, der diesen Fall über einen Patch-Dienstag hinaus bedeutsam macht.

Entdeckt wurden die Schwachstellen bei einer Prüfung des Quellcodes, die die Sicherheitsfirma Calif gemeinsam mit dem PHP Ecosystem Security Team durchführte und die OpenAI finanzierte. Mehrere Teams, darunter die Google-Tochter Wiz, ließen große Sprachmodelle über den PHP-Code laufen und konnten die Fehler so nachvollziehen und die Korrektur überprüfen.

Zwanzig Jahre lang hat niemand diese beiden Stellen gefunden. Eine KI, die Millionen Zeilen Code durchgeht, ohne müde zu werden, hat sie gefunden.

Das ist zunächst eine gute Nachricht. Code-Audits waren teuer, langsam und deshalb selten. Dass sie günstiger und schneller werden, ist ein echter Gewinn für die Sicherheit aller.

Nur gilt derselbe Satz von der anderen Seite. Das BSI schreibt es in seiner Warnung ausdrücklich hin: Spätestens seit dem Aufkommen KI-gestützter Werkzeuge zur Exploit-Entwicklung verfügen Angreifer über die Mittel, Patches innerhalb kurzer Zeit zu analysieren und Angriffe daraus zu generieren. Genau deshalb hielt die Behörde eine breite Ausnutzung innerhalb weniger Stunden nach Erscheinen der Updates für wahrscheinlich.

Hier verschiebt sich etwas grundlegend. Früher war ein Patch ein Vorsprung: Die Lücke war geschlossen, und bis jemand aus dem Update ableitete, wie man sie ausnutzt, gingen Tage oder Wochen ins Land. Dieser Vorsprung schrumpft auf Stunden. Nicht, weil die Angreifer schlauer geworden sind – sondern weil beide Seiten dasselbe Werkzeug benutzen. KI denkt nicht, sie rechnet. Und sie rechnet für jeden, der sie einsetzt.

Die Konsequenz für Betreiber ist unbequem, aber klar: Wer Updates in Ruhe am Monatsende einspielt, ist mit diesem Modell durch. Was zählt, ist die Fähigkeit, innerhalb von Stunden reagieren zu können.

Was Nutzer ohne eigene Webseite wissen müssen

Wer im Netz liest, einkauft und Mails schreibt, muss selbst nichts reparieren. Zwei Dinge lohnen trotzdem die Aufmerksamkeit.

Betrugswellen. Große Sicherheitsvorfälle sind für Kriminelle eine Vorlage. Mails, die zu einem „Sicherheitscheck“ auffordern, ein neues Passwort verlangen oder vor einem Datenleck warnen, häufen sich in solchen Wochen. Keine Bank und kein Shop verschickt dafür Links. Wer prüfen will, tippt die Adresse selbst ein.

Passwörter. Meldet ein Shop, ein Forum oder ein Verein später tatsächlich einen Datenabfluss, hilft nur ein neues Passwort, das nirgends sonst benutzt wird – am besten aus einem Passwortmanager, dazu die Zwei-Faktor-Anmeldung. Der Aufwand ist einmalig, der Nutzen dauerhaft.

Und eine Einordnung, die beim nächsten Mal Gelassenheit spart: Eine abgeschaltete Behördenseite ist in so einer Lage keine Panne und kein Hinweis auf einen Angriff. Sie ist die Vorsichtsmaßnahme, zu der geraten wurde.

Die Checkliste, die auch beim nächsten Mal gilt

PHP2Shell ist irgendwann abgearbeitet. Das Muster bleibt. Diese Punkte lohnen sich unabhängig vom konkreten Fall:

1. Wissen, was läuft. Welche PHP-Version, welches CMS, welche Plugins, auf welchem Server, bei welchem Hoster? Wer das nicht in fünf Minuten beantworten kann, verliert im Ernstfall Stunden.
2. Einen Weg zur Information haben. Status-Seite des Hosters, Newsletter des BSI, eine Fachquelle. Von einer kritischen Lücke sollte man nicht aus der Tagesschau erfahren.
3. Updates automatisieren, wo es vertretbar ist. Sicherheitsupdates des Betriebssystems unbeaufsichtigt einspielen zu lassen, ist für die meisten Seiten das kleinere Risiko.
4. Veraltete Versionen rauswerfen. Jede Software ohne Pflege ist eine offene Rechnung. Das gilt für PHP-Versionen genauso wie für das Plugin, das seit drei Jahren kein Update gesehen hat.
5. Verwaltungszugänge schließen. Admin-Oberflächen, Datenbankwerkzeuge und Geräte-Interfaces gehören nicht ins offene Internet.
6. Backups, die getrennt liegen und getestet sind. Ein Backup auf demselben Server ist kein Backup.
7. Einen Plan für den schlechten Tag. Wer entscheidet über eine Abschaltung? Wer hat die Zugangsdaten? Wen ruft man an? Diese Fragen beantwortet man besser vorher.

Häufige Fragen

Ist meine WordPress-Seite betroffen? Nicht WordPress selbst ist das Problem, sondern das PHP darunter. Betroffen sind praktisch alle Installationen, die nicht auf 8.5.12, 8.4.27, 8.3.36, 8.2.35 oder einem gepatchten Distributionspaket laufen. Die Frage geht an den Hoster.

Reicht es, auf die neueste WordPress-Version zu aktualisieren? Nein. Das Fundament bleibt dadurch unverändert.

Wurden die Lücken schon ausgenutzt? Zum Zeitpunkt der BSI-Warnung lagen keine bestätigten Fälle vor, aber unbestätigte Berichte über existierende Exploits. Das BSI hielt eine Ausnutzung innerhalb weniger Stunden nach dem Patch für wahrscheinlich.

Woher kommt der Name PHP2Shell? Er ist eine Anspielung auf Log4Shell – eine Lücke von Dezember 2021, die damals weltweit Server lahmlegte und zum Standardvergleich für Schwachstellen in weitverbreiteten Bausteinen geworden ist.

Muss ich mein Passwort ändern? Nicht pauschal. Erst, wenn ein Anbieter tatsächlich einen Datenabfluss meldet. Dann aber sofort und nur mit einem Passwort, das nirgends sonst im Einsatz ist.

Was ist mit meinem NAS zu Hause? Beim Hersteller nach einer neuen Firmware sehen – und die Verwaltungsoberfläche so einstellen, dass sie nur im Heimnetz erreichbar ist.