Die 90-Tage-Offenlegungspolitik ist tot

• Die 90-tägige Responsible Disclosure verliert durch LLMs ihren Schutzeffekt, weil sowohl die Zahl der Finder als auch die Geschwindigkeit von Exploit-Entwicklung gestiegen sind
• Innerhalb von 6 Wochen meldeten 11 Personen denselben kritischen Bug bei der Zahlungsvalidierung, was eine gleichzeitige Wiederentdeckung sichtbar machte
• Ein React-Patch-Diff wurde mit KI-Hilfe in nur 30 Minuten in einen funktionierenden Exploit verwandelt
• Copy Fail und Dirty Frag führten von öffentlichen PoCs zu realer Ausnutzung, wodurch Embargos zusammenbrachen
• Kritische Issues müssen als P0 sofort behandelt werden, und LLMs gehören in die Security-Pipeline

---

Warum das Modell der 90-tägigen Responsible Disclosure zerbrochen ist

• Die 90-tägige Responsible-Disclosure-Frist wurde unter der Annahme geschaffen, dass Bug-Finder selten sind und die Entwicklung von Exploits langsam verläuft
• In den vergangenen 12 Monaten sind die Werkzeuge von Security-Teams, Angreifern und Forschern mit ähnlicher Geschwindigkeit deutlich leistungsfähiger geworden; die Einschätzung ist, dass LLMs die Zeit für das Finden von Schwachstellen und die Entwicklung von Exploits nahezu auf 0 reduziert haben
• Im Modell von 2019 gab man Anbietern im Stil von Google Project Zero 90 Tage und ging dabei von Folgendem aus
  • Fast niemand sonst würde denselben Bug finden
  • Selbst wenn ihn jemand anderes findet, würde das Zeit kosten
  • Der Anbieter hätte genug zeitlichen Vorsprung, um einen Patch zu schreiben
  • Nachdem ein Patch öffentlich wird, würden Angreifer Tage oder Wochen brauchen, um ihn rückzuentwickeln und einen funktionierenden Exploit zu bauen
• Alle diese Annahmen haben sich als falsch erwiesen, und das 90-Tage-Fenster ist statt eines Schutzmechanismus für Nutzer zu einer Struktur geworden, die Personen mit dem Bug bereits einen 90-tägigen Vorsprung verschafft

Fall 1: 11 Personen melden in 6 Wochen denselben kritischen Bug

• Ende April wurde einem Unternehmen ein schwerwiegender Bug gemeldet, doch das Triage-Team antwortete, dass er bereits im März erstmals gemeldet worden sei und man selbst der 11. Melder sei
• Der Bug funktionierte so, dass ein Angreifer nach einem Kauf auf einer Website eine selbst manipulierte Antwort an den Server zurücksenden konnte und der Server diese mangels Signaturprüfung der Antwort unverändert akzeptierte
  • So konnte man beispielsweise einen Artikel im Wert von 5.000 Dollar für 0 Dollar kaufen oder einen Kauf auch ohne echte Zahlung als abgeschlossen markieren
• Dass 11 verschiedene Personen innerhalb von etwa 6 Wochen denselben kritischen Bug fanden, zeigt ein Muster, bei dem LLM-unterstützte Hunter nahezu gleichzeitig auf dieselbe Schwachstelle konvergieren
• Ein Bekannter aus dem BlueWater CTF hatte schon vor einigen Monaten darauf hingewiesen, dass bei voneinander unabhängigen Reportern und Workflows unter LLM-Unterstützung dieselben Bugs zusammenlaufen
• Auch auf Triage-Seite wurde dasselbe Phänomen beobachtet
  • @d0rsky schrieb, dass bei neuen Schwachstellen binnen weniger Tage Duplicate Reports mit derselben Grundursache eintreffen, angetrieben durch LLM-Prompts, Skills und Automatisierung
  • Wenn Forscher so schnell reproduzieren können, wächst die Sorge, dass Black Hats dasselbe schon vor einem Patch tun können
