Oktober 2026 im Rückblick: Sieben Sicherheitsereignisse, ihre Zeitachsen und das Patchfenster

Im Oktober 2026 häuften sich die Sicherheitsmeldungen so stark, dass eine Zusammenstellung des Entwicklers Drew Silcock die Runde machte: „Is this the new cyber normal?“ vom 23. Oktober. Sein Schluss lautet, die Zeit von der Nachricht über eine Lücke bis zu automatisierten Angriffen sei von Wochen auf Stunden geschrumpft. Wir haben jede Behauptung daraus gegen die Primärquellen gelesen und für jedes Ereignis aufgeschrieben, wann das Advisory kam, wann der Patch und wann der Exploit.

Ein Patchfenster ist die Zeit zwischen dem Bekanntwerden einer Sicherheitslücke und dem Moment, in dem ein Betreiber sie im laufenden Betrieb geschlossen hat, einschließlich Neustart der betroffenen Dienste. Es besteht aus drei Datumsangaben: Advisory (die Lücke ist öffentlich), Exploit (ein funktionierender Angriff ist bekannt) und Patch (die Korrektur läuft). Dieser Beitrag misst, wie lang der Abschnitt zwischen Advisory und Exploit im Oktober tatsächlich war.

Die Zeitachsen im Überblick

Alle Zeiten in UTC, soweit die Quelle eine Uhrzeit nennt. Wo eine Zelle „nicht belegt“ sagt, haben wir in den gelesenen Quellen kein Datum gefunden.

PHP2Shell: Der Exploit kam vor dem Advisory

Die PHP-Foundation datiert es so: Am 20. Oktober gegen 15:00 UTC kursierten die beiden CVE-Nummern auf Foren, mit falscher Uhrzeit und falscher Bewertung. Das Projekt zog die Vorankündigung auf 19:30 vor und den Release vom 22. auf den 21. Oktober, 14:00 UTC. Gegen 20:00 veröffentlichte Calif, einer der Melder, versehentlich ein Video seines Exploits. Am 21. Oktober um 07:41 stellte nach Angabe der PHP-Foundation der Distributor Chainguard Images mit dem Fix öffentlich bereit, mehr als sechs Stunden vor dem Release. Das Advisory selbst trägt in der GitHub-Schnittstelle den Zeitstempel 13:34.

Amazon schreibt, ein Versuch gegen sein Honeypot-Netz stamme vom 17. Oktober, vier Tage vor dem Advisory, von einer anonymisierten Adresse. Der früheste Proof of Concept habe am 21. Oktober gegen 02:00 vorgelegen. Nach dem Release seien weitere „innerhalb von Stunden“ aufgetaucht und fast sofort gegen die Sensoren gelaufen. Das sind Herstellerangaben aus eigener Telemetrie. Die PHP-Foundation hielt dagegen, ihr Team habe zum Zeitpunkt des Releases keine funktionierenden Exploits gefunden. Beide Aussagen können stimmen, denn sie messen an verschiedenen Stellen. Ob am 17. Oktober tatsächlich ein wirksamer Angriff lief, sagt Amazon selbst nicht.

