Die Lücke war für alle gleich. Die Ausfallzeit nicht!

Was PHP2Shell über die Notfallplanung von Websites verraten hat: Manche Seiten waren fast einen Tag offline, andere kaum. Was den Unterschied macht – und was Sie daraus lernen können.

Sicherheit, Webentwicklung | 27. Oktober 2026 | Lesezeit 9 Minuten | von Michael Ziegler

Illustration: Links ein Rathaus mit vernagelten Fenstern und Türen, rechts ein geöffneter Onlineshop mit Waren in der Auslage. Auf dem Weg davor rennt ein grinsendes Virus mit der Aufschrift „PHP2Shell“.

Am 21. Oktober 2026 hat das PHP-Projekt zwei kritische Sicherheitslücken geschlossen, die unter dem Namen „PHP2Shell“ bekannt wurden (CVE-2026-109618 und CVE-2026-109619). Über sie konnten Angreifer ohne Anmeldung eigenen Code auf dem Server ausführen – auf praktisch jedem Server, der Websites mit PHP ausliefert. Das betrifft WordPress, TYPO3, Drupal, Shopware, WooCommerce und viele Content-Management-Systeme von Behörden.

Die Lücke war für alle gleich. Die Folgen nicht: Manche Websites waren fast einen ganzen Tag nicht erreichbar, andere nur kurz oder gar nicht. Den Unterschied hat nicht die Technik gemacht, sondern die Vorbereitung.

Der Ablauf am 21. Oktober

Bereits vorher hatten PHP-Projekt und BSI eine kritische Aktualisierung angekündigt; viele Betreiber wussten also, dass etwas kommt.
Ab 5 Uhr morgens filterte Cloudflare Angriffsversuche für alle Kunden heraus, auch im kostenlosen Tarif (Cloudflare).
Gegen 15:30 Uhr erschienen die korrigierten PHP-Versionen 8.2.35, 8.3.36, 8.4.27 und 8.5.12 (Zeitachse bei Mallory).
Am Nachmittag und frühen Abend folgten die Updates für die gängigen Linux-Distributionen, etwa Ubuntu und SUSE.

Wer offline war – und wer nicht

Die Liste der abgeschalteten Websites liest sich wie ein Verzeichnis öffentlicher Einrichtungen. Bundes- und Landesportale, Polizeiseiten, Kliniken, Schulplattformen und Stadtverwaltungen in ganz Europa gingen vorsorglich vom Netz (Übersicht bei Command Eleven, Newsweek). Auch einzelne Unternehmen und Plattformen waren betroffen. Online-Shops und Nachrichtenseiten, die genauso auf PHP laufen, blieben dagegen weitgehend erreichbar.

Wir haben am Morgen danach, am 22. Oktober um 9 Uhr, die Websites aller 82 deutschen Großstädte aufgerufen. 10 von 82 waren nicht normal erreichbar. Acht davon – Cottbus, Dresden, Freiburg, Gütersloh, Hagen, Heidelberg, Mainz und Rostock – zeigten gar nichts, nicht einmal einen Hinweis. Mülheim an der Ruhr und Münster zeigten immerhin eine Hinweis- bzw. Wartungsseite.

Das ist mehr als ein Schönheitsfehler. Die Tech-Beraterin und eco-Vorständin Silke Kanes hat es erst in der vergangenen Woche im Human Firewall Podcast von SoSafe auf den Punkt gebracht: Wer bei einem Online-Shop ein schlechtes Gefühl hat, kauft seine Schuhe eben woanders und zahlt vielleicht fünf Euro mehr. Bei der Stadt geht das nicht: „Ich habe als Bürger aber keine Wahl. Ich muss die Daten dort abgeben.“ Eine Verwaltung, deren Website ohne Erklärung verschwindet, verspielt genau das Vertrauen, auf das sie angewiesen ist.

Unsere Meinung: Wer seine Website braucht, damit das eigene Geschäft läuft, hat sie an diesem Tag auch am Laufen gehalten. Viele öffentliche Stellen dagegen haben offenbar darauf gesetzt, dass ein Tag ohne Website schon verkraftbar ist. Das darf nicht sein. Dass Bürgerinnen und Bürger überhaupt noch ins Rathaus oder Landratsamt müssen, statt nur für eine Beratung freiwillig hinzugehen, liegt daran, dass Deutschland seine Verwaltungsprozesse noch immer nicht digitalisiert hat. In einer digitalen Verwaltung ist die Website mit ihren Online-Diensten das eigentliche Rathaus – und damit weit wichtiger als ein Schalter, der ein paar Stunden am Tag öffnet.

Beispiel Mainz: 20 Stunden ohne Website

Wir sitzen in Mainz, deshalb haben wir unsere eigene Stadt genauer verfolgt. Gegen 14 Uhr am 21. Oktober meldete die Stadt auf Instagram, dass sie ihre Website abgeschaltet hat – vorsorglich, noch bevor die korrigierten PHP-Versionen überhaupt erschienen waren. Bürgerbüros und Ämter blieben per Telefon und E-Mail erreichbar (Merkurist).