• Wenn 10 Personen ihn gemeldet haben, kann es weitere geben, die ihn nicht gemeldet haben, und dieselben LLMs stehen nicht nur wohlmeinenden Forschern offen, sondern jedem anderen ebenfalls
• CVE-Credits und Bug-Bounties kann nur eine Person erhalten, sodass die übrigen 9 oder Personen, die gar nicht gemeldet haben, nicht an die 90-Tage-Uhr gebunden sind
• Das 90-Tage-Offenlegungsfenster schützt Nutzer in dieser Situation nicht, sondern verschafft Menschen, die den Bug bereits haben, zusätzliche Zeit

Fall 2: Vom React-Patch zum funktionierenden Exploit in 30 Minuten

• React hat mehrere Sicherheitsprobleme gepatcht und dazu einen öffentlichen Blogpost veröffentlicht
  • CVE-2026-23870
  • CVE-2026-44575
  • CVE-2026-44579
  • CVE-2026-44574
  • CVE-2026-44578
• Es dauerte 30 Minuten, den Patch zu lesen und dagegen für eine lokale Test-App einen funktionierenden Exploit zu bauen
• Beim veröffentlichten Issue handelte es sich um einen Denial-of-Service-Fall (DoS), und die KI übernahm den Großteil des Verständnisses des Diffs, der Identifikation des verwundbaren Code-Pfads und des Schreibens des PoC
• Früher brauchten erfahrene Reverse Engineers Tage bis Wochen, um aus einem öffentlichen Patch einen funktionierenden n-day-Exploit zu machen; dieser Zeitversatz war das Sicherheitsfenster, in dem Administratoren Updates einspielen konnten
• Jetzt können einfache Bugs Minuten und komplexe Bugs Stunden dauern, und erfahrene Reverse Engineers sind keine Voraussetzung mehr
• Man muss davon ausgehen, dass mit Erscheinen des Patches auch ein Exploit existiert, und ein Rollout erst bis zum nächsten Wartungsfenster zu verschieben, passt nicht mehr zur Lage

Fall 3: Copy Fail und Dirty Frag, die nacheinander im Linux-Kernel einschlugen

• In den vergangenen 2 Wochen wurden im Linux-Kernel zwei kritische Schwachstellen direkt hintereinander bekannt; beide hatten öffentliche Exploits und betrafen wichtige Distributionen

• Copy Fail

  • Am 29. April veröffentlichte Xint Code Copy Fail
  • Xint Code ist das Team hinter Theori und wird als Team vorgestellt, das den DEF CON CTF neunmal gewonnen hat
  • Copy Fail ist CVE-2026-31431 und wird als geradliniger Logikfehler im Kernel-Subsystem für Kryptografie beschrieben
  • Es soll ohne Race Condition zu 100 % zuverlässig sein und mit einem 732-Byte-Python-Skript auf allen seit 2017 ausgelieferten Linux-Distributionen Root-Rechte ermöglichen
  • Betroffen sind wichtige Distributionen wie Ubuntu, RHEL, Amazon Linux und SUSE
  • Gefunden wurde es laut eigener Aussage durch einen etwa einstündigen automatisierten Scan des Kernel-Subsystems crypto/ mit KI; die Schwachstelle soll 9 Jahre lang exponiert gewesen sein
  • Die technische Analyse steht im Artikel von Xint
  • Gepatcht wurde es mit dem Mainline-Commit a664bf3d603d, außerdem gab es die Mitigation, das Modul algif_aead zu deaktivieren
  • Danach wurden Hinweise beobachtet, dass iranische Angreifer die Schwachstelle ausnutzten, um Ubuntu-Server zu kompromittieren und als Knoten einer DDoS-Kampagne weiterzuverwenden
  • Es dauerte nur wenige Tage, bis aus einer mit KI gefundenen Kernel-Privilege-Escalation eine öffentliche PoC und die Bewaffnung durch staatliche Akteure wurden

