KI-generierte Bug-Reports: Curl pausierte Annahme einen Monat

KI-generierte Bug-Reports haben bei curl ein Volumen erreicht, das die Maintainer um Daniel Stenberg nicht mehr bewältigen konnten. Weil die Zahl der Sicherheitsmeldungen jede Prüfkapazität überstieg, setzte das Projekt die Annahme von Reports für gut einen Monat aus – vom 1. Juli 2026, 0 Uhr MESZ, bis zum 3. August 2026, 9 Uhr MESZ. Betroffen war das Bug-Bounty-Programm auf HackerOne ebenso wie eine projekteigene E-Mail-Adresse, über die ohnehin keine Meldungen angenommen werden. Wer den Vorgang heute liest, liest einen Rückblick: Die Pause ist vorbei, der Mechanismus dahinter nicht.

KI-generierte Bug-Reports: Zeitraum, Umfang und eine selbstironische Überschrift

Stenberg nannte die Maßnahme „curl’s Sommer voller Glückseligkeit". Ziel sei es gewesen, „tief durchzuatmen und den Sommer zu genießen" – und das, obwohl die Wartungsarbeit weiterlief: Kunden mit einem kostenpflichtigen Supportvertrag sollten nach seiner Aussage auch im Juli betreut werden.

Der Anlass war eine reine Mengenfrage. Im Schnitt war während der Pause eine Sicherheitsmeldung pro Tag zu bearbeiten, fünfmal so viel wie noch im Jahr 2024. Einzelne Angaben zum Anstieg liegen bei vier- bis fünfmal dem Stand von 2024. Entscheidend für die Bewertung ist, wie diese Reports aussehen: Es handelt sich nicht um offensichtlichen Unsinn, sondern um detaillierte, ausführliche Beschreibungen. Ein Filter, der auf „erkennbarer Blödsinn" setzt, greift hier nicht mehr.

Das Muster ist auch deshalb bemerkenswert, weil curl zuvor einen anderen Weg versucht hatte – und gescheitert ist.

Von AI-Slop zu plausiblen Reports: Warum die Flut nicht mehr zu filtern ist

Bereits im Mai 2025 war das Prämienprogramm mit KI-generierten Einsendungen überflutet. Drohungen mit Sperren zeigten keine Wirkung. Was folgte, war keine Beruhigung, sondern eine Verschiebung: Stenberg beschreibt „an ever-increasing amount of really good security reports, almost all done with the help of AI" – also stetig mehr fachlich gute Berichte, die fast alle mit KI-Unterstützung erstellt wurden.

Technisch erklärt das den Aufwand. Ein eingegangener Report muss reproduziert, auf die betroffene Version eingegrenzt, gegen bekannte und längst geschlossene Fälle abgeglichen, in seiner Auswirkung bewertet und im Ernstfall in Patch plus Advisory überführt werden. Diese Kette lässt sich nicht abkürzen, ohne die Verlässlichkeit der Bibliothek zu beschädigen. Ein offensichtlich falscher Report kostet Minuten, ein sauber formulierter und plausibler Report Stunden – gerade weil er nicht sofort als unbrauchbar erkennbar ist. Die Last verschiebt sich damit von „Ist das Unsinn?" zu „Ist das echt, und wenn nicht, warum sieht es so aus?".

Diese Einordnung ist eine Beschreibung des Mechanismus, keine erhobene Statistik über Fehlerquoten.

Bug-Bounty-Aus zum 31. Januar 2026 – und die Rückkehr zu HackerOne

Die Eskalation lässt sich an wenigen Daten festmachen. Mit dem Commit-Titel „BUG-BOUNTY.md: we stop the bug-bounty end of Jan 2026" beendete curl das Bug-Bounty-Programm zum 31. Januar 2026. Die Begründung galt dem „current torrent of submissions": Man wollte den Anreiz für „crap and non-well researched reports" entfernen. Wie massiv die Lage war, zeigt eine Woche mit sieben HackerOne-Reports innerhalb von 16 Stunden; einige betrafen echte Fehler, aber keine Sicherheitslücken. Bis zum damaligen Redaktionsschluss waren 2026 insgesamt 20 Submissions bearbeitet.

Rund vier Wochen später kehrte curl zu HackerOne zurück – nicht aus Überzeugung, sondern aus Mangel an Alternativen: GitHub bot keine geeigneten Verwaltungsfunktionen, Mails wurden unverschlüsselt zugestellt, wertlose Meldungen ließen sich nicht löschen. „Dieses Hin und Her ist bedauerlich, aber wir tun es mit den besten Vorsätzen", so Stenberg. Geld für Prämien gibt es seither nicht mehr; der „inflow tsunami" sei ausgetrocknet, die Furcht vor seiner Rückkehr aber nicht. Stenberg verteidigt zugleich das öffentliche Bloßstellen von Einsendern: Man solle „niemals einen Bug oder eine Schwachstelle melden, wenn man ihn nicht wirklich versteht – und reproduzieren kann". Er räumt ein, dass es sich oft um gutgläubige, fehlgeleitete Menschen handelt.

Was Admins und IT-Entscheider jetzt prüfen sollten

Die Überlastung durch Meldungen ist kein Beleg für eine offene Schwachstelle in curl. Es gibt keinen Hinweis darauf, dass eine konkrete Lücke ungepatcht geblieben wäre. Das Risiko liegt indirekt: Wenn Prüfkapazität in Triage fließt, fehlt sie bei Entwicklung und bei der Bearbeitung echter Meldungen. Bei einer Bibliothek, die in „dutzenden Milliarden Geräten" steckt, während die Zahl der Geldgeber „extrem überschaubar" bleibt, ist das ein struktureller, kein punktueller Effekt.

Konkret heißt das:

Meldeweg vom Anreiz entkoppeln. Prüfen Sie, an welchem Kanal Ihr Patch-Prozess hängt. Wenn er an einem Bounty-Programm klebt, sichern Sie die Zustellung von Advisories und Release Notes unabhängig davon ab.
Bestand erfassen. Ermitteln Sie, welche curl- und libcurl-Versionen in Container-Images, Appliances und Build-Abhängigkeiten stecken – die Lastverschiebung trifft zuerst die, die ihre Version nicht kennen.
Interne Meldungen filterbar machen. Pflichtfelder für betroffene Version, Reproduktionsschritte sowie erwartetes und tatsächliches Verhalten sind der billigste Filter, der auch bei sorgfältig formulierten Reports funktioniert. Planen Sie Triage-Zeit als Personalbudget.
Wartung finanzieren. Wer auf Open-Source-Bibliotheken aufbaut, sollte deren Wartung unterstützen, statt Meldekanäle als kostenlose Qualitätssicherung zu behandeln.

Die eigentliche Nachricht ist nicht die einzelne Pause, sondern ihre Ursache: KI senkt die Kosten des Meldens nahezu auf null, während die Kosten des Prüfens vollständig beim Empfänger bleiben. Jedes Verfahren, das auf Mengenbegrenzung durch Aufwand setzt, kippt unter dieser Verschiebung – ein Bounty-Anreiz verstärkt sie sogar. Wer Sicherheitsprozesse auf Open-Source-Basis plant, sollte diese Asymmetrie als dauerhafte Randbedingung einkalkulieren und nicht als Ausnahmefall eines einzelnen Projekts.

Quellen