PHP2Shell: Der Abend, an dem ein Update zum Krimi wurde
Zwei kritische PHP-Lücken, ein Update unter Zeitdruck und eine Cloud, die ausgerechnet an diesem Abend nicht wie geplant mitspielen wollte. So lief unser Sicherheitsabend.
19:47 Uhr. Eigentlich wäre jetzt ein guter Zeitpunkt für Feierabend. Stattdessen starre ich auf einen Server und warte darauf, dass unsere Cloud wieder sauber startet. Der Grund: An diesem Tag wurden zwei kritische Sicherheitslücken in PHP veröffentlicht. PHP ist ein wichtiger Baustein hinter sehr vielen Websites. Wenn dort etwas schiefläuft, wird aus «ich mache noch schnell ein Update» ziemlich schnell «bitte jetzt nichts anfassen».
Ein paar Stunden vorher war noch alles ruhig. Dann begann ein kleiner Wettlauf gegen die Zeit. Ohne Blaulicht, ohne Verfolgungsjagd, aber mit erstaunlich viel Kaffee und deutlich weniger Gelassenheit.
Was ist PHP überhaupt?
Stell dir eine Website wie ein Restaurant vor. Vorne sieht der Gast die Speisekarte und das fertige Essen. Hinten arbeitet die Küche. PHP ist vereinfacht gesagt ein Teil dieser Küche. Es verarbeitet Anfragen, holt Daten und baut daraus die Seite, die am Ende im Browser erscheint.
Die neuen Schwachstellen waren deshalb unangenehm, weil ein Angreifer unter bestimmten Bedingungen schon in der Küche stehen konnte, noch bevor WordPress oder ein Login überhaupt fragen konnten: «Moment, wer bist du eigentlich?» Genau das macht so eine Lücke ernst.
Am Morgen kommt die Warnung
Die Meldung lautet sinngemäss: Zwei neue PHP-Lücken, beide kritisch bewertet, Angriffe ohne Anmeldung möglich. Die Empfehlung ist einfach: sofort aktualisieren. Das ist ungefähr dieselbe Art Meldung wie «Die Haustürschlösser eines bestimmten Modells lassen sich mit einem Draht öffnen.» Dann diskutiert man nicht lange über die Farbe der Fassade.
18:30 Uhr: Erst schauen, dann schrauben
Zuerst prüfen wir, welche Systeme betroffen sein könnten und ob es Hinweise auf einen Angriff gibt. Auf den ersten Blick finden wir nichts Verdächtiges. Trotzdem ist klar: Nur weil niemand im Wohnzimmer steht, lässt man die kaputte Haustür nicht bis morgen offen.
19:00 Uhr: Die Websites sind durch
Die WordPress-Websites und der LernHub laufen auf der gepatchten PHP-Version. Dienste neu gestartet, Seiten kontrolliert, alles antwortet sauber. Für einen kurzen Moment sieht es so aus, als wäre der Abend gerettet.
19:15 Uhr: Dann steht plötzlich die ganze Welt in derselben Warteschlange
Bei unserer Cloud ist das Update komplizierter. Sie braucht für den Neubau mehrere zusätzliche PHP-Bausteine aus einer zentralen Bibliothek. Genau diese Bibliothek ist an diesem Abend praktisch nicht erreichbar. Nicht wegen eines geheimnisvollen Angriffs, sondern weil offenbar sehr viele gleichzeitig ihre Systeme aktualisieren wollen. Die Infrastruktur ist schlicht überlastet.
Das erinnerte mich an den Ticketverkauf für Robin Williams damals: Nichts ging mehr. Diesmal ging es nur nicht um Konzertkarten, sondern um Sicherheitsupdates für Server.
Unsere Cloud ist eine versiegelte Software-Kiste
Unsere Nextcloud läuft in einem sogenannten Container. Für Nicht-IT-Leute ist die einfachste Vorstellung eine fertig gepackte Software-Kiste. In dieser Kiste steckt nicht nur Nextcloud, sondern auch ihr eigenes PHP und weitere Bausteine. Das ist praktisch und sicher, weil diese Kiste vom restlichen Server getrennt ist.
Der Haken an diesem Abend: Man kann in dieser Kiste PHP nicht einfach wie eine einzelne App aktualisieren. Normalerweise liefert der Hersteller eine neue, fertig gebaute Kiste. Alte raus, neue rein, fertig. Nur gab es genau diese neue Kiste noch nicht, weil für ihren Bau dieselbe überlastete Infrastruktur gebraucht wurde.
Die Versuchung: irgendwo schnell Ersatzteile besorgen
Theoretisch hätten wir die fehlenden Zusatzbausteine auch aus anderen Quellen holen können. Genau das wollten wir aber nicht.
Wenn dein Auto wegen fehlerhafter Bremsen zurückgerufen wird, montierst du ja auch nicht einfach die billigsten Bremsen aus einer unbekannten Quelle. Genau so haben wir es hier gehalten: In einer Sicherheitslage kommen nur Teile hinein, deren Herkunft wir nachvollziehen können.
19:47 Uhr: Die neue Kiste entsteht aus lauter bekannten Teilen
Die Lösung war eigentlich erstaunlich simpel. Wir bauen die Cloud-Kiste selbst, aber nur mit Dingen, denen wir bereits vertrauen: mit dem offiziellen Bauplan von Nextcloud, mit einem bereits reparierten offiziellen PHP-Grundbaustein und mit den Zusatzbausteinen aus unserer bisherigen, funktionierenden Cloud-Kiste.
KI-Illustration: Ein reparierter PHP-Kern, ergänzt durch bekannte Bausteine und anschliessend geprüft.
Der entscheidende Gedanke war: Die Sicherheitslücke steckte im PHP-Kern, nicht in diesen Zusatzbausteinen. Also tauschten wir genau den betroffenen Kern aus und liessen die bewährten Zusatzteile unangetastet. Ein bisschen wie beim Ölwechsel: neues Öl hinein, aber niemand zerlegt deshalb das ganze Getriebe.
Bevor die neue Kiste live ging, musste sie durch die Kontrolle
Zuerst prüfen wir die PHP-Version und ob alle benötigten Erweiterungen sauber laden. Danach sichern wir die Cloud-Datenbank. Erst dann wird umgestellt. Anschliessend prüft Nextcloud sich selbst, wir kontrollieren die Erreichbarkeit von aussen und richten zusätzlich eine Überwachung ein, damit wir merken, sobald wieder ein offizielles Hersteller-Image verfügbar ist.
Und jetzt kommt der Teil, den ich alleine nicht geschafft hätte
Die Idee klingt im Nachhinein logisch. In diesem Moment hätte ich sie aber nicht alleine sauber umgesetzt. Die Analyse, welche Teile wir gefahrlos übernehmen können, wie wir die neue Kiste bauen und welche Prüfungen danach nötig sind, entstand in Zusammenarbeit mit KI.
Für mich ist genau das der spannende Teil: Die KI hat nicht einfach irgendeinen Befehl ausgespuckt. Wir haben gemeinsam Schritt für Schritt geprüft, welche Quelle vertrauenswürdig ist, was verändert werden muss und was auf keinen Fall aus einer unbekannten Quelle kommen darf. Ich habe die Entscheidungen getroffen, die KI hat mir geholfen, die technische Lösung zu bauen und zu kontrollieren.
20:00 Uhr: Ruhe im Maschinenraum
Die Systeme laufen. Die Websites antworten. Die Cloud arbeitet mit dem reparierten PHP. Danach folgt die weniger spektakuläre, aber wichtige Arbeit: prüfen, vergleichen, Sicherungen kontrollieren und nach Spuren suchen. Ergebnis: kein Hinweis auf eine erfolgreiche Kompromittierung.
Warum mich dieser Abend mehr freut als jedes schöne Dashboard
Der spannende Teil war nicht, dass wir an diesem Abend schnell tippen konnten. Der spannende Teil war, dass vorher schon bekannt war, welche Systeme wo laufen, wie sie gebaut sind und wie man sie kontrolliert. Genau diese Dinge wirken im Alltag langweilig. Backups. Überwachung. Dokumentation. Updates. Bis zu dem Tag, an dem man sie wirklich braucht.
Gute IT ist ein bisschen wie eine gute Hausversicherung: Solange nichts passiert, fragt man sich, warum man dafür Geld ausgibt. Wenn es kracht, ist man plötzlich erstaunlich dankbar, dass sie schon vorher da war.
Mein Fazit
Für mich war PHP2Shell kein Actionfilm über Hacker. Es war eher ein Krimi über Vorbereitung und Zusammenarbeit. Die eigentliche Leistung bestand nicht darin, an diesem Abend hektisch irgendetwas zu reparieren. Sie bestand darin, dass die Systeme schon vorher so aufgebaut waren, dass wir reagieren konnten. Und ganz klar: Die technische Sonderlösung für die Cloud hätte ich alleine nicht gebaut. Genau hier hat mir KI geholfen, aus einem Problem Schritt für Schritt eine überprüfbare Lösung zu machen.
FENTRAX
Wie dieser Beitrag entstand
Grundlage dieses Beitrags sind die eigenen Server- und Build-Logs vom 21. Oktober 2026 sowie die dokumentierte interne Incident-Timeline. Die technische Sonderlösung für die Cloud wurde gemeinsam mit KI entwickelt, geprüft und umgesetzt. Die öffentliche Einordnung der Schwachstellen wurde mit den PHP-Sicherheitsmeldungen, NCSC-NL und aktuellen Sicherheitsberichten abgeglichen.