• Dirty Frag

  • Etwa eine Woche später, am 7. Mai, veröffentlichte Hyunwoo Kim(@v4bel) Dirty Frag
  • Dirty Frag ist eine verkettete Schwachstelle aus CVE-2026-43284 und CVE-2026-43500
  • Verkettet werden zwei Schwachstellen in den IPSec-ESP-(esp4/esp6) und RxRPC-Netzwerkmodulen des Kernels
  • Es gehört zur selben Bug-Familie wie Copy Fail und Dirty Pipe und nutzt dieselbe Technik der Page-Cache-Corruption, aber über einen anderen Angriffsweg
  • Dirty Frag funktioniert auch dann, wenn die Mitigation für Copy Fail angewendet wurde
    • Selbst wenn algif_aead auf die Blacklist gesetzt wird, nutzt Dirty Frag dieses Modul nicht
  • Laut Beschreibung ist eine deterministische Eskalation von einem unprivilegierten Nutzer zu Root möglich, und der Exploit funktioniert auf wichtigen Distributionen wie Ubuntu, RHEL 10.1, openSUSE, CentOS Stream, AlmaLinux und Fedora 44
  • Kompilieren und Ausführen sind mit einem Einzeiler möglich

• Offenlegungsprozess von Dirty Frag und Zusammenbruch des Embargos

  • Hyunwoo Kim meldete es am 29. bis 30. April an [email protected] und reichte den Patch öffentlich ein
  • Am 7. Mai wurde mit der Mailingliste linux-distros koordiniert und ein Embargo von 5 Tagen vereinbart
  • Noch am selben Tag veröffentlichte ein unbeteiligter Dritter innerhalb weniger Stunden detaillierte Exploit-Informationen zur ESP-Schwachstelle, wodurch das Embargo brach
  • Nach Rücksprache mit den Maintainers der Distributionen veröffentlichte Hyunwoo die vollständige Analyse von Dirty Frag, den Exploit-Code und einen funktionierenden PoC
  • Zu diesem Zeitpunkt stellte keine einzige Linux-Distribution bereits einen Patch bereit
  • Derzeit gibt es für CVE-2026-43284, also die ESP-Seite, einen Mainline-Fix, während es für CVE-2026-43500, also die RxRPC-Komponente, laut Darstellung noch keinen Upstream-Patch gibt
  • Ubuntu, Red Hat, Tenable und andere haben eigene Advisories veröffentlicht

• Reale Ausnutzung von Dirty Frag

  • Das Microsoft-Defender-Team hat innerhalb von 24 Stunden nach der Veröffentlichung eine begrenzte reale Ausnutzung bestätigt
  • Angreifer sollen SSH-Zugriff erlangt, ELF-Binärdateien verteilt, mit su Root-Rechte erlangt, Authentifizierungseinstellungen verändert, Session-Dateien gelöscht und laterale Bewegungen durchgeführt haben
  • CTS(@gf_256) fasste es mit „responsible disclosure is dead🤦“ zusammen

Was tatsächlich tot ist

• Das 90-Tage-Offenlegungsfenster ist kein reparierbares Problem, sondern ein abgeschlossenes Modell
• Dieses Modell passte zu einer Welt, in der Finder selten waren und Exploit-Entwicklung langsam verlief, aber LLMs machen Finder zahlreicher und Exploit-Entwicklung schneller
• Wenn 10 voneinander unabhängige Personen denselben Bug in 6 Wochen finden und KI ein Patch-Diff in 30 Minuten in einen funktionierenden Exploit umwandeln kann, schützt das 90-Tage-Fenster niemanden mehr
• Bei Copy Fail vergingen von einem KI-Scan bis zu einer öffentlichen PoC und der Bewaffnung durch staatliche Akteure nur wenige Tage
• Bei Dirty Frag brach das Embargo innerhalb von Stunden wegen eines Dritten, der dieselbe Bug-Familie unabhängig gefunden hatte
• In einer Umgebung, in der dieselbe Schwachstelle gleichzeitig und unabhängig durch mehrere Forscher und KI-Tools wiederentdeckt wird, ist koordinierte Offenlegung schwer aufrechtzuerhalten
• Auch der monatliche Patch-Zyklus ist vorbei
  • Das 30-Tage-Fenster zwischen Schwachstelle und Fix setzt voraus, dass Angreifer langsamer sind als der Release-Zug
  • Wenn Microsoft bei Dirty Frag innerhalb von 24 Stunden reale Ausnutzung sieht, ist das monatliche Wartungsfenster keine Sicherheitsreserve mehr, sondern ein Angriffsfenster
