Ein 25-$-Bug im Wert von 500.000 $: KI hat gerade die VDP-Ökonomie gesprengt

Die Kosten, einen kritischen Bug zu finden, sind gerade eingebrochen. Ein Forscher bei Searchlight Cyber richtete ein Frontier-Modell auf den WordPress-Core, gab über rund zehn Stunden etwa 25 $ an Rechenzeit aus und förderte eine SQL-Injection vor der Authentifizierung zutage, die sich zu Remote Code Execution ausweiten lässt – eine Bug-Klasse, die Exploit-Broker mit bis zu 500.000 $ bewerten. Das ist keine Geschichte über KI-Spam. Es ist das Gegenteil, und es ist der Ausfallmodus, für den kaum ein Vulnerability Disclosure Program Budget eingeplant hat: eine Welle echter, tatsächlich kritischer Funde, die schneller eintrifft, als irgendein menschliches Sichtungsteam sie bestätigen, verifizieren oder vergüten kann.

Wenn Sie ein VDP oder ein Bug-Bounty-Programm betreiben, ruht Ihr gesamtes Kostenmodell auf einer stillen Annahme: dass es teuer und selten ist, einen kritischen Bug zu finden. Diese Annahme ist gerade zusammengebrochen. Das hat Folgen für Ihre SLAs, Ihr Prämienbudget und Ihre Sichtungs-Warteschlange – und die sollten Sie noch in diesem Quartal angehen.

Was tatsächlich geschah – und was belegt ist

Adam Kues, Forscher bei Searchlight Cyber, baute ein KI-Prompting-Rezept zu einem Multi-Agenten-Harness für die Schwachstellensuche um und richtete ein Frontier-Modell auf den WordPress-Quellcode. Der Forscher berichtet, es habe über zehn Stunden Modelllaufzeit gedauert und rund 25 $ gekostet, um eine SQL-Injection vor der Authentifizierung zu entdecken, die sich zu RCE ausweitet. Anschließend reproduzierte er sie gegen eine Standard-WordPress-Installation, ließ das Modell die E-Mail-Adresse des Administrators stehlen, und es gab die Adresse binnen Minuten aus. Er hielt die Veröffentlichung zurück und bereitete eine Meldung zur Offenlegung vor.

Zwei Eckdaten zählen hier, und nur eines davon ist unabhängig belegt. Die 25-$-Zahl und die zehnstündige Laufzeit sind die Schilderung des Forschers über seine eigene Arbeit – behandeln Sie sie als berichtet, nicht als gesichert. Die Bewertung von 500.000 $ ist die, die Sie überprüfen können: Die öffentliche Preisliste von Crowdfenses Exploit Acquisition Program nennt „WordPress (RCE): 500k USD“ – dieselbe Stufe wie Remote Code Execution bei Apache HTTP Server und Microsoft IIS, oberhalb von Nginx mit 350.000 $ und weit über anderen Content-Management-Systemen wie Joomla (40.000 $) oder Drupal (25.000 $). Die Obergrenze auf dem Graumarkt ist real, keine rhetorische Zierde. Im Ausgangsbericht wurde keine CVE vergeben, und die genaue Modellbezeichnung ist die Darstellung des Artikels, nicht die Spezifikation eines ausgelieferten Produkts.

Die Lücke ist die ganze Geschichte. Kosten für das Auffinden: etwa 25 $. Wert für einen Angreifer: bis zu einer halben Million Dollar. Diese beiden Zahlen hingen früher grob zusammen, weil zwischen ihnen knappe menschliche Expertise saß. Die KI hat den Menschen gerade als Engpass entfernt.

„KI-Spam“ war das leichte Problem

Zwei Jahre lang drehte sich die Debatte der Branche über KI und Bug-Bounties um Rauschen. Erfundene CVEs, halluzinierte Funktionsnamen, Meldungen von der Stange – jene Sorte minderwertigen Massenmülls, die curl-Maintainer Daniel Stenberg öffentlich darüber schimpfen ließ, dass KI-generierte Meldungen seine Zeit verschwenden. Diesen Ausfallmodus haben wir selbst schon beschrieben, in KI-Spam in Bug-Bounty-Programmen: So sichten Sie ein VDP unter Last. Spam verschwendet Sichtungsstunden. Er ist lästig, in großem Maßstab teuer, und Verteidiger haben echten Aufwand betrieben, um ihre Filter darauf zu trimmen, ihn abzuweisen.

