Am 21. Oktober 2026 machte PHP zwei kritische Sicherheitslücken öffentlich, CVE-2026-109618 und CVE-2026-109619. Schweregrad 9.2 von 10, ausnutzbar über ganz normale Web-Requests. PHP ist die Sprache, in der WordPress und ein grosser Teil des Webs laufen. Betroffen waren alle PHP-Versionen.
Wir betreiben 41 Server mit 68 Web-Applikationen für unsere Kunden, die meisten davon WordPress. Drei Tage später lief jede einzelne davon auf einer gepatchten PHP-Version. Keine Site war offline, und ein elf Jahre altes Theme bekam seinen ersten Patch seit Jahren. Dieser Beitrag zeigt, wie das ging und was Sie daraus für Ihr eigenes Projekt mitnehmen können.
Der Hosting-Partner war schneller als der Fix
Dass die Woche glimpflich verlief, lag zuerst an RunCloud, unserem Hosting-Partner. Noch am Tag der Veröffentlichung sperrte RunCloud auf allen Servern den Weg, den der Angriff braucht, 14 Stunden bevor die gepatchten PHP-Versionen überhaupt verfügbar waren. Danach spielte RunCloud die Updates automatisch ein und schickte uns eine kurze Liste mit dem, was jeder Betreiber selbst prüfen muss.
| Zeitpunkt (MESZ) | Wer | Was |
|---|---|---|
| 21.10., 10:00 | RunCloud | Angriffsweg auf allen Servern gesperrt (session.upload_progress deaktiviert) |
| 22.10., 00:00 | RunCloud | Gepatchte Versionen PHP 8.2 bis 8.5 automatisch ausgerollt |
| 23.10., 11:04 | RunCloud | Fix für die älteren Versionen 7.4 bis 8.1 auf containerisierten Servern |
| 23.10., 23:30 bis 24.10., 00:40 | wir | Bestandsaufnahme aller Server und Apps, Patch-Stand überall bestätigt |
| 24.10., 00:30 bis 01:45 | wir | Elf veraltete Apps auf PHP 8.3 umgestellt, zwei davon mit Theme-Patch |
| 24.10., nachmittags | wir | Letzte App von PHP 5.6 auf 8.3 portiert |
Bestandsaufnahme: Wo ist CVE-2026-109618 noch offen?
Nach dem automatischen Update blieben vier Fragen: Waren alle Server während des Updates erreichbar? Ist das Betriebssystem neu genug? Ist der Patch wirklich überall installiert? Und läuft irgendwo noch eine App auf einer PHP-Version, für die es gar keinen Fix mehr gibt?
Bei 41 Servern klickt man das nicht im Dashboard durch. Wir haben die Antworten über die Programmierschnittstelle (API) von RunCloud abgefragt und mit einem kurzen Prüfskript auf jedem Server gegengecheckt. Die ersten drei Fragen waren damit rasch beantwortet: alle Server online, alle Betriebssysteme aktuell genug, der Patch überall installiert.
Offen blieb die vierte: Zwölf Apps liefen noch auf PHP 8.1 oder älter, einer Version ohne Fix. Jede davon musste auf eine neuere Version, sonst blieb sie angreifbar. Bis dahin gab es einen zweiten Zaun: Die meisten dieser Sites liefen bereits hinter Cloudflare, das verdächtige Anfragen abfängt, bevor sie die Website erreichen. Ein Schutz, aber kein Ersatz für den Patch.
Zwölf Apps umstellen, ohne dass jemand etwas merkt
Sechs der zwölf Apps waren WordPress-Sites. Vier stellten wir direkt um: PHP-Version wechseln, die wichtigsten Seiten aufrufen, fertig. Der Wechsel dauert Sekunden und lässt sich in Sekunden rückgängig machen.
Zwei Sites waren schwieriger. Beide nutzen dasselbe Theme von 2014, darunter die Website von Haus Moos, der man ihr Alter bis heute nicht ansieht. Ein früherer Versuch mit PHP 8 hatte mit einer weissen Seite geendet, und niemand wusste genau, warum. Diesmal liessen wir den gesamten Theme-Code automatisch nach Stellen durchsuchen, die mit neuem PHP nicht mehr funktionieren.
Gefunden haben wir gerade einmal fünf Stellen in vier Dateien. Die entscheidende war eine Zeile, die nie ausgeführt wurde. PHP 8 verweigerte trotzdem die ganze Datei, und damit jede Seite der Website. Fünf Zeilen Korrektur, Backup, Umstellung, danach 80 Seiten automatisch aufgerufen und das Fehlerprotokoll gelesen: kein einziger Fehler. Bei der zweiten Site genauso.
Die zwölfte App, eine Eigenentwicklung auf PHP 5.6, brauchte mehr als einen Versionswechsel: Sie musste portiert werden. Vor KI hätten wir dafür ein bis zwei Tage geschätzt, mit KI waren es rund anderthalb Stunden.
Drei Faktoren, die den Unterschied machten
1. Ein Hosting-Partner, der vor dem Fix handelt. RunCloud hatte die Lücke auf allen Servern entschärft, bevor es überhaupt gepatchte Versionen gab, und sagte danach präzise, was noch zu prüfen war, statt «bitte alles updaten». Das ist der Unterschied zwischen einem Abend Arbeit und einer Woche.
2. Eine API statt eines Dashboards. Bestandsaufnahme, PHP-Wechsel, Rollback: Alles lief über dieselbe Schnittstelle. Wer 41 Server im Browser durchklickt, braucht dafür einen Tag und macht Fehler. Die API braucht Minuten und protokolliert jeden Schritt.
3. Claude als Analyse- und Werkzeug-Beschleuniger. Der KI-Assistent von Anthropic, der uns schon beim BEC-Angriff im April die Forensik beschleunigt hatte, schrieb die Skripte, wertete die Server-Daten aus, analysierte das alte Theme und schlug die fünf Korrekturen vor. Was früher einen Arbeitstag pro Theme gekostet hätte, war eine Frage von Minuten.
Ehrlich bleibt, was die KI nicht durfte und nicht konnte. Auf die Produktionsserver kam sie nicht: Jeder Befehl dort wurde bewusst von uns getippt. Und sie hat zwei eigene Fehler gemacht, ein Skript, das nach dem fünften Server abbrach, und einen falschen Feldnamen in einem API-Aufruf. Beides fiel in der Ausgabe auf und war in Minuten korrigiert, aber eben nicht fehlerfrei.
Keiner dieser drei Faktoren allein hätte es gebracht. Ohne den Partner hätten wir gepatcht statt geprüft. Ohne API hätten wir geklickt statt gezählt. Ohne KI hätten wir das Theme von 2014 vermutlich abgeschrieben und das Problem nur vertagt.
Was das für Ihr nächstes Projekt heisst
1. Betrieb ist eine Entscheidung, die man beim Bauen trifft. Dass die offenen Fragen in Minuten beantwortet waren, lag nicht an dieser Nacht, sondern an Entscheidungen von Jahren davor: eine Plattform mit API, ein Server pro Kunde, keine Spezialfälle in der Konfiguration. Wer ein Produkt oder eine Website plant, entscheidet mit der Wahl der Infrastruktur, wie ein solcher Abend später aussieht.
2. Die PHP-Version gehört in den Projektplan, nicht in die Wartungsliste. Neun unserer zwölf Altlasten liefen auf PHP 8.1, das im Dezember 2025 aus dem Support fiel. Jede hatte einen Grund: ein Projekt im Aufbau, ein Theme, das «eh bald ersetzt wird». Die Lücke hat nicht gefragt. Deshalb starten neue Projekte bei uns auf der aktuellen Version, mit einem festen Datum für den nächsten Sprung. Das nächste steht bereits: fünf Sites auf PHP 8.2, dessen Support am 31. Dezember 2026 endet.
3. Bestehender Code ist selten so kaputt, wie er aussieht. Fünf kurze Korrekturen haben ein elf Jahre altes Theme gerettet. Der frühere Versuch war nur gescheitert, weil die weisse Seite nichts verriet. Eine automatische Code-Prüfung findet solche Stellen in Minuten, und ein Rollback in Sekunden macht den Test auf der Live-Site vertretbar. Das gilt für Themes genauso wie für die Eigenentwicklung, die Sie seit Jahren vor sich herschieben.
Wenn Sie etwas bauen wollen, das so läuft
Wir entwickeln Web-Applikationen und Websites und betreiben sie auf der Infrastruktur, von der dieser Beitrag handelt. Eine Auswahl dieser Projekte zeigt unser Portfolio. Von der kritischen Lücke haben unsere Kunden genau so viel mitbekommen: nichts. Wenn Sie als Product Owner oder Produktentwickler ein Projekt planen, bei dem der Betrieb von Anfang an mitgedacht sein soll, sprechen wir gern darüber, bevor die erste Zeile Code steht.
Alle Angaben zu Servern, Versionen und Zeitpunkten entsprechen unseren Aufzeichnungen vom 21. bis 24. Oktober 2026. RunCloud ist unser Hosting-Partner; wir erhalten keine Vergütung für die Nennung.
