Um KI-generierte Bug-Bounty-Meldungen zu triagieren, ziehen Sie fünf Hebel in dieser Reihenfolge: (1) KI-gestützte Vorfilterung, die halluzinierte Funktionen und fehlende Proof-of-Concepts automatisch markiert, bevor ein Mensch die Meldung überhaupt liest, (2) Rate Limiting bereits bei der Annahme, damit ein einzelner Akteur die Warteschlange nicht fluten kann, (3) Reputationsbewertung, die bestätigten KI-Spam bestraft, (4) SLA-Tracking, das die knappe Zeit der Prüfer schützt, und (5) Prämien, die für Wirkung zahlen, nicht für die Zahl der Einreichungen. Die Programme, die 2026 gestorben sind, hatten kein Spam-Problem. Sie hatten ein Triage-Problem.

Wenn Sie ein `security.txt`-Postfach, ein Vulnerability Disclosure Program (VDP) oder ein Bug-Bounty betreiben, spüren Sie es längst. Das Einreichungsvolumen steigt, und die Quote valider Meldungen bricht ein. Jede plausibel klingende, aber gefälschte Meldung kostet eine erfahrene Entwicklerin oder einen erfahrenen Entwickler trotzdem 30 Minuten bis drei Stunden, um sie zu widerlegen. Das ist das Problem „Betrieb unter Last": nicht „sollten wir ein VDP haben" (sollten Sie, und wir haben beschrieben, [wie man eines aufsetzt](/blog/how-to-set-up-vulnerability-disclosure-program)), sondern „die Warteschlange ersäuft, wie halten wir sie am Leben, ohne die Prüfer auszubrennen oder die echten Forscher zu verlieren?"

## Die Opfer von 2026: curl, HackerOne und Nextcloud

In der ersten Jahreshälfte 2026 sind drei der glaubwürdigsten Namen im Vulnerability Disclosure sichtbar unter dem KI-generierten Rauschen eingeknickt. Das sind keine Randprogramme. Es sind die Referenzimplementierungen dafür, wie man Disclosure richtig macht, und sie alle sind gegen dieselbe Wand gelaufen: Die Kosten, eine gefälschte Meldung zu produzieren, fielen auf nahezu null, während die Kosten, sie zu widerlegen, menschlich und hoch blieben.

### Warum curl den Stecker gezogen hat

curl hat sein HackerOne-Bug-Bounty zum **31. Januar 2026** eingestellt. Gründer Daniel Stenberg hatte den Niedergang über Monate dokumentiert. In seinem Beitrag „Death by a thousand slops" vom Juli 2025 berichtete er, dass **rund 20 % aller Einreichungen von 2025 KI-Spam waren** und dass sich **nur etwa 5 % der Einreichungen von 2025 als echte Schwachstellen herausstellten** – ein steiler Absturz gegenüber den Vorjahren (Quelle: [daniel.haxx.se](https://daniel.haxx.se/blog/2025/07/14/death-by-a-thousand-slops/)).

