Alle Depeschen

DepescheSicherheitneu

Zehn Minuten vom Patch-Hinweis zum Angriffsversuch – ein OCaml-Maintainer erklärt Sicherheits-Embargos für gescheitert

Anil Madhavapeddy, Informatikprofessor in Cambridge und Kern-Betreuer des OCaml-Compilers, hat am 22. August 2026 beschrieben, wie kurz die Frist zwischen einem öffentlichen Hinweis auf eine Lücke und dem ersten Angriffsversuch inzwischen ist. Nachdem er den Pull Request zu einem Pfad-Traversal-Fehler in cohttp 6.3.0 (Advisory OSEC-2026-16) öffentlich gemacht hatte, fing seine Website „within about ten minutes (!)“ Sondierungen nach prozent-kodierten Traversal-Sequenzen ab. Seine Schlussfolgerung: Das übliche Verfahren, eine Lücke bis zum Patch unter Embargo zu halten, beruht auf einer Annahme, die nicht mehr trägt.

Aussagen gegen die Quellen geprüft · 29. August 2026

Der Ablauf in Madhavapeddys eigenen Worten: Den Ausnutzungscode brauchte er nicht selbst zu schreiben – „My agent also trivially created an exploit to probe a local live server in under a minute.“ Aufschlussreich ist, welches Modell dabei mitspielte und welches nicht: „Fable frustratingly refused outright due to its security block since I don’t have access to Glasswing, but DeepSeek V4 Pro obliged me and independently turned up several related issues.“ Das offene Modell fand also nicht nur die eine Lücke, sondern gleich mehrere verwandte – während das kommerzielle Modell mit Sicherheits-Sperre abwinkte.

Dass es kein Einzelfall ist, belegt er mit zwei weiteren Fällen: „marimo’s CVE-2026-39987 went from advisory to first exploitation attempt in 9 hours, even with no public proof-of-concept in existence. Langflow’s CVE-2026-33017 took 20 hours.“ Der Zusatz ist der Kern der These – es existierte kein öffentlicher Machbarkeitsnachweis, aus dem sich der Angriff hätte abschreiben lassen. Als Beleg für die zugrundeliegende Fähigkeit zitiert er die Studie von Fang und Kollegen: „when given a CVE description, their GPT-4 agent exploited 87% of a 15-vulnerability benchmark, and without the description, just 7%.“ Die Beschreibung allein macht hier den Unterschied zwischen 7 und 87 Prozent.

Die andere Seite derselben Entwicklung ist der Meldungsstau bei den Betreuern. Nick Craig-Wood, Autor von rclone, schildert in der Hacker-News-Diskussion zu dem Beitrag: „In the first 10 years of the rclone project we received about 20 security disclosures through GitHub. We had to deal with over 40 in the last month!“ Die Qualität sei dabei nicht schlecht – „about 75% of them have a nugget of something which needs looking at“ –, aber die Aufarbeitung koste ihn „a huge amount of my time, even using AI tools to triage and come up with fixes for review“. Als Folgeschaden nennt er die CVE-Vergabe: „Before the AI apocalypse they took 2-3 days for an assignment but now it they are running at 3-4 weeks“, weshalb er Wartungsreleases mit „CVE-PENDING“ im Changelog ausliefern muss.

⚠️ Einordnung: Es handelt sich um Einzelbeobachtungen zweier namentlich bekannter Open-Source-Betreuer, nicht um eine systematische Erhebung – weder die Zehn-Minuten-Angabe noch die rclone-Zahlen sind unabhängig nachgemessen, und Craig-Woods Angaben sind eine Selbstauskunft über sein eigenes Projekt. Wie viele der über 40 Meldungen tatsächlich agentengestützt entstanden sind, sagt er nicht. Belastbar ist dagegen die Richtung, in die beide Berichte zeigen, und sie deckt sich mit dem, was Anthropic in eigenen Versuchen mit koordinierenden Agentenschwärmen gemessen hat.