Am Dienstag, dem 20. Oktober, kündigten die PHP-Entwickler ein Sicherheitsupdate für den nächsten Tag an. Am Mittwochmorgen hatten viele Behörden, Kliniken und Kommunen ihre Webseiten schon vom Netz genommen. Wer wissen will, ob der Patch wirkt, braucht mehr als ein Häkchen im Changelog.
Der Datenschutz Dude: „Patch drauf, Häkchen dran, Feierabend?“
Was am 21. Oktober passiert ist
PHP steckt hinter einem großen Teil der Webseiten, von Blogs bis zu Onlineshops und WordPress. Am 21. Oktober veröffentlichte das PHP-Projekt Updates für zwei kritische Lücken, CVE-2026–109618 und CVE-2026–109619, beide mit 9,2 von 10 bewertet. Angreifer können ohne Anmeldung Schadcode auf dem Server ausführen. Nach Angaben des Projekts ist das Risiko bei mod_php am höchsten: Dort kann eine einzige Anfrage den Angriff auslösen, bevor Anwendungscode läuft.
Das BSI stufte die Warnung als „Orange“ ein. Vizepräsident Thomas Caspers hielt eine großflächige Ausnutzung innerhalb weniger Stunden für wahrscheinlich, weil KI-Werkzeuge Exploits schneller bauen. Sein Satz dazu: „Es besteht also unverzüglicher Handlungsbedarf!“ Eine breite erfolgreiche Ausnutzung war nach dem BSI-Stand vom 22. Oktober noch nicht bekannt.
Der Patch ist der Anfang, nicht das Ende
Ein Update beantwortet genau eine Frage: Ist die bekannte Lücke im Code geschlossen? Die wichtigeren Fragen kommen danach, in dieser Reihenfolge:
- Inventar. Wo läuft PHP überhaupt? Auch in Appliances, Routern, Hersteller-Software oder beim Dienstleister. Was nicht auf der Liste steht, lässt sich nicht patchen.
- Version prüfen, nicht Vollzug melden. Fix-Stände sind 8.5.12, 8.4.27, 8.3.36 und 8.2.35. Für PHP 8.1 und älter gibt es vom Projekt keine Updates mehr. Dort helfen nur Herstellerpatches oder ein Versionssprung.
- Nachzügler. Am 23. Oktober kam eine dritte Lücke im Session-Upload-Fortschritt dazu (CVE-2026–115560). Bis zum nächsten Release empfiehlt das Projekt,
session.upload_progress.enabledauf 0 zu setzen. Am 26. Oktober folgten aktualisierte Windows-Builds gegen eine Lücke in der Brotli-Bibliothek (CVE-2026–111497). - Logs. Ab dem 20. Oktober auf auffällige Anfragen an PHP-Anwendungen prüfen und das Ergebnis dokumentieren. Wer nichts findet, hat eine Aussage mit Zeitstempel, aber keine Entwarnung.
- Provisorien. Abschaltungen und Notfall-Einstellungen: Was war wann aktiv, und wann wurde es zurückgebaut?
Agentin Cipher: „Dokumentiert ist nicht erledigt.“
Für den Datenschutz: Was der DSB jetzt auf dem Tisch hat
Liegen auf dem Server personenbezogene Daten? Ein Webserver mit Kontaktformular, Shop oder Login verarbeitet sie fast immer.
Eine offene Lücke ist allein noch keine Verletzung des Schutzes personenbezogener Daten im Sinne von Art. 4 Nr. 12 DSGVO. Gibt es aber Anhaltspunkte für einen Zugriff, läuft die Frist von 72 Stunden nach Art. 33 DSGVO, es sei denn, ein Risiko für Betroffene ist voraussichtlich ausgeschlossen. Unabhängig davon verlangt Art. 33 Abs. 5 DSGVO die Dokumentation jeder Verletzung, auch der nicht gemeldeten.
Zur Frage nach Art. 32 DSGVO: Waren die Maßnahmen angemessen, und wurde das Update in vertretbarer Zeit eingespielt? Das LG Traunstein hat am 17. Juli 2026 entschieden, dass ein Hackerangriff allein keinen Verstoß gegen Art. 32 DSGVO beweist. Entscheidend ist, was vorher getroffen war, und das muss schriftlich vorliegen.
Betreibt ein Dienstleister den Server, gehört die Frage in die Auftragsverarbeitung: Wer hat wann gepatcht, und steht das im Vertrag oder in der Dokumentation? Ein Vertrag nach Art. 28 DSGVO regelt das nicht von allein.
Der Dude: „Und wer patcht eigentlich die Kiste im Keller, die der Dienstleister vor drei Jahren aufgestellt hat?“
Notfall: Vom Abschalten bis zu den Lessons Learned
Die schwierigste Entscheidung war nicht technisch: abschalten oder weiterlaufen lassen? Wer sie erst am Mittwochmorgen trifft, entscheidet unter Zeitdruck und mit halber Information. Die Charité sprach von einer Vorsichtsmaßnahme, doch die Online-Terminbuchung war nicht möglich.
Für die Lessons Learned: Wer steht auf der Liste der PHP-Systeme? Wer entscheidet über eine Abschaltung, und wer ist dafür erreichbar? Die PHP-Entwickler haben den Termin einen Tag vorher angekündigt. Wer in dieser Zeit nicht wusste, welche Systeme betroffen sind, hat den Tag für Inventur und Entscheidung verloren.
Ein System, das niemand inventarisiert hat, ist nicht sicher. Es ist unbekannt.
Ciphers Fazit: Klartext zur Lage
Die Lücke ist dort geschlossen, wo das Update eingespielt wurde. Ob sie ausgenutzt wurde, lässt sich aus den bisherigen Quellen nicht sagen. Genau deshalb zählt die Dokumentation: Sie zeigt später, was man wusste und entschieden hat.
Der Dude: „Chillig bleiben, aber aufschreiben, was du geprüft hast. Dann stehst du bei der nächsten Frage nicht mit dem Bauchgefühl allein da. Und sei versichert — irgendjemand wird fragen :-)“
Hahn IT Services, Schwaig
No responses yet