Zwei kritische PHP-Lücken haben am 21. Oktober große Teile des deutschen Internets zeitweise lahmgelegt, sogar die Tagesschau hat berichtet. Interessant ist dabei weniger die Schwachstelle selbst. Der Fall zeigt, wie wenig Zeit künftig zwischen einem Sicherheitsupdate und seiner Ausnutzung bleiben dürfte, gerade seit KI bei der Analyse hilft. Für schlecht gewartete Software wird das zum Problem.
Was am 21. Oktober passiert ist
Behörden, Hochschulen, Krankenhäuser und Unternehmen nahmen ihre Systeme vorsorglich vom Netz, auch das Portal des BSI war zeitweise betroffen. Auslöser waren CVE-2026-109618 und CVE-2026-109619 in PHP. Unter bestimmten Voraussetzungen lässt sich damit ohne Anmeldung beliebiger Code auf dem Server ausführen.
Speicherfehler, Use-after-free und Remote Code Execution kennt die Branche seit Jahrzehnten, ebenso kritische Lücken in weit verbreiteter Software. Neu ist das Tempo, mit dem Schwachstellen heute analysiert und ausgenutzt werden können.
Ein bekannter Fehler wird zum Notfall
Die Vorgeschichte reicht bis 2024. Nach einem externen Audit fand ein PHP-Entwickler Hinweise auf einen Fehler im Speichermanagement. Ausnutzbar schien er, bewiesen war es nicht. Die Behebung blieb liegen: Die Lösungsansätze hatten Nachteile bei Kompatibilität und Stabilität, und erfahrene Entwickler waren anderweitig gebunden. Die PHP Foundation spricht inzwischen selbst von strukturellem Versagen.
Erst als im August 2026 unter anderem Calif, OpenAI und Wiz mithilfe von KI konkrete Angriffswege zeigten, änderte sich die Priorität schlagartig. Die Updates erschienen am 21. Oktober. Die Lehre daraus: Dass kein funktionierender Exploit bekannt ist, heißt nicht, dass es keinen gibt. Es heißt nur, dass man ihn noch nicht kennt.
Koordinierte Offenlegung mit Pannen
Die Abstimmung zwischen Sicherheitsforschern, PHP-Entwicklern, Distributoren und Infrastrukturbetreibern lief zunächst bemerkenswert gut. Cloudflare konnte schon vor der Veröffentlichung Schutzmaßnahmen aktivieren. Dann tauchten am 20. Oktober erste Informationen vorzeitig auf, und das PHP-Team zog den geplanten Termin vom 22. auf den 21. Oktober vor.
Hinzu kamen ein versehentlich veröffentlichtes Exploit-Video und korrigierte Container-Images, die schon vor Ende des Embargos bereitlagen. Angreifer konnten die Änderungen also untersuchen, bevor die offiziellen Updates allgemein verfügbar waren. Amazon will in seinen Honeypots sogar schon am 17. Oktober einen Ausnutzungsversuch beobachtet haben. Woher die Angreifer ihre Informationen hatten, ist unbekannt.
Der Patch als Wegweiser
KI ist wie so oft Fluch und Segen. Die Forscher von Wiz beschreiben, wie ein Einzelner mit KI-Unterstützung in etwa einer Woche schaffte, wofür früher ein Spezialistenteam Monate gebraucht hätte. Solche Angaben sollte man mit Vorsicht lesen, die Richtung ist aber klar.
Sobald ein Update erscheint, können Angreifer die neue Version mit der alten vergleichen. Diese Patch-Diff-Analyse ist nicht neu, der Patch zeigt gewissermaßen, wo man suchen muss. Bisher kostete es viel Erfahrung und Zeit, daraus einen verlässlichen Exploit zu bauen, besonders bei komplexen Speicherfehlern. Künftig könnte das auch Angreifern ohne große Expertise in kurzer Zeit gelingen, und sie können es im großen Stil ausrollen. Für Angreifer wird das Geschäft einfacher, für Verteidiger wird die Zeit deutlich knapper.
Wenn das halbe Internet in den Wartungsmodus geht
Messungen von UptimeRobot zeigen, dass die Zahl der nicht erreichbaren .de-Websites vom 20. auf den 21. Oktober um rund 113 Prozent stieg. An europäischen Messpunkten gab es in der Spitze etwa zwanzigmal so viele Downtime-Alarme wie üblich. Nicht alle Ausfälle gehen auf PHP2Shell zurück.
Landesverwaltungen, Kommunen, Hochschulen und Krankenhäuser nahmen Angebote vom Netz. Der Rechnungssoftware-Anbieter easybill schaltete Anwendung und Website ab. Beim Hoster D&T Internet verhinderten ältere Anwendungen teils kurzfristige Updates, sodass Systeme auf andere Server umziehen mussten. Die wirtschaftlichen Folgen sind erheblich: Shops verlieren Bestellungen, Cloud-Anwendungen sind nicht nutzbar, Behörden können nichts digital anbieten.
In vielen Fällen war das Abschalten richtig, zumal die Updates erst am 21. Oktober bereitstanden. Trotzdem ist es ein schlechtes Zeichen, wenn Teile der Infrastruktur bei einer kritischen Lücke nur die Wahl zwischen riskantem Weiterbetrieb und Abschaltung haben.
Legacy rächt sich
Schlecht gewartete Software bleibt schlecht gewartete Software. Seit Jahren laufen Anwendungen auf veralteten PHP-Versionen, nutzen nicht mehr unterstützte Bibliotheken oder stammen von Herstellern, die längst keine Updates mehr liefern. Man nennt sie gern Legacy-Anwendungen: geschäftskritisch, also weiter online, aber nicht mehr wartbar.
Die Gründe kennt jeder. Ein Update könnte Funktionen brechen, eine Migration kostet Geld, die ursprünglichen Entwickler sind weg, und niemand will die Verantwortung für eine größere Änderung tragen. Also wird verschoben, und beim nächsten Mal wieder. So wächst die Patchlücke, und die Anwendung wird noch unwartbarer. Solange nichts passiert, scheint das sogar zu funktionieren.
Déjà-vu: ProxyLogon
Im März 2021 sorgten vier kritische Lücken in Microsoft Exchange unter dem Namen ProxyLogon für Schlagzeilen. Microsoft veröffentlichte außerplanmäßige Updates, nachdem die Gruppe Hafnium die Lücken bereits ausgenutzt hatte. Auch damals berichteten Tagesschau und Zeitungen.
Das BSI sprach von Zehntausenden angreifbaren Exchange-Servern in Deutschland und schrieb mehr als 9.000 Unternehmen direkt an. Eine Stichprobe knapp eine Woche nach dem Patchday ergab, dass die Hälfte der untersuchten Server von Organisationen mit mehr als 1.000 Mitarbeitenden noch ungepatcht war. Ob es heute besser aussieht, darf man bezweifeln.
Hafnium und PHP2Shell sind nicht dasselbe: Die Exchange-Lücken wurden schon vor den Updates erfolgreich angegriffen. Die Parallele liegt im Betrieb, denn der Patchprozess ist an vielen Stellen defekt.
Und jetzt?
Die Anforderungen an den IT-Betrieb sind theoretisch dieselben geblieben. Aber das Zeitfenster zum Patchen schrumpft drastisch. Es reicht nicht, die Verantwortung für Updates irgendwo in der IT-Abteilung abzulegen. Unternehmen müssen wissen, welche Systeme geschäftskritisch sind, von welchen Softwarekomponenten sie abhängen und was passiert, wenn diese über Nacht abgeschaltet werden müssen. Dafür braucht es ein funktionierendes Informationssicherheitsmanagement und Business Continuity Management.
KI wird auch Verteidigern helfen, Lücken zu finden und Korrekturen zu prüfen und schnell auszurollen. Trotzdem bleibt das Fazit simpel: 2021 hieß die Warnung Hafnium, 2026 heißt sie PHP2Shell. Nicht patchen ist keine Option.