• Auch das Warten auf Advisories ist vorbei
  • Während Verteidiger CVE-Beschreibungen lesen, lesen Angreifer git log --diff-filter=M
  • Advisories sind Downstream-Artefakte, das Patch-Diff ist das eigentliche Signal

Wie die Branche ihre Reaktion ändern muss

• Die Schlussfolgerung ist, dass alle kritischen Sicherheitsprobleme als P0 betrachtet und sofort behoben werden müssen
• Nicht „innerhalb von 24 Stunden“, „im nächsten Sprint“ oder „nach der Impact-Bewertung“, sondern auf dem Niveau: alles stehen und liegen lassen und sofort beheben
• Es gibt Gründe, warum Production-Rollouts komplex sind und Change Management brauchen, aber die Bedrohungslage wartet nicht auf Change-Management-Prozesse

• Anbieter

  • Ab dem Moment, in dem ein kritischer Bug-Report eingeht, läuft die Zeit
  • Maßgeblich ist nicht der Zeitpunkt nach abgeschlossener Triage oder der Übergabe an Engineering, sondern der Eingang des Reports selbst
  • Wenn es jemand gemeldet hat, sollte man annehmen, dass 10 andere es bereits haben und mindestens 1 davon nicht wohlgesinnt ist

• Forscher

  • Kritische Bugs sollten nicht lange zurückgehalten werden; stattdessen sollte man auf das kürzestmögliche Offenlegungsfenster drängen
  • Wenn ein Anbieter es nicht innerhalb einer Woche beheben kann, ist das kein Offenlegungsproblem, sondern ein Anbieterproblem
  • Die frühere Höflichkeit, „Zeit zu geben“, ergab Sinn, wenn man der einzige Finder war; heute ist man das wahrscheinlich nicht mehr

• Schwachstellenmanagement

  • Schwachstellenmanagement muss in Echtzeit erfolgen
  • „Wöchentlicher Scan, Triage im Sprint, Patchen nach Zyklus“ gehört zu einer Zeitachse, in der die Angreifer bereits weitergezogen sind
  • Die neue maximale Reaktionszeit für kritische Issues beträgt nicht Tage, sondern Stunden, und selbst das kann noch zu langsam sein

Warum Blue Teams LLMs in die Verteidigungspipeline aufnehmen müssen

• Angreifer haben LLMs bereits in ihre Exploit-Pipeline integriert, und die Verteidiger müssen sich mit derselben Geschwindigkeit bewegen
• Zum Zeitpunkt des Code-Pushs müssen LLMs integriert werden
  • Bei jedem Pull Request, Merge und Deploy sollte eine KI-gestützte Security-Review als Teil der CI-Pipeline laufen
  • Sie sollte wie ein Linter oder Unit Test beim Push ausgeführt werden, nicht als Quartals-Audit oder nachgelagerte Prüfung
  • Schwachstellen müssen abgefangen werden, bevor sie Production erreichen; das Beheben im PR-Review ist viel günstiger als nach einer CVE-Veröffentlichung
• Auch in die Patch-Analyse müssen LLMs integriert werden
  • Wenn eine Upstream-Abhängigkeit einen Security-Patch veröffentlicht, sollte die Pipeline das Diff automatisch holen, die Änderungen analysieren, prüfen, ob die eigene Codebasis betroffen ist, und Alarm schlagen
  • Das muss innerhalb von Minuten nach dem Patch in einem öffentlichen Repository automatisch passieren, statt sich darauf zu verlassen, dass Menschen Mailinglisten lesen und Jira-Tickets anlegen
  • Wenn Xint Code Copy Fail mit einem einstündigen automatisierten Scan fand, sollte man die eigenen Abhängigkeiten auf dieselbe Weise scannen
• Auch beim Dependency Scanning sollten LLMs genutzt werden
  • Die Lieferkette ist nur so stark wie ihre schwächste transitive Abhängigkeit
  • KI-basierte Dependency-Scanner können den Einfluss einer Schwachstelle entlang des Dependency-Trees verfolgen, betroffene Versionen markieren und Upgrade-Pfade vorschlagen
  • Sie sollten kontinuierlich laufen, nicht wöchentlich
