PHP2Shell: Die Lücke, die Städte vom Netz nahm. Und warum Ihr Hoster entscheidet, ob Sie betroffen waren

In der Nacht zum 22. Oktober 2026 haben Rathäuser, Kliniken und Verkehrsbetriebe ihre Websites abgeschaltet. Nicht wegen eines Angriffs, sondern aus Vorsicht: Zwei Lücken im Kern von PHP erlauben es, fremden Code auf einem Webserver auszuführen, ohne Anmeldung, aus der Ferne. PHP steckt unter WordPress, unter fast jedem Shop und unter den meisten Firmenwebsites. Wer so eine Website betreibt, konnte in dieser Nacht nichts tun. Die Arbeit lag beim Hoster. Und genau daran erkennt man, ob man einen guten hat.

Was in dieser Woche passiert ist

Die beiden Schwachstellen tragen die Kennungen CVE-2026-109618 und CVE-2026-109619, die Sicherheitsbranche nennt sie zusammen „PHP2Shell“. Entdeckt wurden sie von zwei Sicherheitsfirmen, darunter Huntress, und vertraulich an das PHP-Team gemeldet. So läuft das normalerweise: Die Entwickler bauen in Ruhe eine Korrektur, dann erscheinen Update und Warnung am selben Tag, und die Angreifer erfahren erst davon, wenn die Lösung schon da ist.

Diesmal nicht. Am Dienstag, dem 20. Oktober, landeten die Details einen Tag vor dem geplanten Update im Netz. Damit kannten Angreifer die Lücke, bevor es eine Korrektur gab. Das Bundesamt für Sicherheit in der Informationstechnik stufte die Lage mit Warnstufe 3 von 4 ein, „Orange“, also außerordentlich hoch. Die Empfehlung in dieser Lage ist unbequem: Wer das Risiko nicht tragen will, trennt seine PHP-Server vom Netz, bis das Update installiert ist.

Viele haben genau das getan. Mainz schaltete das zentrale Webportal und mehrere städtische Dienste ab, Potsdam und Halberstadt ihre Stadtseiten, die Charité in Berlin ihre offizielle Website. In Hannover nahm die Üstra ihren Auftritt vom Netz, mit Folgen bis in den Fahrkartenkauf in der App. In den Niederlanden waren das nationale Cybersicherheitszentrum, der Hafen Rotterdam und der Fußballverband nicht erreichbar, weitere Abschaltungen gab es in Dänemark, Finnland und Japan.

Am Mittwochnachmittag, dem 21. Oktober, veröffentlichte das PHP-Projekt die korrigierten Versionen. Seitdem läuft weltweit ein Wettlauf: Hoster und Administratoren spielen Updates ein, Angreifer bauen Werkzeuge, die den Fehler automatisch ausnutzen. Heise Security rechnete mit funktionierenden Schadprogrammen innerhalb von Stunden bis Tagen. Das BSI erwartet, dass die Angriffswelle über Wochen und Monate anhält.

Was die Lücke technisch kann

Beide Fehler sitzen in der Speicher- und Zustandsverwaltung von Webanfragen, also dort, wo PHP jede einzelne Anfrage eines Besuchers entgegennimmt. Ein Angreifer schickt eine präparierte Anfrage, und der Server führt daraufhin Code aus, den der Angreifer mitgeschickt hat. Fachleute nennen das Remote Code Execution. Im Schweregrad-System CVSS steht die Lücke bei 9,2 von 10.

In der Praxis heißt das: Wer die Lücke ausnutzt, kann eine Website komplett übernehmen. Er kann die Datenbank mit Kundendaten, Bestellungen und Passwörtern auslesen, Dateien verändern, Schadcode für Besucher einbauen oder den Server als Sprungbrett für weitere Angriffe missbrauchen. Es braucht dafür kein Passwort und keinen Zugang. Es reicht, dass die Website erreichbar ist und eine verwundbare PHP-Version benutzt.

Die letzte Zeile ist die unangenehmste. Für PHP 8.1, 8.0 und 7.4 liefert das PHP-Projekt keine fertigen Updates mehr, weil diese Zweige das Ende ihrer Wartung längst erreicht haben. Wer dort noch läuft, ist auf Rückportierungen seines Hosters oder seiner Linux-Distribution angewiesen. Gibt es die nicht, bleibt nur abschalten oder isolieren. Das BSI sagt das in dieser Deutlichkeit.

Noch ein Punkt, den man wissen sollte: Es gibt Konfigurationsänderungen, die das Risiko verringern, etwa das Abschalten einzelner PHP-Funktionen. Das PHP-Projekt selbst nennt sie nur als Notbehelf. Auch eine Web-Firewall, die verdächtige Anfragen abfängt, ersetzt den Patch nicht. Sie kauft Zeit, mehr nicht. Die einzige vollständige Lösung ist das Update.

Warum Sie das als Website-Betreiber nicht selbst lösen können

