PHP2Shell: Warum wir über 100’000 Websites vom Netz genommen haben

Wegen zweier kritischer Sicherheitslücken in PHP haben wir am 21. Oktober alle Webserver vorübergehend abgeschaltet. Hier erklären wir, warum wir so entschieden haben und weshalb es bis in die frühen Morgenstunden dauerte.

Am Mittwoch, 21. Oktober 2026, um 15:45 Uhr haben wir alle Webhostings, Managed Server und Agencyserver vom Netz genommen, insgesamt über 100’000 Websites. Am Donnerstag um 04:00 Uhr waren alle Websites wieder online, mit den Korrekturen auf sämtlichen Servern. Nach heutigem Stand gibt es keine Hinweise auf erfolgreiche Angriffe bei unserer Kundschaft.

Was ist PHP2Shell?

PHP ist die Programmiersprache, mit der weltweit ein grosser Teil aller Websites läuft, vom Vereins-Blog bis zum Online-Shop. Am 20. Oktober kündigte das PHP-Projekt dringende Sicherheitsupdates für den Folgetag um 16:00 Uhr an.

Es ging um zwei kritische Lücken, bekannt als «PHP2Shell». Über sie konnten Angreifer ohne Passwort fremden Code auf einem Server ausführen und Websites komplett übernehmen. Die Lücken steckten nicht in einer einzelnen Website oder einem Plugin, sondern in PHP selbst. Betroffen war deshalb jede PHP-Installation weltweit.

Hinzu kam, dass Details zu den Lücken vorzeitig durchsickerten. Sicherheitsfirmen meldeten weltweit erste Angriffsversuche, noch bevor Korrekturen verfügbar waren.

Warum wir abgeschaltet haben

Am Ende ging es um eine Abwägung: einige Stunden offline gegen das Risiko gehackter Websites. Ein Unterbruch schadet, aber er endet, sobald die Server wieder laufen. Eine übernommene Website dagegen kann abgeflossene Kundendaten, Meldepflichten nach Datenschutzgesetz, Schadsoftware für Besucherinnen und Besucher und eine Sperrung durch Google bedeuten. Ein Schaden, der sich über Wochen hinzieht.

Weil die Lücken jede PHP-Installation betrafen und sich Angriffe nicht zuverlässig abblocken liessen, war kein Server sicher. Die Massnahme war drastisch, aber in derselben Lage würden wir wieder so entscheiden.

Das CERT-EU und das britische NCSC rieten, betroffene Systeme vom Netz zu nehmen oder zu isolieren, solange sie sich nicht aktualisieren lassen. Weltweit haben Regierungsportale, Universitäten und Spitäler so gehandelt, in der Schweiz etwa die Universität Genf, die EPFL und Websites des Kantons Basel-Stadt.

Unser E-Mail-Dienst lief durchgehend weiter. Nicht erreichbar waren neben den Websites der Sitebuilder, my.cyon und das Webmail.

Warum es bis 4 Uhr morgens dauerte

Die Korrekturen des PHP-Projekts lagen am späteren Nachmittag vor. Dass es trotzdem bis in die Nacht dauerte, hat mit einer bewussten Entscheidung zu tun: Wir wollten alle Websites schützen, auch jene auf älteren PHP-Versionen.

Neben den aktuellen Versionen bieten wir auch PHP 7.4, 8.0 und 8.1 an. Diese werden vom PHP-Projekt eigentlich nicht mehr gepflegt. Wegen der Schwere der Lücken hat es zwar Korrekturen im Quellcode bereitgestellt, aber keine fertigen, installierbaren Versionen. Bei uns laufen noch Zehntausende Websites auf einer dieser Versionen. Wie verbreitet ältere PHP-Versionen weltweit sind, zeigt das Live-Dashboard von Censys.