Der WordPress-Fund ist das Gegenteil, und er ist wohl schlimmer. Das ist hochwertiges Signal mit hohem Schweregrad, erzeugt in Maschinengeschwindigkeit und zu nahezu null Grenzkosten. Spam bedroht Ihre Sichtungszeit. Eine Flut echter kritischer Meldungen bedroht drei Dinge zugleich: Ihr Bestätigungs-SLA, Ihr Prämienbudget und Ihre Patch-Pipeline. Sie haben Ihren Eingang darauf getrimmt, Müll abzuweisen. Für einen Überfluss an Gold haben Sie kein Budget eingeplant.

Hier die unbequeme betriebliche Realität: Beide Ausfallmodi treffen jetzt gemeinsam ein. Dieselbe Technologie, die gültige kritische Funde am Fließband produziert, erzeugt auch überzeugende Fälschungen, echte, aber alte CVEs, die als neu erneut eingereicht werden, und plausible Code-Verweise auf Funktionen, die nicht existieren. Die Sichtung kann nicht länger davon ausgehen, dass eine Meldung entweder vertrauenswürdig oder Müll ist. Sie muss davon ausgehen, dass beide Modi jeden Tag in derselben Warteschlange aktiv sind.

Warum billiges Auffinden die Bug-Bounty-Ökonomie sprengt

In der Preisgestaltung von Bug-Bounties steckt ein impliziter Handel. Einen kritischen Bug zu finden ist teuer und selten, also ist eine Belohnung von ein paar Tausend Dollar eine faire Wertteilung mit einem raren Experten, der die Offenlegung dem Graumarkt vorgezogen hat. Wenn die Kosten fürs Auffinden auf 25 $ einbrechen, kehrt sich dieser Handel um. Der Broker zahlt weiterhin 500.000 $, weil sich der offensive Wert einer RCE vor der Authentifizierung über Hunderte Millionen Installationen hinweg nicht verändert hat. Doch die Auszahlung des Programms, oft um ein bis drei Größenordnungen niedriger, wirkt jetzt wie ein Rundungsfehler – sowohl gegenüber dem wahren Wert des Bugs als auch gegenüber der Menge, die gleich eintreffen wird.

Stellen Sie drei Zahlen nebeneinander:

Das Missverhältnis liegt nicht darin, dass Programme geizig wären. Es liegt darin, dass der Einbruch der Auffindekosten eine ohnehin große Lücke weiter aufgerissen hat – zwischen dem, was ein Bug einem Angreifer wert ist, und dem, was ein Verteidiger vernünftigerweise zahlen kann – und zugleich vervielfacht, wie viele solcher Bugs ein Programm erhalten wird. Ein Forscher, der kritische Funde für je 25 $ am Fließband erzeugen kann, steht vor einer harten Wahl: bei einem Programm einreichen, das im besten Fall 5.000 $ zahlt und Offenlegungsbedingungen durchsetzt, oder an einen Broker für 500.000 $ verkaufen. Billiges Auffinden belastet nicht nur die Sichtungskapazität. Es verstärkt den Sog zum Graumarkt – ausgerechnet bei den Funden mit dem höchsten Schweregrad, die Ihr Programm am dringendsten erhalten müsste.

Kein selbst gehostetes Programm wird je mit einem Broker mithalten. Das ist nicht das Ziel, und etwas anderes vorzugeben verspielt Glaubwürdigkeit. Das realistische Ziel ist es, die große Zahl an Forschern zu gewinnen, die lieber offenlegen würden – vorausgesetzt, Reibung und Auszahlungslücke sind groß, aber nicht beleidigend. Das ist ein Problem des Programmdesigns, und es hat drei Hebel.

Die drei Dinge, die jeder VDP-Verantwortliche jetzt neu justieren muss

Billiges Auffinden erfordert keine neue Plattform. Es erfordert, drei Grundbausteine neu zu justieren, die Ihr Programm bereits hat oder haben sollte: SLA-Stufen, Prämienökonomie und Sichtungskapazität. Kits selbst gehostetes CSIRT-Vertical bildet jeden davon als Konfiguration ab, daher nutze ich seine Standardwerte als konkreten Bezugspunkt. Die Prinzipien gelten, ob Sie Kit, HackerOne oder eine security.txt und ein gemeinsames Postfach betreiben.

SLA neu justieren: „Wir haben Sie gehört“ von „Wir haben es behoben“ trennen

Ein pauschales SLA bricht unter einer Welle gültiger kritischer Meldungen zusammen. Der Ausweg besteht darin, ein Versprechen in zwei zu teilen. Die Bestätigung ist billig und schnell: Sie besagt „Ein Mensch hat Ihre Meldung, und eine Frist läuft.“ Die Lösung ist teuer und langsam: Sie besagt „Das ist gepatcht.“ Beides zu vermengen heißt: Jede Spitze im Posteingang bedroht Ihre öffentliche Zusage, Dinge bis zu einer Frist zu beheben, die Sie nicht mehr in der Hand haben.

