PHP2Shell: Die Schonfrist ist vorbei

Sogar die Tagesschau und die Zeitungen berichten: Zwei kritische PHP-Schwachstellen haben große Teile des Internets zeitweise lahmgelegt. Die Sicherheitsforschung wurde dabei erheblich durch künstliche Intelligenz unterstützt. Das eigentlich Interessante ist aber nicht die Schwachstelle selbst. Vielmehr zeigt der Fall, wie wenig Zeit künftig zwischen der Veröffentlichung eines Sicherheitsupdates und dessen Ausnutzung bleiben dürfte. Für schlecht gewartete Software wird das zunehmend zum Problem.

Tobias Glemser ist BSI-zertifizierter Penetrationstester und Geschäftsführer der secuvera GmbH. Seit über 20 Jahren arbeitet er in der Cybersicherheit. Privat ist er unter anderem bei OWASP engagiert.

Am 21. Oktober waren zahlreiche Webseiten und Onlinedienste in Deutschland nicht erreichbar. Behörden, Hochschulen, Krankenhäuser und Unternehmen nahmen ihre Systeme vorsorglich vom Netz. Auch das Portal des Bundesamtes für Sicherheit in der Informationstechnik (BSI) war zeitweise betroffen. Ursache waren zwei kritische Schwachstellen in PHP, einer der weltweit meistverwendeten Programmiersprachen für Webanwendungen.

Die Schwachstellen CVE-2026-109618 und CVE-2026-109619 ermöglichen unter bestimmten Voraussetzungen die Ausführung beliebigen Programmcodes auf betroffenen Servern, ohne dass sich ein Angreifer zuvor authentifizieren muss. Die Auswirkungen können entsprechend gravierend sein.

Trotzdem sind solche Schwachstellen zunächst nichts grundsätzlich Neues. Fehler bei der Speicherverwaltung, Use-after-free-Schwachstellen und Remote Code Execution kennen wir seit Jahrzehnten. Auch kritische Schwachstellen in weit verbreiteter Software sind kein neues Phänomen.

Warum also diese Aufregung? Und warum mussten so viele Betreiber ihre Systeme abschalten?

Die Antwort liegt weniger in den beiden Schwachstellen selbst als in der veränderten Geschwindigkeit, mit der Schwachstellen heute analysiert und ausgenutzt werden können.

Vom bekannten Fehler zum kritischen Problem

Die Vorgeschichte beginnt bereits 2024. Nach einem externen Sicherheitsaudit entdeckte ein PHP-Entwickler Hinweise auf einen Fehler im Speichermanagement. Über eine mögliche Ausnutzung wurde schon damals nachgedacht, nachweisen ließ sie sich zunächst nicht. Wie wäre das wohl im Sommer 2026 gewesen?

Die Behebung blieb liegen. Verschiedene Lösungsansätze hatten Nachteile hinsichtlich Kompatibilität und Stabilität, erfahrene Entwickler waren mit anderen Aufgaben beschäftigt. Die PHP Foundation bezeichnet die Verzögerung inzwischen selbst als strukturelles Versagen. Erst als im August 2026 unter anderem Calif, OpenAI und Wiz mithilfe von KI konkrete Angriffsmöglichkeiten nachwiesen, änderte sich die Priorität schlagartig. Die Sicherheitsupdates erschienen schließlich am 21. Oktober.

Hier zeigt sich bereits eine erste Schwäche unseres bisherigen Umgangs mit Sicherheitslücken. Dass für eine Schwachstelle kein funktionierender Exploit bekannt ist, bedeutet nicht, dass sie nicht ausgenutzt werden kann. Es bedeutet zunächst nur, dass wir noch keinen kennen.

Disclosure: Gut organisiert – und trotzdem schiefgelaufen

Die eigentliche Koordination funktionierte zunächst bemerkenswert gut. Sicherheitsforscher, PHP-Entwickler, Distributoren und Infrastrukturbetreiber arbeiteten zusammen, sodass unter anderem Cloudflare schon vor Veröffentlichung der Sicherheitsupdates Schutzmaßnahmen aktivieren konnte. Das war angesichts der Verbreitung von PHP eine beachtliche Leistung.

