27 Minuten statt sechs Stunden: Was die kritische PHP-Lücke vom 21. Oktober 2026 über Software-Lieferketten verrät

Am Abend des 20. Oktober 2026 kündigte das PHP-Projekt für den folgenden Tag eine außerplanmäßige Sicherheitsveröffentlichung an.¹ Zwei Lücken, beide mit 9,2 von 10 Punkten bewertet, beide ohne Anmeldung aus dem Internet ausnutzbar. Die europäische Behörde CERT-EU stufte beide als kritisch ein: „Both vulnerabilities can allow unauthenticated remote code execution“, und riet, betroffene Systeme „immediately“ zu aktualisieren.² Dieser Artikel ordnet ein, was passiert ist, wie wir den Tag für unsere Kunden gestaltet haben und warum die Zeit zwischen Korrektur und Schutz heute das eigentliche Risiko ist.

Worum es ging

PHP ist die Programmiersprache, in der ein Großteil des Internets geschrieben ist: Onlineshops, Content-Management-Systeme, Portale, auch die meisten Anwendungen, die wir für unsere Kunden betreiben. Die beiden Lücken, geführt unter CVE-2026-109618 und CVE-2026-109619³, erlaubten es einem Angreifer, eigene Befehle auf dem Server auszuführen. Fachlich spricht man von Remote Code Execution, der schwersten Klasse von Schwachstellen. Das PHP-Projekt selbst beschreibt die Korrektur so: „PHP 8.5.12, 8.4.27, 8.3.36 and 8.2.35 fix two critical vulnerabilities that can allow unauthenticated remote code execution.“⁴ Es brauchte kein Passwort, kein Opfer, das auf einen Link klickt. Es reichte, dass die Anwendung erreichbar war.

Entdeckt wurden die Lücken von Wiz Research zusammen mit OpenAI Codex Security, also unter Mitwirkung eines KI-Systems. Die Forscher bestätigen: „The demonstrated remote code execution and memory-disclosure attacks did not require authentication or an application account.“⁵ Noch am Tag der Veröffentlichung beobachtete das Sicherheitsunternehmen watchTowr über sein weltweites Netz von Köderservern erste Angriffsversuche: „Exploitation has been observed in the wild as of the 21st of October.“⁶

Das passt zu einer Entwicklung, die wir seit einiger Zeit beobachten: Sobald eine Korrektur erscheint, lesen Angreifer aus dem Unterschied zwischen alter und neuer Version ab, wo der Fehler sitzt. Mit KI-Unterstützung entsteht daraus nach unserer Einschätzung in weniger als 60 Minuten ein funktionierender Angriff. Das Zeitfenster, in dem ein Update noch rechtzeitig kommt, ist auf Minuten geschrumpft.

Der Tag in Zahlen

Die Korrektur erschien um 15:36 Uhr, eine knappe halbe Stunde früher als angekündigt.⁴ Ab diesem Moment lief die Uhr für jeden Betreiber einer PHP-Anwendung. So lange hat es gedauert, bis die korrigierte Version auf den jeweiligen Wegen verfügbar war (alle Zeiten MESZ):

Debian und Ubuntu waren schnell, weil sie zum Kreis der vorab informierten Hersteller gehören und ihre Pakete bereits fertig hatten. Alle anderen mussten warten, bis die Korrektur die Kette aus Zwischenstationen durchlaufen hatte. Wer seine Anwendungen als Container betreibt, also der Großteil moderner Infrastruktur, war auf dem üblichen Weg drei bis sechs Stunden länger angreifbar als nötig.

Warum die Kette so lang ist

Zwischen dem PHP-Projekt und einem laufenden Server liegen in einer typischen Container-Umgebung drei voneinander unabhängige Stationen. Zuerst muss die Linux-Distribution die neue Version als Paket bauen und veröffentlichen. Dann muss der Anbieter der Basis-Container-Abbilder dieses Paket in seine Abbilder übernehmen und für alle Varianten und Prozessorarchitekturen neu bauen. Erst danach können die Anwendungen, die auf diesen Abbildern aufsetzen, selbst neu gebaut werden.

Jede dieser Stationen ist für den Normalbetrieb ausgelegt, nicht für einen Notfall am selben Tag. Am 21. Oktober war das gut zu beobachten: Bei Alpine Linux schlugen die automatischen Tests fehl, weil zwei der neuen Prüfungen des PHP-Projekts in der Alpine-Umgebung nicht liefen. Ein Mensch musste eingreifen und die Prüfungen ausnehmen, die Build-Server waren zusätzlich überlastet, und am Ende dauerte es sechs Stunden.¹¹ Niemand hat dabei einen Fehler gemacht. Der Weg ist einfach nicht für diese Geschwindigkeit gebaut.

