Letzte Woche hat eine kritische Sicherheitslücke in PHP das Web auf Trab gehalten und Teile davon lahmgelegt. Aber was ist eigentlich passiert? Und wieso interessiert sich plötzlich alle Welt für die Software-Updates auf deinem Server? Ein Versuch, die Situation zusammenzufassen.
Was ist am letzten Mittwoch eigentlich passiert?
Sicherheitslücken in Software sind grundsätzlich etwas Alltägliches. Sie sind der Grund, warum du dein Smartphone und deinen Computer genauso wie die eingesetzten Apps regelmässig aktualisieren solltest.
Wie kritisch eine Lücke ist, wird auf einer Skala von 0-10 (dem sogenannten Common Vulnerability Scoring System, kurz CVSS) eingestuft. Je höher die Zahl, desto schwerwiegender: ab 7 gilt der Schweregrad als «Hoch», ab 9 als «Kritisch». Die «php2shell» genannte Lücke, die am Mittwoch, dem 21. Oktober 2026, geschlossen wurde, erreichte einen Score von 9.2, wurde also als sehr kritisch eingeschätzt. Zudem betraf sie mit PHP eine Programmiersprache, die sehr weit verbreitet ist.
In diesem Fall bestand das Risiko einer sogenannten Remote Code Execution (RCE), was bedeutet, dass Angreifer von aussen auf einem Server fremden Code ausführen und diesen dadurch übernehmen könnten. Und dies ohne jegliche Authentifizierung oder Login. Also so ziemlich das schlimmste denkbare Szenario.
An den Patches, die diese Lücken nun geschlossen haben, wurde seit August im Geheimen gearbeitet und plangemäss hätten diese am Donnerstag, dem 22. Oktober 2026, veröffentlicht und anschliessend kommuniziert werden sollen, so wie es in solchen Fällen die Regel ist.
Als jedoch bereits ein paar Tage davor Informationen durchsickerten und teilweise sogar erste Angriffe registriert wurden, brach plötzlich Hektik aus und das Ganze musste am Dienstagabend kurzerhand angekündigt und am Mittwoch unter hohem Zeitdruck veröffentlicht werden, um weiteren Angriffen zuvorzukommen.
Am Mittwoch überschlugen sich deshalb die Neuigkeiten im Minutentakt. Zuerst nur in Fachmedien ein Thema, verbreitete sich die Nachricht schnell. Bald warnten auch CERT-EU, das Cybersecurity-Team der EU-Institutionen, und das schweizerische Bundesamt für Cybersicherheit (BACS) offiziell vor der Lücke. Weltweit wurden Dienste und Websites vorsorglich vom Netz genommen, darunter mehrere Regierungsseiten. Schliesslich richtete selbst die Premierministerin von Japan eine Warnung an die Bevölkerung. Und wenn die Politik anfängt, sich für deine Software-Updates zu interessieren, dann weisst du definitiv, dass es ernst ist.
Wie wurde die Schwachstelle entdeckt?
Vermutet wurde bereits seit längerem, dass eine Schwachstelle dieser Art möglich sein könnte. Bewiesen oder gefixt werden konnte dies allerdings bisher nicht. Nachgewiesen haben sie nun mehrere Cybersecurity-Research-Firmen, die im Sommer mithilfe verschiedener grosser KI-Modelle gezielt danach suchten. Die PHP Foundation hat den gesamten Ablauf von der Entdeckung bis zum Patch in einem lesenswerten Blogpost aufgearbeitet.
Welche Folgen hatte das Ganze für uns?
Wie alle, die irgendwie mit dem Web und insbesondere PHP zu tun haben, verfolgten wir die Lage und versuchten so viel wie möglich darüber herauszufinden. Wir tauschten uns morgens mit Kolleg:innen, Hostinganbietern und sonstigen Expert:innen aus und klärten ab, was wir unternehmen konnten. Spätestens am frühen Nachmittag, und mit jeder offiziellen Warnung und jedem Dienst, der vorsorglich vom Netz ging, wurde langsam klar, wie kritisch das Ganze war. Kurz bevor PHP dann die Patches veröffentlichte, entschied sich auch unser Hostinganbieter dazu, erstmal den Stecker zu ziehen und PHP zu deaktivieren, bis die Updates eingespielt werden konnten. Dies betraf leider neben unseren eigenen auch viele unserer Kundenseiten, die anschliessend komplett offline waren, bis die entsprechend angepassten Updates vom Hersteller der Serversoftware zur Verfügung standen. Eine Entscheidung, die auch dem CEO von cyon, David Burkardt, nicht leichtfiel. In seinen Worten ging es am Ende um eine Abwägung zwischen einigen Stunden Ausfall und dem Risiko gehackter Websites, ein potentieller Schaden, der sich danach über Wochen hätte hinziehen können. Wir sehen das gleich und stehen zu 100% hinter dieser Entscheidung.
Leider dauerte der Ausfall länger als erhofft und die Seiten waren erst nachts um 3:52 Uhr wieder online. In dieser Zeit konnten wir nur zusehen und abwarten, und gleichzeitig unsere Kund:innen über die Situation informieren, als klar wurde, dass es doch noch eine Weile länger dauern würde.
Hatte WordPress damit zu tun?
Nein. Die Lücke befand sich direkt in der Programmiersprache PHP und betraf daher alle Systeme, die in PHP programmiert sind, wie WordPress, Drupal, Joomla, Laravel, diverse Forensoftware und viele andere mehr.
WordPress hat als eines der am weitesten verbreiteten Systeme zwar alle Nutzer:innen über die Lücke informiert, konnte darüber hinaus aber selbst nichts unternehmen. Die Lücke konnte ausschliesslich über ein Update von PHP selbst geschlossen werden.
Welche Schlüsse ziehen wir daraus?
Als wir am Mittwochabend selbst aktiv nichts mehr unternehmen konnten, haben wir die Situation genutzt, um zu prüfen, wo unser Notfallplan gut funktionierte und wo dieser noch verbessert werden könnte. Folgende Punkte haben wir uns notiert:
- Interne Prozesse funktionierten zwar, sollten aber noch besser dokumentiert werden. Wer macht was? Ab wann werden alle Kunden informiert? Solche und ähnliche Fragen sollten vorab beantwortet sein und in einem Notfall nicht mehr diskutiert werden müssen.
- DNS- und Domain-Einstellungen konsequent extern auslagern, überall, wo dies noch nicht der Fall ist. So sind wir flexibler und könnten im Fall eines längeren Ausfalls kritische Seiten umziehen und auf anderer Infrastruktur schnell wieder online haben.
- Aussagekräftigere Maintenance-Seite als automatischer Fallback: in diesem spezifischen Fall war «nur» PHP das Problem. Eine einfache statische Wartungsseite wäre also theoretisch noch möglich und hilfreicher gewesen als eine Fehlermeldung im Browser.
- Static Pages: damit könnten Inhalte weiterhin in WordPress gepflegt werden, aber als Static Pages komplett ohne PHP ausgeliefert werden. Für viele einfachere Seiten könnte dies eine Option sein, die zudem Sicherheits- und Performance-Vorteile bringt. Damit wollten wir uns ohnehin intensiver befassen, und das ist ein guter Anlass, das Thema bald anzugehen.
- Abklären, inwiefern ein CDN-Dienst wie Cloudflare, als zwischengeschalteter Caching-Layer, im Notfall als Fallback dienen könnte.
- Schnellere Kommunikation: die erste Information an unsere Hosting- und Maintenance-Kund:innen ging erst um 19:48 Uhr raus, als die Seiten bereits fast 4 Stunden offline waren. Das sollte auch (oder gerade) in einer Ausnahmesituation wie dieser schneller gehen (siehe Punkt 1).
Fazit
Diese und diverse andere Sicherheitslücken, Leaks und bekanntgewordene Hacks der vergangenen Wochen und Monate zeigen, wie KI das Tempo beschleunigt und die Ausgangslage verändert hat.
Nicht nur werden heute mehr Fehler in kürzerer Zeit gefunden, man muss heute auch davon ausgehen, dass diese schneller und einfacher aktiv ausgenutzt werden können, was eine schnelle, verantwortungsvolle Reaktion und regelmässige Updates umso wichtiger macht.
Wir sind sehr beeindruckt von der Arbeit der PHP Foundation, allen beteiligten Entwickler:innen und Security-Expert:innen, die in dieser aussergewöhnlichen Situation einen super Job gemacht haben. Und, so schmerzhaft der lange Totalausfall auch war, es war auch schön zu sehen, wie die Web-Community und selbst sonst konkurrierende Firmen im Notfall zusammenarbeiten, um das Web wieder zumindest ein Stück sicherer zu machen.
Ein Dankeschön geht auch nach Basel zum Team von cyon und an alle anderen Hosting-Anbieter, die sich umgehend um die Patches gekümmert haben, sowie an Mario Rimann von der Ops One AG in Zürich, der uns am Mittwoch mit Rat zur Seite stand und diesen Beitrag fachlich gegengelesen hat.
Und nicht zuletzt danken wir allen unseren Kundinnen und Kunden für das Verständnis und die Geduld.
Falls du Fragen dazu hast, melde dich bei uns und wir beraten dich gerne persönlich.
In diesem Sinne – on to the next one.