Auf menschlicher Ebene war die Rechnung brutal. Jede Meldung band **drei bis vier seines siebenköpfigen Sicherheitsteams** über **30 Minuten bis rund drei Stunden** an Validierungsarbeit – fast durchweg ehrenamtlich. Der Start ins Jahr 2026 nahm ihm die Entscheidung ab: In den **ersten 21 Tagen des Jahres 2026 erhielt curl rund 20 Einreichungen und bestätigte null Schwachstellen**, darunter **sieben HackerOne-Meldungen innerhalb eines einzigen 16-Stunden-Fensters** (Quelle: [daniel.haxx.se](https://daniel.haxx.se/blog/2026/01/26/the-end-of-the-curl-bug-bounty/); [BleepingComputer](https://www.bleepingcomputer.com/news/security/curl-ending-bug-bounty-program-after-flood-of-ai-slop-reports/)).

Seit dem 1. Februar 2026 leitet curl Meldungen ohne Geldprämie an die private Meldefunktion von GitHub und an `security@curl.se` weiter – ausdrücklich, in Stenbergs Worten, um „den Anreiz zu beseitigen, Schrott einzureichen". Über seine gesamte Laufzeit hat das Programm für **87 bestätigte Schwachstellen ausgezahlt – über 100.000 US-Dollar seit 2019**. Das Bounty hat jahrelang funktioniert. Es war der KI-Spam, der es kaputt gemacht hat.

### HackerOnes 76-Prozent-Anstieg und die Pause der Internet Bug Bounty

HackerOne machte zwei getrennte Schritte. Erstens pausierte die **Internet Bug Bounty (IBB)** – der gemeinsame Fonds, der zentrale Open-Source-Abhängigkeiten finanziert – **Ende März 2026 neue Einreichungen** und verwies auf eine Verschiebung im Gleichgewicht zwischen KI-gestützter Entdeckung und menschlicher Behebungskapazität (Quelle: [Privacy Guides](https://www.privacyguides.org/news/2026/04/17/hackerone-pauses-internet-bug-bounty/); [InfoWorld](https://www.infoworld.com/article/4154210/internet-bug-bounty-program-hits-pause-on-payouts.html)).

Zweitens legte HackerOne im April 2026 – zeitgleich mit dem Start eines kostenpflichtigen Validierungsdienstes – die Schlagzeilen-Kennzahl offen: **Schwachstellen-Einreichungen wuchsen im Jahresvergleich um 76 % und erreichten im März 2026 einen Rekordwert**, während **rund 25 % der Funde als ausnutzbar bestätigt wurden** – eine Quote, die ungefähr stabil blieb (Quelle: [HackerOne-Pressemitteilung](https://www.hackerone.com/press-release/hackerone-introduces-h1-validation-help-enterprises-manage-surge-ai-discovered)). Lesen Sie das genau: Die absolute Zahl echter Bugs wächst weiter, aber das Rauschen um sie herum wächst ebenfalls – und schneller. Bis Mai 2026 hatte die IBB die **Prämien über alle Schweregradstufen hinweg drastisch gekürzt** (Quelle: [The Register](https://www.theregister.com/security/2026/05/21/hackerone-takes-an-axe-to-its-bug-bounty-rewards/5244458)).

### Das betrifft das gesamte Ökosystem

Es wäre einfach, curl als unterfinanziertes Open-Source-Projekt und HackerOne als Wachstumsschmerzen einer einzelnen Plattform abzutun. Das Muster reicht weiter.

| Programm | Was passiert ist | Wann |
|---|---|---|
| **Nextcloud** | Auszahlungen eingestellt unter Verweis auf einen „massiven Anstieg minderwertiger Meldungen"; Annahme blieb offen, bis man „herausgefunden hat, wie sich Einreichungen sauber filtern lassen" | April 2026 |
| **Google** | Annahme bestimmter KI-generierter Meldungen gestoppt | März 2026 |
| **Cosmos Labs (Krypto)** | Co-CEO meldete einen **Anstieg von 900 % im Jahresvergleich**, 20 bis 50 Einreichungen pro Tag | 2026 |
| **Bugcrowd** | Einreichungen **innerhalb von drei Wochen mehr als vervierfacht**, überwiegend False Positives oder minderwertige KI-Funde | März 2026 |
| **Linux-Kernel** | Linus Torvalds nannte die Security-Mailingliste unter doppelten KI-gestützten Meldungen „nahezu komplett unbeherrschbar" | 2026 |

Quellen: [heise](https://www.heise.de/en/news/Due-to-AI-Bug-bounty-programs-without-rewards-now-also-at-Nextcloud-11271443.html); [Computing.co.uk](https://www.computing.co.uk/news/2026/security/bug-bounty-platforms-battle-ai-slop); [Cointelegraph via TradingView](https://www.tradingview.com/news/cointelegraph:f6afb56fe094b:0-ai-drives-surge-in-bug-bounty-reports-but-slop-is-rising-too/).

Nextclouds Formulierung ist die aufschlussreichste. Sie haben die Annahme nicht abgeschaltet. Sie hielten den Kanal offen und stoppten die Zahlungen, *bis sie sauber filtern könnten*. Genau diese Lücke – „wir wollen die Meldungen, können uns aber die Triage nicht leisten" – ist das Problem, um das es in diesem Artikel geht.

## Warum KI-Spam die Bug-Bounty-Ökonomie zerstört

Ein Bug-Bounty ist ein Mechanismus des kostspieligen Signals. Die ursprüngliche Annahme: Ein Mensch hat echten Aufwand betrieben, um einen Bug zu finden, und produziert deshalb eine konkrete, reproduzierbare Meldung – die Triage lohnt sich für die Prüferin. Das ganze Modell beruht darauf, dass der Aufwand für eine Einreichung teuer genug ist, um Rauschen schon an der Quelle herauszufiltern.

KI bringt diese Annahme zum Einsturz. Sie macht das Erzeugen einer plausibel aussehenden Meldung nahezu kostenlos, während das Widerlegen einer solchen Meldung hartnäckig menschlich bleibt. Eine generierte Meldung kann ein echt aussehendes CVE zitieren, eine echt aussehende Funktion beschreiben und selbstbewusste Reproduktionsschritte auflisten – alles halluziniert. Eine Prüferin muss trotzdem die Codebasis öffnen, die Behauptung nachverfolgen und das Negativ beweisen. Zu beweisen, dass ein Bug echt ist, geht schnell. Zu beweisen, dass eine überzeugende Fälschung *nicht* echt ist, geht langsam.

Es kommt noch schlimmer. KI neigt dazu, viele Instanzen *desselben* zugrunde liegenden Problems hervorzubringen – dasselbe Cross-Site-Scripting-Muster mit zwanzig verschiedenen Payloads – und reicht jede davon als eigenständigen Fund ein. Das Volumen bläht sich auf, ohne dass die Sicherheit besser wird. Der Engpass verlagert sich vollständig auf die Validierung – genau den Teil der Pipeline, den man standardmäßig nicht billig automatisieren kann (Quelle: [Pen Test Partners](https://www.pentestpartners.com/security-blog/ai-noise-and-the-effect-its-having-on-vulnerability-disclosure-programs/)).

Zur Einordnung lohnt sich der Blick zurück: VDPs und Bountys liefen historisch **schon vor KI mit 60 bis 80 % ungültiger Einreichungen** (Quelle: [Yogosha](https://yogosha.com/blog/ai-and-vulnerability-triage-lessons-learned-from-our-automated-assistance-poc/)). Die Triage-Steuer gab es immer schon. KI hat das Problem nicht erfunden. Sie hat die natürliche Drossel beseitigt, die es überlebbar hielt.

## Das Triage-Playbook: fünf Hebel, die ein VDP am Leben halten

Das lösen Sie nicht mit einem einzigen Werkzeug. Sie lösen es, indem Sie die Ökonomie zurückdrehen: die Kosten fürs Einreichen von Spam erhöhen und die Kosten fürs Filtern senken. Hier sind die fünf Hebel, nach Wirkungsgrad geordnet.

1. **KI-gestützte Vorfilterung bei der Annahme.** Klassifizieren Sie offensichtlichen Spam automatisch (halluzinierte Funktionen, erfundene CVEs, kein Proof-of-Concept, Textbausteinsprache), bevor ein Mensch eine Stunde darauf verwendet.
2. **Rate Limiting und Spam-Kontrollen.** Eine Drosselung über ein gleitendes Zeitfenster, damit ein einzelner Akteur die Warteschlange nicht in einem 16-Stunden-Schub fluten kann.
3. **Reputationsbewertung, die KI-Spam bestraft.** Lassen Sie bestätigten KI-Spam den Einreicher etwas kosten, damit Wiederholungstäter sich selbst aussortieren.
4. **SLA-Tracking, das die Zeit der Prüfer schützt.** Bestätigen und beheben Sie nach Stoppuhr, damit echte Forscher nicht aus Frust an die Öffentlichkeit gehen.
5. **Prämien für Wirkung, nicht für Volumen.** Zahlen Sie nach Schweregrad, setzen Sie informative Funde auf null und verlangen Sie Konsolidierung, damit tausend identische Funde nur einmal zahlen.

### 1. KI-gestützte Vorfilterung bei der Annahme

Der mit Abstand wirkungsvollste Schritt ist, rohe Einreichungen gar nicht erst zuerst auf einen Menschen treffen zu lassen. Ein LLM-Screening-Durchlauf kann die verräterischen Zeichen erkennen, die fast jede Spam-Meldung teilt: Verweise auf Funktionen oder Code-Elemente, die nicht existieren, als neu zitierte CVEs, die Jahre alt oder frei erfunden sind, generische Behebungs-Floskeln und das Fehlen jedes konkreten, ausführbaren Proof-of-Concept.

Die entscheidende Designentscheidung ist, dass dies *unterstützend* wirkt und nicht automatisch ablehnt. Der erste Durchlauf soll empfehlen, nicht entscheiden: durchwinken mit hoher Konfidenz, Prüfung nötig oder markieren. Über alles Grenzwertige urteilt weiterhin ein Mensch. Sie bauen keinen Roboter-Türsteher. Sie bauen einen Sprechenden Hut, der den offensichtlichen Spam von der Aufmerksamkeit Ihrer erfahrenen Entwickler fernhält.

### 2. Rate Limiting und Spam-Kontrollen

curl nahm sieben Meldungen in 16 Stunden entgegen. Kein menschliches Team triagiert das in Echtzeit. Eine einfache Drosselung über ein gleitendes Fenster – etwa fünf Meldungen pro Akteur in fünf Minuten, dann eine vorübergehende Sperre – neutralisiert das Flutungsmuster, ohne legitime Forscher zu behindern, die so gut wie nie in rascher Folge einreichen. Das ist der am günstigsten umzusetzende Hebel und einer der wirksamsten gegen das spezifische Angriffsmuster von 2026.

### 3. Reputationsbewertung, die KI-Spam bestraft

Karma-Systeme sind im Bounty-Land ein alter Hut, aber die meisten belohnen nur valide Arbeit. Das Umfeld von 2026 verlangt das Gegenteil: Bestätigter KI-Spam und abgewiesener Spam sollten Punkte *abziehen*. Wenn die Reputation eines Einreichers sinkt, können Sie dessen künftige Einreichungen einschränken oder automatisch nachrangig behandeln. Das Ziel ist, KI-Spam etwas kosten zu lassen, damit es sich für die Volumen-Optimierer nicht mehr lohnt.

### 4. SLA-Tracking, das die Zeit der Prüfer schützt

Hier ist der Zusammenhang, den die meisten übersehen: SLA-Tracking geht nicht nur darum, reaktionsschnell zu sein. Es geht darum, die guten Forscher nicht zu verlieren. Echte Forscher gehen an die Öffentlichkeit, wenn Eingangsbestätigungen ausbleiben, Fixes klammheimlich ausgerollt werden oder der Schweregrad still und leise heruntergestuft wird – genau das Versagensmuster, das wir unter [wenn Forscher an die Öffentlichkeit gehen](/blog/when-researchers-go-public-botched-disclosure) behandelt haben. Unter Spam-Last sind die Bestätigungszeiten das Erste, was rutscht – und genau dann können Sie es sich am wenigsten leisten, die echten Meldenden zu vergraulen, die im Rauschen begraben liegen. Eine Bestätigungs-Stoppuhr (z. B. 72 Stunden) plus Behebungsziele je Schweregrad sorgen dafür, dass genau die Leute, die Sie am dringendsten halten wollen, weiter mit Ihnen koordinieren.

<div class="blog-inline-cta">
  <p><strong>Ertrinken Sie in Ihrem VDP-Postfach?</strong> Das CSIRT-Modul von Kit liefert KI-Vorfilterung, Rate Limiting bei der Annahme, Reputations-Karma, SLA-Stoppuhren und wirkungsbasierte Prämien als Konfiguration – nicht als sechsmonatiges Eigenbau-Projekt.</p>
  <p><a href="/users/sign_up">Kostenlose Testphase starten</a></p>
</div>

### 5. Prämien für Wirkung, nicht für Volumen

Wenn Ihr Bounty pro akzeptiertem Fund zahlt, unabhängig vom Schweregrad, dann bezahlen Sie Leute fürs Einreichen von Volumen – und KI tut das nur zu gern. Koppeln Sie Auszahlungen an eine Schweregrad-Matrix, in der informative Funde **0 US-Dollar** bringen und nur echte Wirkung echtes Geld bringt. Kombinieren Sie das mit Deduplizierung, damit tausend Instanzen eines Bugs mit einer Ursache zu einem Ticket und einer Auszahlung zusammenlaufen. Genau zu diesem Hebel hat curl am Ende gegriffen: den Geldanreiz fürs Einreichen von Schrott beseitigen. Sie müssen nicht bis auf null gehen wie curl, aber Sie müssen aufhören, Quantität zu belohnen.

## Werfen Sie die guten KI-gestützten Forscher nicht über Bord

Der Feind ist *unvalidiertes Volumen*, nicht KI. Diese Unterscheidung ist wichtig, denn die bequeme Reaktion – „KI-gestützte Meldungen verbieten" – würde Ihre besten Mitwirkenden aussortieren.

Das klarste Gegenbeispiel ist Joshua Rogers, dessen KI-gestützte Arbeit rund 50 *echte* Bugs in curl aufdeckte – jeder einzelne von einem Menschen validiert, bevor er eingereicht wurde. Dasselbe Werkzeug wie bei den Spam-Lieferanten, gegenteiliges Ergebnis – weil ein kompetenter Mensch zwischen dem Modell und dem Absenden-Knopf stand. Stenberg hat ausdrücklich gesagt, dass verantwortungsvolle KI-gestützte Forschung willkommen ist; es ist der Feuerwehrschlauch ungeprüften Outputs, den er nicht aushält.

Die Aufgabe des Playbooks ist also präzise: nach *Evidenz und Validität* filtern, nicht danach, *ob KI im Spiel war*. Eine Meldung mit funktionierendem Proof-of-Concept und echtem Code-Verweis besteht – egal ob ein Mensch oder ein Modell sie verfasst hat. Eine Meldung mit halluzinierten Funktionen und ohne PoC fällt aus demselben Grund durch, unabhängig von der Urheberschaft. Filtern Sie das Signal, nicht das Werkzeug.

## Wie Kit das Playbook in den Betrieb bringt

Hier ist die unbequeme Wahrheit für jedes Team, das das in Eigenregie baut: Die fünf Hebel oben entsprechen grob sechs Monaten interner Werkzeugentwicklung. Kits `Csirt::`-Vertikale setzt sie als Konfiguration um. Die Zuordnung ist nahezu eins zu eins.

| Playbook-Hebel | Kit-CSIRT-Funktion | Was sie leistet |
|---|---|---|
| **KI-gestützte Vorfilterung** | `Csirt::AiScreening` | LLM-Screening liefert je nach Konfidenz `pass` / `review` / `flag` und erkennt explizite Spam-Signale: halluzinierte Funktionen, erfundene CVEs, ein altes CVE als neu zitiert, generische Behebung, kein konkreter PoC, Textbausteinsprache, vage Reproduktionsschritte, Verweise auf nicht existierenden Code |
| **Rate Limiting / Spam-Kontrollen** | `Csirt::SpamConfig` | Drosselung über gleitendes Fenster (Standard: 5 Meldungen pro 5 Minuten, dann vorübergehende Sperre) mit Auto-Sperre bei Wiederholung |
| **Reputation, die KI-Spam bestraft** | `Csirt::KarmaEvent` | Bestätigter KI-Spam kostet den Einreicher Karma; Spam-Abweisung und „nicht zutreffend" ziehen ebenfalls ab; valide Behebungen und Prämien fügen hinzu, mit Boni nach Schweregrad |
| **Deduplizierung** | `Csirt::TriageConfig` | Dedup standardmäßig aktiv, damit wiederholte Instanzen einer Ursache nicht zu hundert Tickets werden |
| **SLA-Tracking** | `Csirt::SlaConfig` | Bestätigungs-Stoppuhr (Standard 72 h) plus Behebungsziele je Schweregrad |
| **Wirkungsbasierte Prämien** | `Csirt::BountyMatrixConfig` | Nach Schweregrad gestaffelte Auszahlungsbänder; informativ zahlt 0 US-Dollar, skalierend bis kritisch |
| **Verantwortung unter Last** | `Csirt::OnCallConfig` | Automatische Bereitschaftszuweisung, damit Bestätigungen nicht rutschen, wenn die Warteschlange ausschlägt |
| **Weniger Rauschen außerhalb des Geltungsbereichs** | `Csirt::ScopeConfig`, `Csirt::SecurityTxtConfig` | Öffentlicher Scope und Policy reduzieren ungültige Einreichungen an der Quelle |

Ein präziser Hinweis zum KI-Screening: Es ist *unterstützende Triage* – eine Empfehlung plus Konfidenzwert, keine automatische Ablehnung. Über jedes `flag` und `review` urteilt weiterhin ein Mensch. Kit beansprucht nicht, allen Spam zu blockieren. Es filtert den ersten Durchlauf und bepreist die Anreize neu, sodass die Stunden Ihrer Prüfer in echte Bugs fließen – und eine Joshua-Rogers-Meldung mit funktionierendem PoC glatt durchläuft, während eine halluzinierte hängen bleibt.

## Das Fazit: ein Spam-Problem ist in Wahrheit ein Triage-Problem

Die Programme, die 2026 gestorben sind, wurden nicht von KI besiegt. Sie wurden von einer Annahme-Pipeline besiegt, die für eine Welt des kostspieligen Signals gebaut war, die es nicht mehr gibt. Spam ist nur Volumen. Das Versagen war strukturell: kein automatisierter erster Durchlauf, kein Rate Limit, keine Reputationsstrafe und ein Bounty, das für Quantität zahlte.

Jeder einzelne dieser Punkte ist behebbar, und jeder einzelne ist eine Einstellung statt eines Forschungsprojekts. Wenn Sie ein Programm von Grund auf aufsetzen, beginnen Sie mit [dem VDP-Setup-Leitfaden](/blog/how-to-set-up-vulnerability-disclosure-program). Wenn Sie schon untergehen, ist der richtige Schritt, die Ökonomie zurückzudrehen: den ersten Durchlauf automatisieren, die Fluten drosseln, KI-Spam etwas kosten lassen, die Zeit Ihrer Prüfer mit SLAs schützen und immer nur für echte Wirkung zahlen. Halten Sie die curl-killer-Meldungen draußen und die Joshua-Rogers-Meldungen drin.

Genau dafür ist das CSIRT-Modul von Kit gebaut. [Starten Sie eine kostenlose Testphase](/users/sign_up) und verwandeln Sie ein geflutetes Postfach in eine gefilterte, rate-limitierte, SLA-gestützte Warteschlange.