Zehn Minuten vom Patch zum Angriff

Anil Madhavapeddy pflegt cohttp, die HTTP-Bibliothek für OCaml. Am 28.08.2026 hat er einen Path-Traversal-Fix veröffentlicht und dabei etwas dokumentiert, das jeder kennen sollte, der Software wartet oder Sicherheitsprozesse aufsetzt.

Der Ablauf

Der Bugreport kam privat über einen Slack-Kanal, gefunden hatte ihn ein Modell. Vor dem Fix setzte Madhavapeddy seinen eigenen Agenten auf den Code, mit nichts als der groben Richtung "sieh dir die Pfadnormalisierung an". Kein CVE-Text, keine Zeilennummer.

Das Ergebnis ist der Kern des Beitrags: Der Agent fand mehrere verwandte Probleme und baute in unter einer Minute einen lauffähigen Exploit gegen einen lokalen Server.

Den Fix machte er als Pull Request öffentlich, um mehr Augen darauf zu bekommen. Übliches Vorgehen. Etwa zehn Minuten später standen in den Logs seines Webservers Proben nach prozentkodierten Traversal-Sequenzen, also nach genau dem Muster, das der PR behebt.

Seine eigene Einordnung dazu ist die unbequemste Stelle: Wenn er selbst eine Minute für den Exploit brauchte, seien zehn Minuten für automatisierte Angreifer eigentlich langsam.

Ein Detail, das im Beitrag untergeht, macht es noch schärfer. Der Pull Request wurde am 14.08.2026 geöffnet, veröffentlicht und geschlossen wurde die Sache erst zwei Wochen später. So lange stand der Fix öffentlich lesbar da, mit allem, was ein Scanner daraus ableiten kann, ohne dass Nutzer eine gefixte Version installieren konnten.

Warum das Embargo nicht mehr trägt

Das klassische Verfahren beruht auf einer Annahme: Solange die Details geheim bleiben, sind Nutzer geschützt. Genau diese Annahme greift nicht mehr, wenn ein Agent mit einer groben Suchrichtung selbst recherchiert.

Madhavapeddy belegt das mit der Arbeit von Fang et al.: Ein GPT-4-Agent nutzte 87 Prozent eines Benchmarks aus 15 Lücken aus, wenn er die CVE-Beschreibung bekam, und nur 7 Prozent ohne. Der Beschreibungstext war damals der entscheidende Hebel. Heute reicht weniger davon.

Die Zahlen, die er aus Vulncheck-Daten anführt, zeigen die Richtung:

Ein negativer Wert heißt: Die Ausnutzung geht dem Patch im Schnitt voraus. Dazu zwei konkrete Fälle, beide aus diesem Jahr: Bei marimo (CVE-2026-39987) lagen zwischen Advisory und erstem Ausnutzungsversuch 9 Stunden, obwohl kein öffentlicher Proof of Concept existierte. Bei Langflow (CVE-2026-33017) waren es 20 Stunden.

Was als Auslöser reicht, listet er selbst auf: eine Frage auf einer Mailingliste, ein auffälliger Commit in einem verwaisten Branch, ein Kontextleck. Nicht der Exploit muss durchsickern, nur die Vermutung, wo einer stecken könnte.

Die Asymmetrie, die daraus folgt

Eine Arbeit von Pesoli et al. aus dem Mai 2026 nennt das "bugonomics" und benennt den Engpass klar: nicht das Finden, sondern der "defender remediation throughput". Modelle erzeugen Funde am laufenden Band, aber Triage, Validierung und Release-Kapazität der Maintainer bleiben, wo sie waren.

Madhavapeddy beschreibt aus der eigenen Praxis eine "unsustainable surge of activity", und dass niemand genau sagen kann, wie viel der eingehenden Meldungen maschinell erzeugt ist. Ein Detail dazu ist bemerkenswert: Sein kommerzielles Modell verweigerte die Analyse der eigenen Bibliothek wegen einer Sicherheitssperre, weil er keinen Zugang zum Anthropic-Programm Glasswing hat. Ein offenes Modell hatte diese Sperre nicht und half. Die Schutzmechanismen der Anbieter treffen also zuerst den Maintainer, der sein eigenes Projekt absichern will, und nicht den Angreifer, der auf ein Modell ohne Sperre ausweicht.

Das passt zum zweiten Fund dieses Tages: Mit GLM-5.3 liegen seit gestern die Gewichte eines Modells offen, das im Lückenfinden auf Augenhöhe mit den kommerziellen Spitzenmodellen ist und keine Nutzungsbedingungen kennt.

Was das für euch heißt

Das ist die Fortsetzung von KI findet Lücken schneller, als wir patchen, diesmal aber nicht aus der Statistik, sondern aus den Serverlogs eines einzelnen Maintainers.

Wenn ihr Software betreibt: Die Zeit zwischen Advisory und Angriff ist keine Woche mehr, sondern Stunden. Ein Patch-Fenster, das darauf baut, "am nächsten Wartungstermin" einzuspielen, ist bei internetseitigen Diensten keine Strategie mehr. Wichtiger als schnelles Patchen aller Dinge ist zu wissen, welche eurer Dienste überhaupt exponiert sind. Diese Liste sollte man haben, bevor man sie braucht.

Wenn ihr Software veröffentlicht: Der öffentliche Fix-PR ist der Startschuss, nicht der Schlusspunkt. Genau das zeigt dieser Fall: zwischen öffentlichem PR und Release lagen zwei Wochen, in denen die Information draußen war und die Lösung nicht. Praktisch heißt das, Fix, Release und Advisory so eng wie möglich zusammenzulegen und den PR erst öffentlich zu machen, wenn der Release daran hängt.

Wenn ihr Lücken meldet: Wir machen das mit KIberschutz selbst, und dieser Beitrag beschreibt die Zwickmühle genau. Verantwortungsvolle Offenlegung setzt darauf, dass ein Projekt in Ruhe fixen kann. Diese Ruhe gibt es nicht mehr in dem Maß, in dem es sie gab. Die Konsequenz ist aber nicht, das Verfahren aufzugeben, sondern die Erwartungen anzupassen: Ein Fix, der Monate im Draft-Status liegt, ist heute ein eigenes Risiko. Wer meldet, sollte das mitdenken und Maintainern die Arbeit so weit wie möglich abnehmen, mit fertigem Patch statt nur mit einem Befund.

Denn der Befund von Pesoli et al. bleibt der wichtigste: Finden ist billig geworden, Beheben nicht. Wer helfen will, sollte auf der teuren Seite helfen.