Hier liegt der Punkt, der in vielen Berichten untergeht. Wenn Sie eine WordPress-Website, einen Shop oder ein Portal betreiben, pflegen Sie das System und seine Erweiterungen. PHP liegt eine Etage tiefer. Es gehört zum Server, nicht zur Website. Bei einem Webhosting-Paket, wie es die meisten Betriebe haben, kommen Sie an diese Etage gar nicht heran. Sie können in Ihrem Kundenmenü vielleicht zwischen PHP 8.2 und 8.3 wählen. Welche Unterversion dahintersteckt und ob sie gepatcht ist, entscheidet allein der Hoster.

Deshalb gab es in dieser Woche drei Sorten Websites:

• Websites bei großen Massenhostern. Anbieter wie IONOS haben laut Tagesschau die PHP-Versionen in ihren Systemen zentral aktualisiert. Wer dort ein Standardpaket mit automatischen Updates hat, war nach wenigen Stunden geschützt, ohne es zu merken.
• Websites auf eigenen oder gemieteten Servern. Hier muss jemand das Update von Hand einspielen und die PHP-Prozesse neu starten. Das sind die Fälle, in denen Städte und Kliniken ihre Seiten lieber vom Netz nahmen, bis die Administratoren damit durch waren. Nicht aus Panik, sondern weil nachts um elf niemand mehr im Haus war, der es hätte tun können.
• Websites, bei denen niemand zuständig ist. Der Server wurde vor Jahren von einer Agentur eingerichtet, die es nicht mehr gibt. Oder das Paket beim Billighoster läuft noch auf PHP 7.4, weil das nie jemand umgestellt hat. Diese Websites sind heute verwundbar und bleiben es, bis sich jemand kümmert. Für Angreifer sind sie die leichteste Beute, weil ihre Werkzeuge das Netz automatisch nach genau solchen Versionen absuchen.

Sie können als Betreiber in dieser Situation nur eines tun: nachfragen. Und Sie sollten das tun, heute, nicht nächste Woche.

Was in dieser Nacht auf unseren Servern passiert ist

Wir hosten Kundenwebsites auf eigenen Servern in Deutschland, verwaltet über Plesk. Wir legen offen, wie die Nacht bei uns gelaufen ist, weil genau das die Frage ist, die Sie jedem Hoster stellen sollten.

• 21. Oktober, Vormittag. Plesk baut die korrigierten PHP-Pakete für alle vier Zweige, die auf unseren Servern laufen: 8.2, 8.3, 8.4 und 8.5. Das geschieht noch am selben Tag, an dem das PHP-Projekt die Korrektur veröffentlicht.
• 22. Oktober, 02:12 Uhr. Die tägliche Serversicherung läuft wie jede Nacht durch. Falls später etwas schiefgeht, gibt es einen Stand von vor dem Update.
• 22. Oktober, 06:13 bis 06:32 Uhr. Die automatische Sicherheitsaktualisierung installiert die neuen PHP-Pakete und das zugehörige Plesk-Update. Um 06:32 Uhr starten alle vier PHP-Dienste neu. Dieser Neustart ist wichtig: Ein Update auf der Festplatte schützt nicht, solange die alten Prozesse im Speicher weiterlaufen.
• 22. Oktober, 08:35 bis 08:47 Uhr. Prüfung von Hand. Alle 119 aktiven Website-Konfigurationen auf dem Server laufen auf den gepatchten Versionen. Acht öffentliche Websites werden von außen stichprobenartig abgerufen, alle antworten mit der neuen PHP-Version im Header. In den Fehlerprotokollen der letzten drei Tage finden sich keine Spuren eines Angriffs. Daneben finden sich fünf alte PHP-Prozesse, drei interne Testserver und zwei Cronjobs, die noch mit dem alten Stand im Speicher liefen. Keiner davon war von außen erreichbar.
• 22. Oktober, 09:04 Uhr. Die fünf Altprozesse werden beendet. Danach eine zweite Stichprobe: Alle geprüften Websites antworten normal.

Keine einzige Kundenwebsite war in dieser Zeit offline. Die meisten Kunden haben von der Lücke aus den Nachrichten erfahren und nicht von uns, weil es für sie nichts zu tun gab. Das ist der Zustand, den Managed Hosting herstellen soll.

Ehrlich bleibt dabei: Zwischen dem Leak am Dienstag und unserem Update am Donnerstagmorgen lagen rund anderthalb Tage, in denen die alten Versionen liefen. Wir haben in diesem Fenster keine Angriffsspuren gefunden. Eine Logprüfung ist aber keine forensische Untersuchung, und wer das Gegenteil behauptet, verspricht zu viel. Genau deshalb halten wir die Sicherungen vor diesem Zeitraum vor.

Woran Sie einen Hoster erkennen, der so etwas abfängt

Die Nacht hat gezeigt, welche Eigenschaften eines Hostings im Ernstfall zählen. Keine davon steht auf dem Preisschild.

Sicherheitsupdates laufen automatisch, auch nachts