Fertige Pakete für alle Versionen erhalten wir von CloudLinux. Unsere Server laufen mit diesem auf Webhosting spezialisierten Betriebssystem. CloudLinux liefert eigene, geprüfte PHP-Pakete und pflegt auch ältere Versionen weiter, die das PHP-Projekt längst nicht mehr unterstützt. Deshalb setzen wir für alle PHP-Versionen auf diese Pakete, auch für die aktuellen. Im Normalfall ist das ein grosser Vorteil. Die geprüften Pakete kamen später als angekündigt, das hat einige zusätzliche Stunden gekostet.

Unsere Zeitangaben haben wir laufend auf der Statusseite angepasst, wo wir während des ganzen Unterbruchs informiert haben. Zusätzlich haben wir dich bei der Abschaltung und nach der Wiederaufschaltung per E-Mail benachrichtigt.

Auf Behelfslösungen haben wir bewusst verzichtet:

«Im Vorfeld kursierten verschiedene Behelfslösungen, etwa angepasste PHP-Einstellungen oder Firewall-Regeln. Auch die vom PHP-Projekt empfohlenen Einstellungen schlossen aber nur einzelne Angriffswege. Das PHP-Projekt hielt selbst fest, dass nur die Korrekturen zuverlässig schützen.

Wir wollten die Websites unserer Kundschaft nicht mit einer Massnahme wieder aufschalten, von der wir nicht wussten, ob sie hält. Da haben wir lieber einige Stunden länger auf die geprüften Pakete gewartet», sagt Andreas Wili, Lead Service Operations bei cyon.

Was wir aus dem Vorfall mitnehmen

Als sich das Ausmass der Lücken abzeichnete, haben Mitarbeitende aus Engineering, Operations, Support und Kommunikation gemeinsam die Risiken beurteilt, die Abschaltung koordiniert, die Kundschaft informiert und die Wiederaufschaltung vorbereitet. Viele haben bis in die frühen Morgenstunden gearbeitet. Unsere Abläufe für solche Fälle haben funktioniert.

Der Vorfall hat aber auch gezeigt, wie wenig Zeit bei kritischen Lücken bleibt. Mit KI lassen sich bekannte Lücken heute in Stunden statt Tagen ausnutzen. Und wenn wie diesmal Korrekturen von Lieferanten später kommen als angekündigt, verlieren wir Zeit, die wir nicht selbst in der Hand haben.

Wir werten deshalb aus, wo wir beim nächsten Mal schneller und unabhängiger reagieren können.

Und deine Website?

Für die Sicherheitslücken musst du nichts tun: Die Korrekturen sind auf allen Servern installiert, auch bei älteren PHP-Versionen.

Für PHP 7.4 bis 8.1 hat das PHP-Projekt diesmal wegen der Schwere der Lücken eine Ausnahme gemacht. Darauf verlassen kann man sich bei künftigen Lücken nicht. Wenn du deine Website ohnehin auf den neusten Stand bringst, lohnt sich deshalb auch der Wechsel auf eine aktuelle PHP-Version. Standard bei cyon ist PHP 8.3. Was diese Version mitbringt und worauf du beim Wechsel achten solltest, zeigen wir in einem separaten Beitrag.

Ein persönliches Wort zum Schluss

Wir wissen, was ein solcher Unterbruch bedeuten kann. Je nach Website fehlten Bestellungen und Anfragen, Werbung lief ins Leere, oder wichtige Informationen waren genau dann nicht erreichbar, als jemand sie brauchte. Agenturen mussten ihrer eigenen Kundschaft Rede und Antwort stehen.

In über 20 Jahren cyon habe ich diesen Entscheid noch nie treffen müssen. Diesmal war er nötig. Leicht gefallen ist er mir trotzdem nicht.

Danke für deine Geduld. Und danke allen bei cyon, die bis tief in die Nacht daran gearbeitet haben, die Websites wieder sicher online zu bringen.

David Burkardt, CEO von cyon

Hast du Fragen zum Vorfall? Schreib sie in die Kommentare. Bei Fragen zu deiner Website ist unser Support gern für dich da.