Zwei Behauptungen aus der Zusammenstellung halten der Prüfung stand. Die Lücke hat eine Vorgeschichte: 2020 wurde ein verwandter Speicherfehler gemeldet (Bug #78876), und ein Audit von OSTIF und Quarkslab fand 2024 ein verwandtes Problem, dessen Ausnutzbarkeit unbewiesen blieb. Silcock schreibt, der Fehler sei im Audit gefunden worden; die Quellen sprechen von einem verwandten Fehler ohne konkreten Angriffsweg. Zweitens waren KI-Werkzeuge beteiligt: Die PHP-Foundation nennt OpenAI Codex Security unter den Findern. Die Modellnamen, die Silcock aufführt, stehen in keiner der gelesenen Primärquellen.

eMudhra: Schlüssel 4 und die Zeit bis zum Beweis

Am 17. Oktober meldete ein Forscher (im Bugzilla als Wayne geführt), dass acht Zwischenzertifikate von eMudhra private Schlüssel mit kleinen Ganzzahlen nutzten. Die Zertifikate stammen aus einer Schlüsselzeremonie vom 30. April 2025. Mozilla bestätigt: Alle acht Schlüssel waren kleiner als 256. Mozilla erhielt die Meldung um 20:06 und rechnete die Schlüssel um 21:48 selbst zurück, 1 Stunde 42 Minuten später. Die Werte 4 bis 237 nennt ein Kommentator im Bugzilla; bestätigt hat sie dort niemand, wir führen sie als Kommentar.

Der CRLSet-Eintrag stand um 22:46, die Firefox-Sperre um 22:59, eMudhra widerrief am 18. Oktober gegen 09:38. In den Certificate-Transparency-Logs tauchte ab dem 20. Oktober 09:40 eine Welle von 107.107 Zertifikaten auf, nach Mozillas Auszählung 106.050 davon Testzertifikate für google.com. eMudhra schreibt, aus den acht Zwischenzertifikaten sei kein einziges Zertifikat im Betrieb ausgestellt worden. Dass Angreifer die Schlüssel vorher nutzten, ist nicht belegt.

GitLab: Ein Tag bis zum PoC, 17 Tage bis zur Ausnutzung

Beide CVSS-10-Lücken sind belegt. CVE-2026-97229 wurde am 12. Oktober mit 19.4.2, 19.3.5 und 19.2.8 geschlossen, am Folgetag veröffentlichte Rapid7 einen Proof of Concept und schrieb, bestätigte Ausnutzung gebe es noch nicht. Nach Rapid7 braucht der Weg Schreibrechte auf einem öffentlichen Projekt, auch wenn die Bewertung „ohne Anmeldung“ lautet. Die CISA nahm die Lücke am 29. Oktober in ihren KEV-Katalog auf. Das ist das Datum der bestätigten Ausnutzung, nicht des ersten Angriffs. CVE-2026-110264 folgte am 21. Oktober als zweite Regex-Lücke; 19.4.2 ist dafür noch verwundbar. Im KEV steht sie bis zum 6. November nicht, und ob ein öffentlicher PoC existiert, widersprechen sich die Berichte.

Kernel, LiteLLM und Railway

Trend Micros Zero Day Initiative schickte am 21. Oktober fünf Berichte an das Kernel-Sicherheitsteam und setzte nach Sysdig öffentliche Listen in Kopie. Phoronix beschreibt es als Versehen, eine Stellungnahme von ZDI haben wir nicht gefunden. Zwei Berichte tragen CVSS 9.0, ein CVE und ein Fix im Mainline fehlten bis zum 28. Oktober. Sysdig meldet, TuxCare habe den PoC zu ZDI-CAN-33367 nachgebaut, mit Root-Zugriff auf Ubuntu, Debian und AlmaLinux.

LiteLLM 1.107.0 war nach Herstellerangabe auf PyPI von 11:39 bis 13:23 erreichbar, die Docker-Tags bis 14:20. Das sind gut 100 Minuten für PyPI. Ein früherer Vorfall mit 1.82.7 und 1.82.8 ist bei Datadog belegt. Unseren eigenen Befund dazu beschreibt der Beitrag LiteLLM 1.107.0: Schadcode und Schlüsseltausch. Bei Railway vergingen 37,5 Stunden von der ersten Latenzmeldung (20.10. 13:58) bis zur Bestätigung, dass der Angreifer keinen Zugriff mehr hatte (22.10. 03:32); die Entschlüsselung der Variablen fällt nach Railways Bericht auf den 21.10. zwischen 07:25 und 09:18.

Was die These „Stunden statt Tage“ trägt

Gestützt wird sie von einem Fall mit Daten: PHP2Shell, und dort aus Amazons Telemetrie. Bei GitLab liegen zwischen Patch und öffentlichem PoC etwa ein Tag und bis zur bestätigten Ausnutzung 17 Tage. Beim Kernel sind es bis zum nachgebauten PoC höchstens drei Tage, bei eMudhra knapp zwei Stunden bis zur Schlüsselrückrechnung bei Mozilla und gut zweieinhalb Tage bis zu Testzertifikaten in den Logs. Außerhalb des Oktobers meldet ein Anbieter für die Alpine-OpenSSH-Lücke einen ersten Versuch weniger als neun Stunden nach der CVE-Veröffentlichung (Help Net Security); den Flottencheck dazu haben wir im Alpine-Beitrag beschrieben. Als allgemeine Regel bleibt die These offen: Ein Honeypot-Betreiber sieht nur, was bei ihm einschlägt, und das KEV-Datum ist eine Obergrenze. Unabhängige Messungen über viele Ereignisse fehlen.

Bei PHP2Shell haben wir die Zeit auch gegen uns selbst gestellt. Nach unserem PHP-Messbeitrag lief unser eigenes Image am 21. Oktober um 17:07 UTC, 3 Stunden 33 Minuten nach dem GitHub-Zeitstempel des Advisorys, und der letzte betroffene Container startete um 20:28:10, also 6 Stunden 54 Minuten danach. Weitere Beiträge zu Lücken und Lieferkette bündelt der Hub Security und Datenschutz.

Empfehlung für das Patchfenster

Für Systeme, die aus dem Internet erreichbar sind und eine unauthentifizierte Remote-Code-Ausführung haben, gilt der Tag des Advisorys als Frist, der Neustart eingeschlossen. Danach kommen Plattformen, die Zugangsdaten für andere Systeme halten, also CI, Build-Server und Secret-Speicher: Dort gehört nach einem Vorfall die Rotation vor die Ursachenanalyse. Bei Lücken, die erst nach dem Advisory auftauchen, sucht man rückwärts ab 17. Oktober, nicht ab dem Veröffentlichungstag. Interne Systeme ohne gespeicherte Geheimnisse dürfen einige Tage warten. Wer Bestand und Patchfenster prüfen lassen will, findet das Angebot unter Leistungen.

Weiterführende Quellen

• Silcocks Zusammenstellung (Ausgangspunkt, nicht Beleg): drew.silcock.dev
• PHP, Advisory CVE-2026-109618: GHSA-w8hw-w9fx-j79w
• PHP-Foundation zur Zeitleiste von Leak und Release: thephp.foundation
• Calif, Entdeckung und Zeitleiste 2004 bis 2026: calif.io/php2shell
• Amazon Threat Intelligence, Versuch vom 17. Oktober: AWS Security Blog
• Recorded Future, Zeitleiste PHP2Shell: recordedfuture.com
• CISA-Katalog bekannter ausgenutzter Lücken: cisa.gov
• GitLab-Patch vom 12. Oktober: 19.4.2 und vom 21. Oktober: 19.5.1
• Rapid7 zu CVE-2026-97229: rapid7.com
• eMudhra, Stellungnahme: emudhra.com
• Mozilla, Fallbeschreibung: Bugzilla 2083449
• Phoronix zu den Kernel-Berichten: phoronix.com
• Sysdig zu den sechs ZDI-Funden: sysdig.com
• LiteLLM, Vorfallsbericht: docs.litellm.ai
• Railway, vorläufiger Bericht: blog.railway.com