Curl beendet Bug-Bounty-Programm auf HackerOne: Konsequenzen von KI-Spam für die Cybersicherheit

CyberSecureFox 🦊

Der Gründer und Lead-Entwickler von Curl, Daniel Stenberg, hat die schrittweise Beendigung der Bug-Bounty-Programme für Curl und libcurl auf HackerOne angekündigt. Auslöser ist ein massiver Anstieg an schwach begründeten Schwachstellenmeldungen, von denen ein erheblicher Teil nach seiner Einschätzung mit Hilfe generativer KI erstellt wurde. Der Vorgang gilt als warnendes Beispiel dafür, wie KI-unterstützter Spam die Wirtschaftlichkeit klassischer Bug-Bounty-Modelle gefährden kann.

Rolle von Curl und libcurl in der Open-Source-Sicherheit

Curl und libcurl gehören zu den am weitesten verbreiteten Open-Source-Komponenten im Internet. Die Bibliothek wird in Betriebssystemen, Embedded-Systemen, mobilen Apps, Unternehmenssoftware und Cloud-Diensten eingesetzt, um HTTP, TLS und zahlreiche weitere Protokolle zu sprechen. Entsprechend hoch ist die sicherheitstechnische Relevanz: Schwachstellen in libcurl können ganze Lieferketten und IoT-Landschaften betreffen.

Vor diesem Hintergrund ist ein effizienter, verlässlicher Prozess zur Meldung und Behandlung von Sicherheitslücken zentral. Störungen in diesem Prozess – etwa durch unbrauchbare Meldungen – wirken sich nicht nur auf ein Projekt, sondern potenziell auf eine große Anzahl von Produkten und Diensten aus, die auf Curl basieren.

Abschaltung auf HackerOne: Zeitplan und Beweggründe

Die Bug-Bounty-Programme für Curl und libcurl auf HackerOne laufen bis zum 31. Januar 2026 weiter. Bis zu diesem Datum eingereichte Tickets werden noch geprüft und sauber abgeschlossen. Ab dem 1. Februar 2026 nimmt das Projekt dort keine neuen Meldungen mehr an und wechselt vollständig zu einer direkten Responsible-Disclosure-Strategie über GitHub.

Stenberg begründet diesen Schritt damit, dass der finanzielle Anreiz der Bug-Bounty-Plattform inzwischen einen breiten Strom oberflächlicher oder falscher Meldungen auslöse. Ob diese Berichte per KI generiert oder manuell geschrieben sind, sei zweitrangig – entscheidend sei, dass sie keine verwertbaren Sicherheitsinformationen enthalten, aber erhebliche Ressourcen im Maintainer-Team binden.

AI Slop: Wenn KI-generierte Reports die Signal-Rausch-Verhältnisse kippen

Bereits 2024 beobachtete das Curl-Team laut Stenberg, dass rund 20 % aller Meldungen mit Hilfe von KI erstellt wurden. Gleichzeitig sank die Validitätsquote drastisch: Nur noch etwa 5 % der eingereichten Reports beschrieben tatsächlich echte Schwachstellen. Dieses Muster passt zu Beobachtungen anderer Programme, wonach generative KI zwar schnell Berichte produzieren kann, aber ohne fundierte Expertise häufig nur bekannte Informationen variiert oder falsche Annahmen formuliert.

Der wirtschaftliche Effekt ist klar: Die Erstellung von Pseudo-Reports ist nahezu kostenlos, während die Verifikation jedes einzelnen Berichts qualifizierte Sicherheitsarbeit erfordert. Sicherheitsplattformen wie HackerOne oder Bugcrowd weisen seit einigen Jahren darauf hin, dass die Qualitätssicherung und Triagierung zum zentralen Kostenfaktor von Bug-Bounty-Programmen geworden ist.

Begrenzte Ressourcen: Siebenköpfiges Team unter Dauerlast

Das Security-Team von Curl besteht aus lediglich sieben Personen. Jeder Report erfordert typischerweise die Prüfung durch drei bis vier Reviewer und beansprucht zwischen 30 Minuten und drei Stunden. Im Januar 2026 erreichte die Belastung einen kritischen Punkt: Innerhalb von 16 Stunden gingen sieben neue Meldungen über HackerOne ein, und bis zur Monatsmitte wurden über 20 Berichte geprüft – keiner davon enthielt eine valide Schwachstelle.