Wie der Tag bei uns ablief

Die entscheidende Frage haben wir uns am Vormittag gestellt, als die Korrektur noch gar nicht existierte: Wie lange wird es dauern, bis die Pakete da sind, und können wir in dieser Zeit einen Weg schaffen, der nicht auf den Lieferanten wartet?

Vorbereitung. Zuerst haben wir geprüft, welche PHP-Version in jeder einzelnen Kundenanwendung tatsächlich läuft. Dabei zeigte sich, dass ein Teil unserer Basis-Abbilder an einen Stand des Lieferanten gebunden war, der keine Aktualisierungen mehr erhielt. Das haben wir noch am Vormittag grundlegend korrigiert, unabhängig von dieser einen Lücke.

Schutzmaßnahmen vor der Korrektur. Aus den öffentlich verfügbaren Hinweisen ließ sich ableiten, welche Funktionen von PHP ein Angreifer für diese Lücken braucht. Zwei davon nutzt keine unserer Anwendungen. Wir haben sie abgeschaltet, nachdem wir jede Kundenanwendung einzeln auf Verträglichkeit geprüft hatten. Eine der beiden Maßnahmen hat das PHP-Projekt am Nachmittag selbst empfohlen: „Set session.upload_progress.enabled=0 and restart every worker.“ Zugleich stellt es klar, dass solche Maßnahmen das Risiko nur verringern: „There are no complete mitigations, updating is the only safe choice.“⁴

Ein eigener Weg zum Paket. Parallel haben wir die Möglichkeit geschaffen, die PHP-Pakete selbst zu bauen, nach exakt demselben Bauplan, den unser Linux-Lieferant verwendet, nur eben sofort. Das ist kein Fremdprodukt und keine Abkürzung bei der Qualität, sondern derselbe Code aus derselben Quelle. Der Unterschied ist allein, dass wir nicht in einer Warteschlange stehen.

Umsetzung. Um 15:36 Uhr erschien die Korrektur. 27 Minuten später, um 16:03 Uhr, stand die korrigierte Version für unsere Anwendungen bereit. Die folgenden Minuten galten der Prüfung: Jede Anwendung wurde neu gebaut, ausgerollt und der Stand direkt auf den Servern nachgeprüft. Am Abend, als unser Lieferant die offiziellen Pakete endlich bereitstellte, haben wir wieder auf diese zurückgewechselt. Das ist Hygiene, kein Sicherheitsthema, und für die Anwendungen nicht spürbar.

Was Unternehmen daraus mitnehmen sollten

Die Lehre dieses Tages ist nicht, dass man PHP meiden sollte. Vergleichbare Lücken gab es in jeder verbreiteten Technologie, und es wird sie wieder geben. Die Lehre ist, dass die Geschwindigkeit, mit der eine Korrektur bei Ihnen ankommt, eine Eigenschaft Ihrer Infrastruktur ist, keine Frage des Glücks.

Drei Fragen lohnen sich für jedes Gespräch mit dem eigenen Dienstleister:

1. Wissen Sie, welche Version wo läuft? Ohne vollständige, versionierte Auflistung aller Bestandteile lässt sich am Tag einer Lücke nicht einmal die Betroffenheit zuverlässig feststellen. Wie wir das handhaben, beschreiben wir unter Sicherheit und Compliance.
2. Wie viele Stationen liegen zwischen Hersteller und Server? Jede Station kostet Stunden. Wer sie kennt, kann für den Ernstfall einen kürzeren Weg vorbereiten.
3. Ist der Ernstfall geübt? Der Weg, den wir am 21. Oktober genutzt haben, war am Morgen desselben Tages entstanden. Beim nächsten Mal ist er von der ersten Minute an verfügbar. Genau das unterscheidet regelmäßige Aktualisierung als Kultur von Aktualisierung als Projekt.

Für unsere Kunden hieß der 21. Oktober am Ende: Ihre Anwendungen liefen 27 Minuten nach der Veröffentlichung auf der korrigierten Version, Stunden bevor die üblichen Wege sie überhaupt bereitstellten. Es gab nichts zu tun.

Passend dazu: Patch-/Update-Status, Server-Infrastruktur-Audits und Sicherheit und Compliance.