Nur das Gerücht eines Bugs genügt, um einen Exploit zu finden

Just the rumour of a bug is enough to find an exploit these days

Nur das Gerücht eines Bugs genügt, um einen Exploit zu finden

Anil Madhavapeddy, Maintainer der OCaml-Bibliothek cohttp, veröffentlichte einen Sicherheits-Patch für eine Path-Traversal-Schwachstelle. Minuten nach dem Öffnen des öffentlichen PRs beobachtete er Sonden in seinen Server-Logs, die genau das Bug-Muster nutzten. Er zeigt, dass LLM-gestützte Systeme allein aufgrund vager Hinweise Exploits generieren können, und argumentiert, dass traditionelle Embargo-Strategien wirkungslos sind. Er fordert neue Ansätze wie private Patch-Entwicklung, kontinuierliche Releases und proaktive Schutzmechanismen auf Protokollebene.

Die Frage ist nicht, ob Frontier-Modelle, Open-Weight-Modelle oder Programmanalyse "gewinnen". Die Frage ist, wie man sie orchestriert, damit knappe Validierungs-, Priorisierungs- und Release-Kapazitäten in dauerhafte Fixes fließen statt in mechanische Suche und Berichtsentwürfe.
  1. nickcw

    Das beschreibt mein Leben als Open-Source-Maintainer im Moment genau!

    In den ersten 10 Jahren des rclone-Projekts haben wir etwa 20 Sicherheitsmeldungen über GitHub erhalten. Im letzten Monat mussten wir uns mit über 40 befassen! Das hat eine enorme Menge meiner Zeit in Anspruch genommen, selbst mit KI-Tools zum Triage und zur Erstellung von Fixes zur Überprüfung.

    Die Trefferquote bei diesen Sicherheitsmeldungen ist ziemlich gut – etwa 75 % davon enthalten einen Kern von etwas, das untersucht werden muss. Die Konfigurationen für rclone sind zunehmend unwahrscheinlicher geworden, also hoffe ich, dass sie irgendwann versiegen.

    Ich habe erwogen, die Fixes direkt in master zu mergen, nur um mir das Leben zu erleichtern, anstatt ein Dutzend unabhängige Sicherheitsfixes auf Branches zu halten und sie beim Point-Release zu mergen und zu hoffen, nicht zu viele Konflikte beheben zu müssen. Ich habe mich entschieden, vorerst beim Prozess zu bleiben.

    GitHub vergibt CVEs für die Advisories. Vor der KI-Apokalypse dauerte die Zuweisung 2-3 Tage, aber jetzt dauert sie 3-4 Wochen, also muss ich die Point-Releases mit CVE-PENDING im Changelog herausgeben, was nicht ideal ist.

    Ich bin mir nicht sicher, was die Lösung ist, aber es ist definitiv ein Problem für uns.

  2. godelski

    Es ist einfacher, Bugs zu finden und zu beheben, aber der Wille ist geringer denn je. Meine Chefs wollen nur Geschwindigkeit und halten mir eine 30-minütige Vorlesung darüber, warum ich einen Bug nicht lösen muss, den Claude in 5 Minuten gelöst hat, den ich verifiziert habe und der bereits in einem offenen PR ist. Währenddessen bringen wir immer schneller Bugs heraus.

    Egal wie gut KI beim Beheben von Bugs wird, wir werden sie nie beheben, wenn es keinen Willen gibt, Dinge zu beheben. Software wird nie gut sein, wenn es keinen Willen gibt, gute Software zu machen. Das Problem war schon immer der Wille. Zu viele bessere Produkte. Es ist verrückt, dass wir in einer Zeit, in der wir bei Geschwindigkeit und Qualität besser sein könnten, immer noch Geschwindigkeit wählen und uns einreden, es sei Velocity.

  3. bri3d

    Ich glaube nicht, dass das mit LLMs neu ist (einen Exploit aufgrund einiger beiläufiger Worte zu finden war schon immer ein unterhaltsamer Teil der Exploit-Entwicklung), aber es wurde skaliert und demokratisiert zur Massenausbeutung von Zielen mit geringem Wert. Exploit-PoCs aus Patches, Commit-Messages und zufällig gehörten oder überlesenen Sätzen abzuleiten, ist eine Praxis, die so alt ist wie die Schwachstellenforschung. Der Unterschied bei LLMs besteht darin, dass eine Explosion von Akteuren, die "qualifiziert genug" sind (menschlich oder nicht), es schlampigen / wenig qualifizierten "das ganze Internet ausnutzen"-Akteuren ermöglicht hat, wie nie zuvor.

    Ich stimme den Ideen des Autors jedoch zu; die meisten davon sind Dinge, die viel früher hätten getan werden sollen, und ich denke, es ist in gewisser Weise gut, dass es jetzt einen zwingenden Faktor gibt.

  4. stephbook

    Ich denke, Rollout und Deployment sind noch größere Probleme. Wer aktualisiert seinen Software-Stack innerhalb von 10 Minuten? Die meisten CI-Läufe dauern länger, um zu verifizieren, dass die Geschäftslogik noch funktioniert.

    Hinzu kommt die Gefahr von Supply-Chain-Angriffen, bei denen man nicht einmal automatische Updates möchte.

  5. rndhouse

    Ich habe ein Tool gebaut, das Commits überwacht und versucht, stille Bugfixes zu erkennen. Mit GPT-5.5-Klasse-Modellen kann es zuverlässig Fixes identifizieren, die in ansonsten routinemäßigen Commits versteckt sind. Es ist schwierig, die Codeänderungen genug zu verschleiern, um die Erkennung zu vermeiden.

    Ich habe von mindestens einem Projekt (c-lightning?) gehört, das vorübergehend eine Closed-Source-Binärdatei als Workaround veröffentlicht hat, bis Benutzer sicher aktualisieren konnten.

  6. ChrisMarshallNY

    Traurigerweise scheint die Lehre daraus zu sein, seine Repos privat zu halten.

    Ich bin kein Fan davon, aber ich denke, viele Leute werden das daraus mitnehmen.

  7. jameshart

    Ich frage mich, wie hoch die Trefferquote im Allgemeinen ist, wenn Claude einen erfolgreichen Exploit findet, wenn es mit einem Gerücht aufgefordert wird, das es zu der Annahme führt, dass der Bug vorhanden ist.

    "Mir wurde gesagt, es gibt einen Path-Traversal-Exploit in diesem Paket. Kannst du ihn finden?" – wahrscheinlich eine ziemlich hohe Chance, einen zu finden, selbst wenn man sich das Gerücht nur ausgedacht hat.

  8. janpeuker

    Ich verstehe die Angst vor neuen Bugs, aber ehrlich gesagt fürchte ich mehr, dass es in ein paar Jahren so billig ist, mittlere bis hohe Sicherheitsbugs zu beheben, dass Lowkey-Hacking und das Finden besorgniserregender Datenschutzverletzungen für Bürger unerschwinglich teuer werden.

Mehr von diesem Tag

2026-08-28