So weit ist das vertretbar. Wer nicht weiß, ob seine Server angreifbar sind, darf sie vom Netz nehmen. Doch dann geschah lange nichts:

Die Updates für aktuelle Serversysteme lagen spätestens ab dem frühen Abend bereit – bei manchen Anbietern sogar schon vor dem offiziell angekündigten Termin um 16 Uhr.
Die Website blieb trotzdem die ganze Nacht offline – ohne Hinweisseite. Wer mainz.de aufrief, bekam einen Fehler angezeigt.
Erst am 22. Oktober um 10:23 Uhr war mainz.de wieder erreichbar.

Macht gut 20 Stunden ohne die zentrale Anlaufstelle der Landeshauptstadt. Das lag nicht an fehlenden Updates, sondern an fehlenden Abläufen: Offenbar konnte oder durfte nach Feierabend niemand die Updates einspielen, und für den Notbetrieb lag nichts bereit. Mainz steht damit nicht allein, wie die acht Städte ohne jeden Hinweis zeigen. Doch mit eingespielten Abläufen wären aus 20 Stunden wenige geworden.

Was gute Vorbereitung ausmacht

Die Betreiber, die gut durch den Tag kamen, hatten keine bessere Technik. Sie hatten einen Plan. Vier Dinge machen den Unterschied:

Gepatcht wird, sobald der Patch da ist. Eine kritische Lücke richtet sich nicht nach Bürozeiten. PHP2Shell war vorab angekündigt. Wer die Warnung ernst genommen hat, konnte sofort Zuständigkeiten klären, Server und Abläufe vorbereiten und dann nur noch auf das Update warten. Die korrigierten Versionen kamen am Nachmittag, die Updates der Distributionen spätestens am frühen Abend. Dafür braucht es Admins, die solche Warnungen selbst im Blick haben und ohne Freigabe aus Verwaltung oder Geschäftsleitung handeln dürfen. Und die klare Regel: Feierabend ist erst, wenn mindestens die öffentliche Website gepatcht ist. Wer bis zum nächsten Arbeitsbeginn wartet, verliert eine ganze Nacht.
Die Zeit bis zum Update wird überbrückt, nicht ausgesessen. Gut vorbereitete Betreiber haben schon am Vormittag die angreifbare PHP-Funktion abgeschaltet und zusätzliche Filterregeln aktiviert. Cloudflare und AWS haben Angriffe vor der Website abgefangen (AWS). Vergleichbare Dienste gibt es auch von deutschen und europäischen Anbietern. Wer eigene Server betreibt, kann solche Regeln außerdem selbst auf dem Webserver einrichten. Diese Filter ersetzen das Update nicht, sie verschaffen aber Stunden.
Nur abschalten, was gefährdet ist. Koblenz hat seine Website online gelassen oder schnell wieder livegeschaltet und nur einzelne Online-Dienste vorsorglich abgeschaltet.
Eine Notseite liegt bereit. Muss die Website doch vom Netz, gibt es eine statische Seite im eigenen Design: was passiert ist, wie man die Verwaltung oder das Unternehmen erreicht, wann es weitergeht. So eine Seite ist in einer Stunde gebaut – wenn man es vorher tut.

Silke Kanes fordert im Podcast, solche Lagen regelmäßig zu proben, ähnlich wie den Sirenenalarm: „Die Angriffe werden kommen. Ich kann es nicht verhindern. Jedes System, was ich mir vornehme, ist letztlich angreifbar. Also muss ich es auch üben.“ PHP2Shell war so eine Übung – nur unangekündigt.

Wie es bei uns lief

Wir entwickeln Websites und Webprojekte für unsere Kunden und betreiben viele davon auch auf unseren eigenen Servern. Am 21. Oktober haben wir die betroffenen Websites gegen 16 Uhr vorsorglich vom Netz genommen, die Updates eingespielt und geprüft. Gegen 18 Uhr waren alle Server aktualisiert und alle Websites wieder online. Die Ausfallzeit lag bei anderthalb bis zwei Stunden – am Nachmittag, nicht über Nacht.

Das ist weder besonders schnell noch eine besondere Leistung. Wir sind eine kleine Firma, und trotzdem waren alle Server nach zwei Stunden gepatcht. Deshalb stellt sich die Frage: Warum können wir, was Mainz nicht kann? Wie kann es sein, dass eine Großstadt mit eigener IT-Abteilung mehr als 20 Stunden braucht?

Darauf ruhen wir uns nicht aus. Wir bauen unsere Überwachung laufend aus, damit wir Probleme bemerken, bevor unsere Kunden es tun. Und wir automatisieren Updates Schritt für Schritt, damit Sicherheitskorrekturen schnell und zuverlässig auf allen Servern ankommen. Davon profitieren alle Websites, die wir betreuen, ohne dass unsere Kunden selbst etwas tun müssen.

Sie möchten wissen, wie gut Ihre Website auf den nächsten Ernstfall vorbereitet ist? Sprechen Sie uns an – wir schauen es uns gemeinsam an.

Wir prüfen Ihre Vorbereitung