Am 20. Oktober tauchten erste Informationen vorzeitig auf. Das PHP-Team zog daraufhin die ursprünglich für den 22. Oktober geplante Veröffentlichung um einen Tag vor. Hinzu kamen ein versehentlich veröffentlichtes Exploit-Video und bereits vor Ablauf des Embargos bereitgestellte, korrigierte Container-Images. Potenzielle Angreifer konnten die Änderungen damit untersuchen, bevor die offiziellen Updates allgemein verfügbar waren. Amazon beobachtete nach eigenen Angaben sogar schon am 17. Oktober einen Ausnutzungsversuch in seiner Honeypot-Infrastruktur. Wie die Angreifer bereits vor der Veröffentlichung an die notwendigen Informationen gelangten, ist unbekannt.

Der Patch als Anleitung für Angreifer

KI ist – wie so oft – Fluch und Segen. Die Forscher von Wiz beschreiben, wie sie mit KI-Unterstützung komplexe Angriffsmöglichkeiten entwickelten. Nach eigenen Angaben konnte ein einzelner Forscher innerhalb etwa einer Woche Arbeiten erledigen, für die früher ein spezialisiertes Team mehrere Monate benötigt hätte. Natürlich sollte man solche Angaben mit Vorsicht genießen. Die grundsätzliche Entwicklung ist aber offensichtlich: Sobald ein Sicherheitsupdate veröffentlicht wird, können Angreifer die korrigierte Software mit der vorherigen Version vergleichen. Diese Patch-Diff-Analyse ist keineswegs neu. Sie wird seit vielen Jahren eingesetzt, um herauszufinden, welche Fehler ein Hersteller mit seinen Änderungen behoben hat. Der Patch liefert gewissermaßen die Markierung, an welcher Stelle gesucht werden muss.

Bisher erforderte es viel Erfahrung und Zeit, daraus eine tatsächlich ausnutzbare Schwachstelle abzuleiten. Gerade bei komplexen Speicherfehlern kann die Entwicklung eines zuverlässigen Exploits erheblichen Aufwand verursachen.

Aber jetzt ist zu befürchten, dass zumindest mittelfristig jeder beliebige Angreifer ohne hohe Expertise innerhalb kurzer Zeit einen funktionierenden Exploit entwickeln und hochskaliert "ausrollen" kann. Für die Angreifer wird das Geschäft einfacher. Für die Verteidiger wird die Zeit knapper. Viel knapper.

Damit verändert sich eine wesentliche Grundlage unseres Schwachstellen- und Risikomanagements.

Das halbe Internet im Wartungsmodus?

Nach Messungen des Monitoringanbieters UptimeRobot stieg die Zahl nicht erreichbarer, von diesem Dienst überwachten .de-Websites vom 20. auf den 21. Oktober um rund 113 Prozent. Bei europäischen Messstandorten wurden in der Spitze ungefähr zwanzigmal so viele Downtime-Alarme wie gewöhnlich registriert. Nicht alle diese Ausfälle lassen sich PHP2Shell zurechnen.

In Deutschland nahmen zahlreiche öffentliche Einrichtungen ihre Angebote vorsorglich vom Netz. Betroffen waren Landesverwaltungen, Kommunen, Hochschulen und Krankenhäuser. Auch Unternehmen reagierten: Der Rechnungssoftwareanbieter easybill schaltete sowohl seine Anwendung als auch seine Webseite ab. Beim Hostinganbieter D&T Internet verhinderten ältere Anwendungen teilweise eine kurzfristige Aktualisierung, sodass Systeme auf andere Server umgezogen werden mussten.