Reservieren Sie Ihre engsten Lösungsfristen nur für den obersten Schweregrad, damit eine Welle kritischer Meldungen Ihre Warteschlange nicht praktisch lahmlegen kann. Kits Csirt::SlaConfig liefert diese Form standardmäßig: ein Bestätigungsversprechen von 72 Stunden, dann nach Schweregrad gestaffelte Lösungsziele von 24 Stunden für Super-kritisch, 72 Stunden für Kritisch, 7 Tage für Hoch und zunehmend länger für Mittel und Niedrig. Der Konstruktionsgedanke: Die Bestätigung bleibt konstant und billig, während die Lösung mit dem Schweregrad skaliert. Wenn hundert gültige Meldungen in einer Woche eintreffen, können Sie „Wir haben Sie gehört, binnen 72 Stunden“ noch für alle einlösen und „Wir haben es behoben, binnen 24 Stunden“ nur für die echten 10,0er.

Prämien neu bepreisen: eine belastbare Spitzenstufe und eine Dedup-Richtlinie aufbauen

Ihr Schweregrad-Vokabular braucht ein Band oberhalb von „Kritisch“. Die KI wird gleich mehr echte CVSS-10,0-Funde zutage fördern, als Programme historisch in einem Jahr sahen, und eine RCE vor der Authentifizierung über eine riesige Installationsbasis ist genau das. Kit bildet das mit einer super_critical-Stufe (CVSS 10,0) oberhalb von critical (9,0 bis 9,9) ab, sowie mit einer gestaffelten BountyMatrixConfig, die von 0 $ für Informativ bis hin zu 5.000 bis 10.000 $ für Super-kritisch reicht.

Seien Sie ehrlich, was diese Spitzenstufe ist. Kits großzügiger selbst gehosteter Standard von 5.000 bis 10.000 $ liegt immer noch 50- bis 100-mal unter dem Broker-Preis für genau den Bug, den Kues fand. Diese Lücke werden Sie nicht schließen, also hören Sie auf, es zu versuchen. Was Sie tun können: die Kurve steiler machen und die Spitze verbreitern, sodass die Funde mit dem höchsten Schweregrad eindeutig wert sind, gemeldet zu werden, statt in der Schublade zu landen. Das gehen wir im Detail durch in Bug-Bounty-Prämienstufen, denen Forscher wirklich vertrauen.

Fügen Sie dann eine Deduplizierungsrichtlinie hinzu, denn sie trägt plötzlich echtes Gewicht. Wenn viele Forscher dasselbe Modell auf dasselbe beliebte Ziel richten, ist eine Kollision bei identischen Bugs kein Risiko, sondern das vorhersehbare Ergebnis. Ohne eine klare, veröffentlichte Regel „erste gültige Meldung gewinnt“ verbrauchen Sie Ihre Glaubwürdigkeit damit, Kopf-an-Kopf-Streitigkeiten zu schlichten – genau das Szenario, das wir in Streit um Bug-Bounty-Auszahlungen: SLAs und Fairness in Ihrem VDP behandeln. Kit aktiviert Dedup aus diesem Grund standardmäßig in seiner TriageConfig.

Sichtung in Maschinengeschwindigkeit: Spam herausfiltern und die echten kritischen Meldungen bevorzugt behandeln

Die Sichtung hat jetzt zwei Aufgaben, die in entgegengesetzte Richtungen ziehen. Sie muss überzeugende Fälschungen abweisen und echtes Signal mit hohem Schweregrad schnell validieren – oft in derselben Warteschlange am selben Tag. Eine Sichtung im Menschentempo schafft bei großem Volumen nicht beides.

Das Screening ist die erste Hälfte. Kits Csirt::AiScreening vergibt einen ai_confidence_score (0,0 bis 1,0, die Wahrscheinlichkeit, dass eine Meldung KI-Spam ist) und markiert bekannte Fälschungssignale wie halluzinierte Funktionen, erfundene CVEs, eine als neu zitierte frühere CVE und Meldungen ohne konkreten Proof of Concept. Diese Schicht wurde für das Spam-Problem gebaut, und sie muss weiterhin laufen, denn der Spam verschwindet nicht.