• Vor dem Release eines Patches sollte dieser mit KI getestet werden
  • Wenn ein LLM wie im React-Beispiel einen Patch in 30 Minuten in einen Exploit verwandeln kann, müssen Verteidiger dieselben Werkzeuge vor der Veröffentlichung des Patches zuerst einsetzen
  • Man muss prüfen, ob der Patch das Problem tatsächlich behebt und keine neuen Probleme schafft
  • Er sollte auch für das Generieren von Regressionstests und die Suche nach demselben Muster an anderen Stellen der Codebasis genutzt werden
• Das Fenster zwischen „Schwachstelle vorhanden“ und „Schwachstelle wird ausgenutzt“ nähert sich 0, und die Verteidiger müssen mit derselben Geschwindigkeit automatisieren wie die Angreifer
• Mehr Zero-Days werden schneller in realen Umgebungen ausgenutzt werden; Gründe sind dieselben Werkzeuge, geringere Eintrittsbarrieren, mehr Finder und kürzere Zeitachsen
• Die Teams, die diesen Wandel überleben, sind jene, die KI zum erstklassigen Bestandteil ihrer Security-Pipeline machen, bevor sie dazu gezwungen werden

Fazit

• Die Realität, in der ein Systemadministrator das Dirty-Frag-Advisory liest, es noch keinen Patch gibt, der Exploit bereits öffentlich ist, Microsoft reale Ausnutzung meldet und als Mitigation das Deaktivieren des IPSec-Moduls bleibt, während 400 Server angefasst werden müssen, wird zum neuen Standard
• Die 90-Tage-Offenlegungspolitik, der monatliche Patch-Zyklus und die Annahme, dass zwischen Offenlegung und Ausnutzung Zeit liegt, sind alle tot
• Was bleibt, ist die Fähigkeit, sich schnell zu bewegen, stark zu automatisieren und kritische Bugs wie echte Notfälle zu behandeln
• Die KI-Welle, die das alte Modell gebrochen hat, ermöglicht zugleich auch ein neues Modell mit schnellen Patches, automatisierten Scans, Threat Intelligence in Echtzeit und KI-gestützten Code-Reviews
• Die Werkzeuge sind bereits da; entscheidend ist, ob Verteidiger sie vor den Angreifern einsetzen, und derzeit liegen die Angreifer in diesem Rennen vorn

[GN⁺]

Lobste.rs-Meinungen

• Dem muss ich widerwillig zustimmen. Wir haben in unserer Firma zu diesem Thema ebenfalls Untersuchungen durchgeführt, und die Zeit vom Patch bis zum Exploit ist praktisch sofort.

• Die Richtlinie zur verantwortungsvollen Offenlegung war von Anfang an eine Fiktion, bei der alle nur so taten, als würden sie einander aus Höflichkeit vertrauen. Schon immer war es eher etwas, dem man sich der Stimmung entsprechend anschloss, und Tools zur Schwachstellenfindung auf LLM-Basis haben diese Realität nur offengelegt.

• Es ist ziemlich ironisch, dass auch dieser Text selbst nach LLM riecht

  • Klingt plausibel. Wenn man eine originelle Idee hat, muss man sie veröffentlichen, bevor es jemand anderes tut. Kritisches Denken und Selbstreflexion sind tot, und wenn man einen Gedanken nicht innerhalb von 39 Minuten in einen Blogpost gießt, macht es jemand anderes zuerst :P
  • Für mich wirkt es nicht so. Diesen Schreibstil gab es schon in technischen Texten vor LLMs seit Langem, und die großen LLMs schreiben normalerweise eher etwas anders als dieser Text
  • Liest sich wie angstschürende Werbung
  • Ob gut oder schlecht, so läuft es jetzt wohl einfach

• Vielleicht ist das, was wirklich tot ist, das Zeitalter von handgefertigten, kunsthandwerklich anmutenden Boutique-C-Programmen für mission-kritische Einsätze