Das hat erhebliche wirtschaftliche Folgen. Onlineshops verlieren während einer Abschaltung Bestellmöglichkeiten, Kunden können Cloudanwendungen nicht nutzen und Behörden keine digitalen Dienstleistungen anbieten. Natürlich war es in vielen Fällen richtig, gefährdete Dienste vorsorglich abzuschalten, zumal die offiziellen Updates erst am 21. Oktober bereitstanden. Trotzdem sollte uns zu denken geben, dass Teile unserer digitalen Infrastruktur bei einer kritischen Schwachstelle praktisch nur zwischen Weiterbetrieb mit erheblichem Risiko und Abschaltung wählen konnten. Das kann keine dauerhafte Lösung sein.

Die Rechnung für schlechte Softwarewartung

An dieser Stelle kommen wir zu einem Problem, das in der Diskussion um die beeindruckenden KI-Fähigkeiten etwas untergeht.

Schlecht gewartete Software bleibt schlecht gewartete Software.

Wir kennen seit Jahren Anwendungen, die auf veralteten PHP-Versionen (oder anderer Software) laufen, nicht mehr unterstützte Bibliotheken verwenden oder deren Hersteller seit langer Zeit keine Aktualisierungen bereitstellen. Euphemistisch „Legacy-Anwendungen“ genannt: geschäftskritisch, also weiter online, aber nicht mehr wartbar. Die Gründe dafür sind vielfältig: Ein Update könnte Funktionen beeinträchtigen, eine Migration kostet Geld, die ursprünglichen Entwickler stehen nicht mehr zur Verfügung oder niemand möchte die Verantwortung für eine größere Änderung übernehmen.

Also wird das Update verschoben. Und beim nächsten Mal wieder. Es entsteht eine Patchlücke, die zu noch größerer „Unwartbarkeit“ führt.

Solange nichts passiert, scheint diese Strategie sogar zu funktionieren. Die Anwendung läuft schließlich noch. Weshalb sollte man Geld in etwas investieren, das offensichtlich seinen Zweck erfüllt?

Die Antwort haben wir jetzt (erneut) gesehen.

Das hatten wir doch schon einmal

Wer sich an den März 2021 erinnert, dürfte ein Déjà-vu haben. Damals waren es vier kritische Schwachstellen in Microsoft Exchange, die unter dem Namen ProxyLogon bekannt wurden. Microsoft brachte außerplanmäßige Sicherheitsupdates heraus, nachdem die Angreifergruppe Hafnium die Schwachstellen bereits ausgenutzt hatte. Auch damals haben Tagesschau und Zeitungen berichtet.

Das BSI sprach von Zehntausenden über das Internet angreifbaren Exchange-Servern in Deutschland und schrieb mehr als 9.000 Unternehmen direkt an. Damals habe ich eine knappe Woche nach dem Patchday eine kleine Analyse gemacht: 50 Prozent der ausgewählten Server (alle von Organisationen mit mehr als 1.000 Mitarbeitenden) waren weiter nicht gepatcht. Ist es aktuell besser? Man darf Zweifel haben.

Natürlich ist der Verlauf von Hafnium und PHP2Shell nicht dasselbe: Die Exchange-Schwachstellen wurden vor der Veröffentlichung der Updates bereits erfolgreich ausgenutzt. Die Parallele liegt im Betrieb: Der Patchprozess ist defekt.

Und nun?

Die Anforderungen an den IT-Betrieb sind in der Theorie seit jeher dieselben. Der Zeitraum für die Umsetzung von Patches verkürzt sich jedoch drastisch. Dabei genügt es nicht, die Verantwortung für Sicherheitsupdates irgendwo in einer IT-Abteilung zu verorten. Unternehmen müssen wissen, welche Systeme geschäftskritisch sind, von welchen Softwarekomponenten sie abhängen und was passiert, wenn diese von heute auf morgen abgeschaltet werden müssen. Genau dafür braucht es ein funktionierendes Informationssicherheitsmanagement und Business Continuity Management.

KI wird aber auch Verteidigern helfen, Schwachstellen zu finden und Korrekturen zu prüfen und rasch auszurollen.

2021 hieß die Warnung Hafnium, 2026 PHP2Shell.

Wer den Schuss jetzt noch nicht gehört hat, wird ihn vermutlich auch beim nächsten Mal nicht hören. Nicht patchen ist keine Option.