Doch das Screening ist nur die Hälfte des neuen Problems. Die Herausforderung ist jetzt, die gültigen kritischen Meldungen bevorzugt durchzuschleusen. Das heißt Auto-Eskalation und Weiterleitung an die Bereitschaft, damit eine super-kritische Meldung nie in einer Warteschlange darauf wartet, dass jemand sie bemerkt. Kits TriageConfig unterstützt Eskalations-Schweregrade (standardmäßig Kritisch und Super-kritisch), Anforderungen zum erneuten Test und automatische Zuweisung an die Bereitschaft, verdrahtet mit einer Bereitschaftsrotation und PagerDuty. Der rote Faden für jeden Programmverantwortlichen: Spam-Filterung ist jetzt Grundvoraussetzung; schnelle Validierung und Priorisierung echten Signals bei großen Mengen ist die Fähigkeit, die Sie als Nächstes wirklich aufbauen müssen.

Was in diesem Quartal zu tun ist

Sie können einen Broker nicht überbieten, und Sie müssen es auch nicht. Sie brauchen ein Programm, das schnell, glaubwürdig und gut instrumentiert genug ist, sodass ein Forscher, der die Offenlegung bevorzugt, keine reibungsbedingte Ausrede hat, stattdessen an einen Broker zu verkaufen. Konkret:

1. Teilen Sie Ihr SLA. Veröffentlichen Sie ein schnelles, konstantes Bestätigungsfenster und nach Schweregrad gestaffelte Lösungsfenster. Reservieren Sie Ihr engstes Lösungsziel für eine Spitzenstufe oberhalb von „Kritisch“.
2. Fügen Sie ein Super-kritisch-Band hinzu und bepreisen Sie die Spitze neu. Machen Sie die Prämienkurve steiler und die Spitze breiter, sodass echte 10,0er meldenswert sind. Die Lücke zu den Broker-Preisen müssen Sie akzeptieren – die zum Beleidigenden nicht.
3. Veröffentlichen Sie eine Dedup-Regel, bevor Sie sie brauchen. Die erste gültige, vollständig reproduzierbare Meldung gewinnt. Halten Sie das jetzt schriftlich fest, nicht erst im Streitfall.
4. Betreiben Sie eine zweiseitige Sichtung. Bewerten Sie die KI-Wahrscheinlichkeit, um Fälschungen abzufangen, und eskalieren Sie gültige kritische Meldungen automatisch an die Bereitschaft, damit nichts Schwerwiegendes in einer Warteschlange wartet.
5. Instrumentieren Sie die Bestätigungszeit. Wenn Sie Ihre Zeit-bis-zur-Bestätigung je Schweregrad nicht sehen können, können Sie sie nicht verteidigen, wenn die Menge eintrifft.

Die Kosten, einen kritischen Bug zu finden, sind auf 25 $ gefallen. Der Wert dieses Bugs für einen Angreifer hat sich nicht bewegt. Ihr Programm lebt in der Lücke zwischen diesen Zahlen, und die Lücke ist gerade breiter und voller geworden. Die Programme, die das nächste Jahr überstehen, werden nicht die mit den größten Prämientöpfen sein. Es werden die sein, die schnell bestätigen, ehrlich bepreisen, fair deduplizieren und die echten kritischen Meldungen eskalieren, bevor irgendjemand sonst das Ticket auch nur öffnet.

Wie Kits CSIRT die Welle bewältigt

Kit ist eine KI-native Plattform für Startups, und sein selbst gehostetes CSIRT- und VDP-Modul existiert genau deshalb, weil die Sicherheitssichtung am Ende standardmäßig bei den Gründern landet. Es liefert die vier Hebel, die dieser Wandel verlangt, als Konfiguration statt als Projekt: ein super_critical-Schweregradband oberhalb von Kritisch, getrennte SLAs für Bestätigung und Lösung, eine gestaffelte Prämienmatrix, die Sie neu bepreisen können, Dedup und Auto-Eskalation an die Bereitschaft sowie ein KI-Screening, das die Wahrscheinlichkeit bewertet, dass eine Meldung Spam ist.

Was es nicht tut: sich als 500.000-$-Broker ausgeben – und genau diese Ehrlichkeit ist der Punkt. Ein gut instrumentiertes, schnelles, transparentes Programm gewinnt die Forscher, die lieber offenlegen als verkaufen – solange Sie die Offenlegung nicht langsam, undurchsichtig oder beleidigend machen. Die Kostenkurve für das Auffinden kritischer Bugs ist eingebrochen. Das Design Ihres Programms ist der einzige Hebel, den Sie noch vollständig steuern – also justieren Sie ihn vor der Flut, nicht mittendrin.