Der Patch kam an einem Mittwochnachmittag heraus. Bei uns war er am Donnerstagmorgen um halb sieben installiert, ohne dass jemand aufstehen musste. Ein Hoster, bei dem Updates auf die nächste Wartung warten, verliert in so einer Lage Tage. Und Tage sind hier zu viel.

Es laufen nur PHP-Zweige, die noch gewartet werden

Auf unseren Servern läuft nichts unter PHP 8.2. Das ist kein Zufall, sondern eine Regel: Sobald ein Zweig aus der Wartung fällt, ziehen wir die Websites auf den nächsten um. PHP 8.2 erreicht am 31. Dezember 2026 sein Supportende, die betroffenen Websites stehen bereits auf der Liste. Wer Ihnen heute noch PHP 7.4 anbietet, hat diese Woche keine Lösung für Sie gehabt.

Nach dem Update wird neu gestartet und nachgeprüft

Das Update installieren ist die halbe Arbeit. Die Prozesse müssen neu starten, und danach muss jemand nachsehen, ob wirklich alles auf dem neuen Stand läuft. Unsere Prüfung hat fünf Altprozesse gefunden, die das automatische Update nicht erwischt hatte. Ohne Nachprüfung wären sie weitergelaufen.

Vor dem Update gibt es eine Sicherung

Tägliche Backups sind in unseren Paketen Standard, und in dieser Nacht lief die Sicherung vier Stunden vor dem Update. Wenn ein Patch eine Anwendung bricht, was vorkommt, ist der Weg zurück kurz.

Angreifer werden schon vor der Tür gebremst

Automatisierte Scanner suchen das Netz nach verwundbaren Versionen ab und schicken Hunderte Anfragen pro Minute. Auf unseren Servern sperrt eine Einbruchssperre solche Adressen nach einer Serie fehlgeschlagener Zugriffe für eine Stunde, Wiederholungstäter länger. Das ersetzt keinen Patch, wie gesagt. Aber es macht einen Server für Massenangriffe uninteressant.

Jemand sagt Ihnen, was passiert ist

Der Unterschied zwischen einem Hoster und einem Vermieter von Speicherplatz zeigt sich daran, ob Sie nach so einer Woche einen Bericht bekommen. Unsere Betreuungskunden erhalten einen monatlichen Wartungsbericht, in dem solche Vorfälle mit Zeitpunkt und Maßnahme stehen. Dieser Artikel ist die öffentliche Version davon.

Sechs Fragen an Ihren Hoster

Wenn Sie nicht sicher sind, wie Ihr Hosting diese Woche überstanden hat, schreiben Sie eine kurze Mail an Ihren Anbieter. Diese sechs Fragen reichen:

1. Auf welcher PHP-Version läuft meine Website heute, mit vollständiger Versionsnummer?
2. Wann wurden die Updates gegen CVE-2026-109618 und CVE-2026-109619 installiert?
3. Wurden die PHP-Prozesse danach neu gestartet?
4. Werden PHP-Versionen angeboten, die keine Sicherheitsupdates mehr bekommen, und läuft meine Website auf einer davon?
5. Gibt es eine Sicherung vom Stand vor dem Update, und wie lange wird sie aufbewahrt?
6. Wurden die Protokolle auf Angriffsspuren geprüft?

Ein guter Hoster beantwortet das innerhalb eines Tages, mit Zahlen. Ein Hoster, der ausweicht, allgemein von „höchsten Sicherheitsstandards“ spricht oder gar nicht antwortet, hat Ihnen damit auch eine Antwort gegeben.

Was jetzt noch zu tun bleibt

Die Welle ist nicht vorbei. Angreifer scannen das Netz in den kommenden Wochen nach allem, was noch verwundbar ist, und sie werden fündig, weil viele Websites niemanden haben, der sich kümmert. Drei Dinge gehören deshalb auf Ihre Liste:

Erstens: Klären Sie die PHP-Version Ihrer Website, mit den Fragen oben. Wenn die Antwort „7.4“ oder „8.1“ lautet, ist ein Umzug oder ein Versionswechsel keine Frage des Komforts mehr, sondern überfällig.

Zweitens: Verwechseln Sie PHP-Updates nicht mit Updates Ihrer Website. WordPress, Plugins und Themes haben eigene Lücken, und die werden durch den PHP-Patch nicht geschlossen. Beides muss gepflegt werden, auf verschiedenen Ebenen, oft von verschiedenen Leuten. Wer beides aus einer Hand hat, spart sich die Frage, wer gerade zuständig ist.

Drittens: Wenn Ihre Website in den letzten Tagen plötzlich langsamer wurde, unbekannte Dateien auftauchen oder Besucher auf fremde Seiten umgeleitet werden, warten Sie nicht ab. Das sind die typischen Zeichen einer übernommenen Website. Für diesen Fall gibt es unsere Notfallhilfe, bei der wir Spuren sichern, den Angreifer aussperren und die Lücke schließen.