Solche Zahlen verdeutlichen, wie schnell ein kleines Open-Source-Team durch schlecht qualifizierte Meldungen überfordert werden kann. Neben technischen Risiken rücken hier auch Aspekte wie Burn-out-Gefahr und mentale Belastung der Maintainer in den Fokus, ein Thema, das beispielsweise auch die OpenSSF und die Linux Foundation in ihren Studien zu Open-Source-Sicherheit adressieren.

Neue Sicherheitsstrategie: Direktmeldungen via GitHub und angepasste security.txt

Ab Februar 2026 setzt Curl auf eine direkte Responsible-Disclosure-Methode über GitHub. Sicherheitsforscher sollen ihre Funde unmittelbar an die Maintainer melden, ohne den Umweg über eine Bug-Bounty-Plattform. Für seriöse Forscher reduziert dies bürokratische Hürden, nimmt aber zugleich den monetären Anreiz aus dem Prozess.

In den vergangenen Jahren wurden über HackerOne und die Initiative „Internet Bug Bounty“ für Curl und libcurl insgesamt mehr als 90.000 US‑Dollar für 81 bestätigte Schwachstellen ausgeschüttet. Die Abkehr von dieser Praxis markiert eine klare Schwerpunktverlagerung: weg von der Monetarisierung des Bug-Findens, hin zu partnerschaftlicher Zusammenarbeit für die Stabilität der Open-Source-Ökosysteme.

Parallel dazu wurde die Datei security.txt des Projekts überarbeitet. Darin stellt Curl klar, dass keine finanziellen Belohnungen mehr gezahlt und auch keine Kompensationen durch Dritte vermittelt werden. Zudem wird angekündigt, dass Absender klarer Spam- oder Copy-&-Paste-Reports blockiert und im Zweifel öffentlich gemacht werden können – ein bewusst scharf formulierter Versuch, unqualifizierte Massenmeldungen zu entmutigen.

Konsequenzen für Sicherheitsforscher und Bug-Bounty-Plattformen

Für professionelle Sicherheitsforscher bedeutet dieser Kurswechsel, dass die Zusammenarbeit mit Curl stärker auf Reputation, technische Qualität und nachhaltige Ökosystem-Sicherheit ausgerichtet sein wird. Wer weiterhin seriöse, reproduzierbare Proof-of-Concepts liefert, behält einen direkten Kanal zu den Maintainers, auch ohne Bounty.

Für Bug-Bounty-Plattformen stellt der Fall Curl ein Risikoszenario dar: Wenn hochkritische Open-Source-Projekte aussteigen, verlieren die Plattformen an Attraktivität und müssen ihre Qualitätskontrollen, Filtermechanismen und Zugangsbeschränkungen nachschärfen, um ähnliche Abwanderungen zu verhindern.

Lehren für Bug-Bounty-Programme im KI-Zeitalter

Die Entwicklung rund um Curl zeigt exemplarisch, wie KI-generierte Schwachstellenmeldungen („AI slop“) das Gleichgewicht von Aufwand und Nutzen kippen können. Jede Meldung benötigt gründliche Analyse, Reproduktion und Risikoabschätzung, während KI-Tools binnen Sekunden beliebig viele scheinbar professionelle Reports erzeugen können.

Organisationen, die eigene Bug-Bounty- oder Vulnerability-Disclosure-Programme betreiben, sollten deshalb:

  • Strenge Mindestanforderungen an Reports definieren (klare Impact-Beschreibung, reproduzierbare Schritte, PoC-Code, Versionen).
  • Mehrstufige Programme einführen, bei denen nur verifizierte Forscher Zugang zu den lukrativen Bereichen erhalten.
  • Automatisierte Vorfilter und KI-gestützte Plausibilitätsprüfungen einsetzen, um offenkundigen Spam auszuschließen.
  • security.txt und Responsible-Disclosure-Policies regelmäßig aktualisieren und transparent kommunizieren.

Die Entscheidung von Curl macht deutlich, wie begrenzt die Ressourcen selbst hochkritischer Open-Source-Projekte sind. Unternehmen und Behörden, die auf Curl und ähnliche Komponenten setzen, sollten ihre eigenen Sicherheitsprozesse überprüfen, Bug-Bounty-Programme kritisch neu justieren und Teams darin schulen, KI-Tools so einzusetzen, dass sie Analysequalität erhöhen statt Rauschen produzieren. Wer diese Signale ernst nimmt, kann seine Vulnerability-Management-Strategie robuster gestalten und damit die eigene Angriffsfläche wie auch die Stabilität der Open-Source-Supply-Chain nachhaltig stärken.

Schreibe einen Kommentar

Diese Website verwendet Akismet, um Spam zu reduzieren. Erfahre, wie deine Kommentardaten verarbeitet werden.