Chromes Prämie von 1.000 $: Schweregrad ist kein Preis

Der Schweregrad einer Sicherheitslücke bestimmt nicht automatisch die Höhe einer Prämie. Der Schweregrad misst die technischen Auswirkungen unter bestimmten Voraussetzungen. Bei der Dringlichkeit der Behebung kommen Nachweise wie aktive Ausnutzung und die Exposition des betroffenen Systems hinzu. Eine Prämie hängt außerdem davon ab, was der Forscher geliefert hat, welche Regeln das Programm veröffentlicht hat, wie gut die Meldung ist, welche Boni gelten und wie ein Mensch entscheidet.

Dieser Unterschied erklärt eine zunächst verblüffende Angabe in Googles Chrome-Sicherheitshinweis vom September 2026. CVE-2026-85046 war eine V8-Sicherheitslücke mit hohem Schweregrad. Google erklärte, die Lücke werde bereits aktiv ausgenutzt. Die offengelegte Prämie betrug 1.000 $.

Die Zahl wirkt nur dann absurd, wenn Sie davon ausgehen, dass „Hoch“, „aktiv ausgenutzt“ und „Prämie“ drei Bezeichnungen für denselben Preis sind. Das sind sie nicht. Für das Sicherheitsteam eines Startups ist dieser Fall ein hilfreiches Modell, um vier Entscheidungen voneinander zu trennen: technischer Schweregrad, Dringlichkeit der Behebung, geliefertes Exploit-Material und die Beratung über die Prämienhöhe.

Warum legte Google für eine aktiv ausgenutzte Chrome-Sicherheitslücke nur eine Prämie von 1.000 $ offen?

Die kurze Antwort lautet: Aus den öffentlichen Unterlagen geht Googles Berechnung nicht hervor. Sie belegen eine Sicherheitslücke, eine Patch-Priorität und eine endgültige Prämie. Diese Fakten gehören zu unterschiedlichen Systemen.

Googles Stable-Channel-Update vom 3. September führte CVE-2026-85046 als „Type Confusion in V8“ mit hohem Schweregrad auf. Als Forscher wurde Salvatore Gulizia, auch bekannt als Serotav, genannt. Laut Hinweis meldete er die Lücke am 4. August, die offengelegte Prämie betrug 1.000 $. Google erklärte außerdem, die Lücke werde bereits aktiv ausgenutzt.

Die korrigierten Versionen waren 152.0.7977.82 oder .83 für Windows und Mac sowie 152.0.7977.82 für Linux. Das Update enthielt zwölf Sicherheitskorrekturen. Google wies darauf hin, dass der Zugriff auf Details zu den Fehlern eingeschränkt bleiben könne, bis die meisten Nutzer aktualisiert hätten.

Nichts in dieser Tabelle ist widersprüchlich. Der Fehler besteht darin, die letzte Zeile aus den ersten drei ableiten zu wollen.

Deshalb braucht eine Prämienmatrix Spannen statt einer Preisliste. Wenn Ihre Tabelle festlegt: „Hoch entspricht 1.000 $“, verdeckt sie die Fragen, auf die es innerhalb des Schweregrads ankommt. Hat der Forscher einen Absturz, einen zuverlässigen Proof of Concept, eine wiederverwendbare Exploit-Primitive, eine Abhilfemaßnahme oder eine vollständige Kette geliefert? War die Meldung klar und eigenständig? Die Spanne der jeweiligen Prämienstufe kann den Rahmen der Beratung abstecken, sie aber nicht ersetzen. Unser Leitfaden zu Prämienstufen für Bug Bounties zeigt, wie Sie diese Grundlage veröffentlichen, ohne daraus eine starre Formel zu machen.

Überwindet CVE-2026-85046 die Chrome-Sandbox?

Nein, zumindest nicht nach den öffentlich verfügbaren Belegen. Laut offiziellem CVE-Eintrag konnte präpariertes HTML beliebigen Code innerhalb der Sandbox ausführen. Das ist eine schwerwiegende Möglichkeit zur Codeausführung in Chromes V8-JavaScript-Engine, aber nicht mit einem Ausbruch aus der Sandbox und der Kontrolle über das Betriebssystem gleichzusetzen.

Chrome isoliert Webinhalte in einem eingeschränkten Renderer-Prozess. Erlangt ein Angreifer dort die Möglichkeit zur Codeausführung, soll die Sandbox verhindern, dass dieser Code ungehindert auf das Hostsystem zugreift. Eine vollständige Angriffskette gegen den Browser benötigt häufig eine weitere Sicherheitslücke, um diese Grenze zu überwinden. Googles Project Zero hat diesen Unterschied bei seiner Arbeit zum Überwinden der Chrome-Sandbox dokumentiert.

Gulizias eigener technischer Bericht macht diese Grenze ungewöhnlich deutlich. Er beschreibt eine Typverwechslung, die beliebige Lese- und Schreibzugriffe im JavaScript-Heap ermöglichte. Anschließend erklärt er, er habe „diesen Bug“ mit einem bereits bekannten n-Day-Sandbox-Escape verkettet, um bei Googles v8CTF eine gültige Flag einzureichen. Mit anderen Worten: Diese CVE lieferte einen Teil der Kette. Ein separater, bereits bekannter Exploit ermöglichte das Überwinden der Sandbox.

Dieser Unterschied ist in zweifacher Hinsicht wichtig.

Erstens bestimmt er die technische Aussage. Die CVE als „Sandbox-Escape“ zu bezeichnen, würde der ersten Sicherheitslücke die Fähigkeit des zweiten Exploits zuschreiben. Auch „Sandbox RCE“ ist eine riskante Verkürzung, weil viele Leser darunter „Codeausführung nach dem Überwinden der Sandbox“ verstehen. Die präzise Formulierung lautet: beliebige Codeausführung im V8-Renderer innerhalb der Chrome-Sandbox.

Zweitens bestimmt er die Diskussion über die Prämie. Eine V8-Sicherheitslücke, die eine nützliche Primitive bereitstellt, und ein funktionierender, vollständiger Angriff auf den Browser sind nicht dieselbe Leistung. Ein Programm kann dafür zu Recht unterschiedliche Prämienkategorien und Boni festlegen. Aus einem später veröffentlichten externen Bericht lässt sich nicht ableiten, welche Leistung die vertrauliche Meldung belegte.

Der bei Hacker News eingereichte Titel behauptete außerdem, der Fehler betreffe „alle Chromium-Versionen“. Die Versionshistorie zeigt etwas anderes. Die betreffende Optimierung von Array.prototype.sort wurde am 27. April 2026 in V8 aufgenommen. Die Versionszuordnung von V8 ordnet Version 14.9 Chrome M149 zu. Der CVE-Eintrag nennt eine Obergrenze, nämlich Versionen vor 152.0.7977.82, aber keine Untergrenze. Die Repository-Historie liefert den fehlenden Beginn.

CISA zufolge könnte das Problem mehrere Chromium-basierte Browser betreffen, darunter Chrome, Edge und Opera. Das ist eine Aufforderung, die Sicherheitshinweise der einzelnen Anbieter zu prüfen, aber kein Beleg dafür, dass jeder Chromium-Fork oder jede frühere Version verwundbar war.

Warum beantworten CVSS und CISA KEV unterschiedliche Fragen?

CVSS beschreibt technische Merkmale. Der Known Exploited Vulnerabilities Catalog von CISA informiert Verantwortliche darüber, dass eine Ausnutzung nicht mehr nur möglich ist, sondern tatsächlich beobachtet wurde. Sie benötigen beide Signale, sollten sie aber weder zu einem einzigen Wert noch zu einer einzigen Auszahlungsregel verschmelzen.

Der offizielle CVE-Eintrag beschreibt, wie präpariertes HTML zu beliebiger Codeausführung innerhalb der Sandbox führt. Er ordnet die Schwachstelle CWE-843 zu, also dem Zugriff auf eine Ressource über einen inkompatiblen Typ. Der bei NVD angezeigte Wert 8.8 stammt aus einer sekundären Bewertung durch CISA ADP und ist kein separater NVD-Wert.

Der Vektor lautet AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. Im Klartext:

• Der Angriff ist über ein Netzwerk möglich.
• Die Angriffskomplexität ist niedrig.
• Es sind keine bestehenden Berechtigungen erforderlich.
• Eine Nutzerinteraktion ist erforderlich, etwa der Aufruf präparierter Webinhalte.
• Der Geltungsbereich bleibt unverändert, was zur Ausführung innerhalb der Sandbox passt.
• Die Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit werden innerhalb dieses Geltungsbereichs als hoch eingestuft.

CVSS fragt nicht danach, ob in dieser Woche ein Exploit im Umlauf ist. Hier kommt KEV ins Spiel. CISA nahm CVE-2026-85046 am 4. September in seinen KEV-Katalog auf und setzte den 18. September als Frist für die Behebung bei betroffenen US-Bundesbehörden fest. Private Unternehmen sind nicht an diese Frist gebunden. Das operative Signal ist dennoch wertvoll: Das Team sollte nicht länger darüber diskutieren, ob die Ausnutzung nur theoretisch ist, sondern das Update mit höchster Priorität einspielen.

Daraus ergibt sich eine klare Regel für Verantwortliche in Startups: CVSS hilft, die Auswirkungen zu beschreiben; KEV hilft, Arbeiten zu priorisieren. Keines von beiden berechnet eine Prämie. Wenn Ihr Programm für eine Meldung mit Nachweisen aktiver Ausnutzung einen Bonus zahlen will, schreiben Sie diese Regel in die Richtlinie. Improvisieren Sie nicht erst, nachdem eine Schlagzeile erschienen ist.

Wofür genau wurde die Chrome-Prämie von 1.000 $ gezahlt?

Die einzige belastbare Antwort lautet: Es handelt sich um die im Chrome-Hinweis offengelegte Prämie für Gulizias CVE-Meldung. Öffentliche Belege nennen weder die genaue Kategorie im Vulnerability Reward Program noch die Berechnung oder den Inhalt der vertraulichen Einreichung.

Googles aktuelle Regeln des Chrome Vulnerability Reward Program zeigen, warum es unsicher wäre, den Betrag im Nachhinein herzuleiten. Die Prämien liegen im Ermessen von Google. Nach eigenen Angaben berücksichtigt Google unter anderem Reproduzierbarkeit, Ausnutzbarkeit, Qualität der Meldung, vorgeschlagene Abhilfemaßnahmen und Eigenständigkeit der Meldung. Die Tabelle enthält einen Basisbetrag für Speichersicherheitsfehler, mehrere V8-bezogene Multiplikatoren und deutlich höhere bedingte Boni für geeignete Exploit-Ketten.

Diese veröffentlichten Zahlen beschreiben einen Rahmen, keine Rechnung. Wir wissen nicht, welche Zeile Google herangezogen hat, ob eine Anpassung vorgenommen wurde oder welche Nachweise die ursprüngliche Meldung enthielt. Ebenso wenig wissen wir, ob der aktiv eingesetzte Exploit der Arbeit des Forschers ähnelte.

Das v8CTF sorgt für eine zweite mögliche Verwechslung. Seine offiziellen Regeln nennen eine Prämie von 10.000 $ für die erste gültige Flag gegen eine festgelegte Version, sofern alle Bedingungen erfüllt sind. Gulizia schreibt, er habe eine gültige Flag eingereicht, nachdem er diesen Bug mit einem n-Day-Escape verkettet hatte. Keine öffentlich auffindbare Primärquelle bestätigt für diesen Fall, dass Google diese Flag anerkannt oder bezahlt hat. 10.000 $ und 1.000 $ zu addieren, würde aus einer möglichen separaten Prämie eine falsche Gesamtsumme machen.

Trennen Sie drei Leistungen voneinander:

1. Schwachstellenmeldung: eine klare, eigenständige Beschreibung, mit der der Anbieter eine Sicherheitslücke reproduzieren und beheben kann.
2. Exploit-Primitive: eine zuverlässige Fähigkeit wie kontrollierter Speicherzugriff, die eine weitergehende Ausnutzung ermöglicht.
3. Vollständige Kette: die Komponenten, die nötig sind, um relevante Sicherheitsgrenzen zu überwinden und ein End-to-End-Ergebnis zu erreichen.

Programme bewerten diese Leistungen häufig unterschiedlich, weil sie unterschiedliche Arbeit erfordern und unterschiedliche Auswirkungen belegen. Der endgültige Betrag kann außerdem von der Qualität der Meldung, Neuartigkeit, Abhilfemaßnahmen, Duplikaten, dem Geltungsbereich und programmspezifischen Boni abhängen. Deshalb kann der Schweregrad allein nicht den Preis bestimmen.

Wie sollte ein Startup die Höhe einer Bug-Bounty-Prämie festlegen?

Nutzen Sie einen Ablauf mit vier getrennten Protokollen. Jedes hat einen anderen Verantwortlichen, einen eigenen Nachweisstandard und ein eigenes Ergebnis. Ziel ist nicht mehr Bürokratie. Es geht darum, zu verhindern, dass eine einzige emotional aufgeladene Bezeichnung über alles entscheidet.

1. Technischen Schweregrad bewerten

Reproduzieren Sie das Problem und halten Sie fest, welche Grenze überwunden wurde. Erfassen Sie erforderliche Berechtigungen und Interaktionen, das betroffene System sowie die Auswirkungen auf Vertraulichkeit, Integrität und Verfügbarkeit. Nennen Sie auch die Grenze, die nicht überwunden wurde. In diesem Fall ist „innerhalb der Sandbox“ genauso wichtig wie „beliebige Codeausführung“.

Lassen Sie einen CVSS-Wert nicht für sich allein stehen. Speichern Sie den Vektor und seine Begründung, damit andere Prüfer nachvollziehen können, wie der Wert zustande kam.

2. Dringlichkeit der Behebung festlegen

Verbinden Sie den Schweregrad mit der aktuellen Exposition und Erkenntnissen zur Bedrohungslage. Über das Internet erreichbare Systeme, verfügbarer Exploit-Code, aktive Ausnutzung und ein KEV-Eintrag können eine Meldung vor ein technisch ähnliches Problem rücken. Das ist eine Priorisierungsentscheidung. Sie kann sich schnell ändern, wenn neue Erkenntnisse vorliegen.

Die Dringlichkeit sollte die Einreichung des Forschers nicht stillschweigend umdeuten. Wird die Ausnutzung erst nach der Meldung bekannt, beschleunigen Sie die Behebung und dokumentieren Sie das neue Signal. Gewähren Sie einen Bonus nur, wenn Ihre veröffentlichte Richtlinie das vorsieht oder ein Mensch ausdrücklich eine Ausnahme nach Ermessen genehmigt.

3. Geliefertes Exploit-Material einordnen

Halten Sie fest, was der Forscher tatsächlich geliefert hat, nicht, was Ihr Team später entwickelt hat. Eine knappe Systematik hilft:

Dieser Datensatz verhindert, dass sich die zugerechnete Leistung nachträglich verschiebt. Er liefert Ihnen außerdem eine belastbare Begründung dafür, zwei Sicherheitslücken mit demselben Schweregrad an unterschiedlichen Stellen innerhalb einer Prämienbandbreite einzuordnen.

4. Über die Prämie beraten und sie genehmigen

Beginnen Sie mit der veröffentlichten Prämienspanne. Vergleichen Sie anschließend Leistung, Qualität, Eigenständigkeit und alle schriftlich festgelegten Boni. Legen Sie einen Betrag mit Begründung vor. Lassen Sie Prüfer mit einem Alternativbetrag widersprechen, nicht nur mit einem Daumen nach unten. Verlangen Sie abschließend, dass eine namentlich benannte, befugte Person die Prämie genehmigt.

Ihr Entscheidungsprotokoll sollte fünf Fragen beantworten:

• Welche Richtlinie und welche Schweregradstufe galten?
• Was hat der Forscher geliefert?
• Welche Faktoren bestimmten die Position des Vorschlags innerhalb der Spanne?
• Welche Alternativen haben die Prüfer erwogen?
• Wer hat den endgültigen Betrag wann genehmigt?

Falls das bedächtiger klingt, als eine Zahl in ein Auszahlungsformular einzutragen, ist genau das beabsichtigt. Mit der Genehmigung wird eine Prämie zu einem bindenden Versprechen nach außen. Die interne Beratung sollte bis dahin revidierbar bleiben. Der Leitfaden zu Prämien und Auszahlungen behandelt den Punkt, an dem aus der Beratung eine Zahlung wird.

Warum Patch-Dringlichkeit und faire Prämien getrennte Datensätze brauchen

Eine aktiv ausgenutzte Sicherheitslücke sollte den Behebungsprozess schnell durchlaufen. Das bedeutet nicht, dass Informationen zur Bedrohungslage die Prämie automatisch neu festlegen sollten. Fairness entsteht, wenn bekannte Regeln auf den tatsächlichen Beitrag des Forschers angewendet und Ausnahmen ehrlich dokumentiert werden.

Der Chrome-Fall zeigt alle vier Zustände gleichzeitig. Die Sicherheitslücke war technisch schwerwiegend. Die aktive Ausnutzung machte den Patch dringend. Öffentliche Belege beschreiben eine Primitive innerhalb der Sandbox sowie einen separaten n-Day-Escape, die in einer Forschungskette verwendet wurden. Google legte eine Prämie von 1.000 $ offen, ohne die Berechnung offenzulegen. Daraus lässt sich nicht schließen, Google habe einen aktiv eingesetzten Angriff auf Chrome mit 1.000 $ bewertet. Vielmehr erlauben die öffentlichen Fakten nicht, diese Beurteilungen zusammenzufassen.

Wenn Ihr Team Annahmeprozess, Geltungsbereich, Safe Harbor und Reaktionserwartungen erst noch aufbaut, beginnen Sie mit einem Vulnerability Disclosure Program. Ein Prämienprozess kann keinen Annahmeprozess ausgleichen, in dem Nachweise verloren gehen oder Forscher im Unklaren bleiben.

Wie Kit verhindert, dass der Schweregrad automatisch zum Preis wird

Ein guter Auszahlungsprozess braucht einen begrenzten Ausgangspunkt, eine unabhängige Prüfung, dokumentierte Begründungen und eine menschliche Entscheidung. Der CSIRT-Ablauf von Kit unterstützt diese Kontrollen, ohne vorzugeben, den richtigen Preis ermitteln zu können.

Kit speichert Mindest- und Höchstbeträge für jeden Schweregrad. Eine Bewertung erstellt eine Momentaufnahme des vorgeschlagenen Bereichs. Deren Höchstbetrag begrenzt Vorschläge, Gegenvorschläge und Prämien. Enthält diese Momentaufnahme keinen Höchstbetrag, greift Kit auf den aktuellen Höchstbetrag des Schweregrads zurück. Lässt sich für ein Matrixprogramm weiterhin kein Höchstbetrag ermitteln, blockiert Kit die Auszahlung vorsorglich.

Für eine nicht offensichtliche Prämie kann ein Teammitglied einen Prämienvorschlag mit einer Begründung erstellen, die verschlüsselt gespeichert wird. Die Abstimmung ist standardmäßig verdeckt, sodass gewöhnliche Prüfer weder Namen noch Positionen oder Gegenvorschläge sehen, bevor sie selbst abgestimmt haben. Ein Einwand muss einen positiven Alternativbetrag enthalten. Das Stimmenbild dient der befugten genehmigenden Person als Entscheidungsgrundlage, ist aber nur beratend: Es gibt kein automatisches Quorum, keine Konsensregel und keine automatische Auszahlung.

Das ist Beratung, keine Berechnung. Kit übernimmt derzeit keine Daten aus CVE, NVD, CISA KEV oder EPSS. Es berechnet Prämien weder aus CVSS noch aus dem Ausnutzungsstatus. Es besitzt keinen externen Datensatz mit Vergleichswerten für Prämien, unterscheidet nicht zwischen einer Exploit-Primitive und einem Sandbox-Escape und bewahrt keine unveränderliche Version der Prämienmatrix oder Richtlinie vom Zeitpunkt der Einreichung auf. Der Bereich zum Zeitpunkt der Bewertung ist eine Momentaufnahme, wird aber erst nach der Einreichung erfasst.

Diese Grenzen sind wichtig. Software kann Eingaben bewahren, Ankereffekte verringern, einen Höchstbetrag durchsetzen und die Entscheidung protokollieren. Sie kann aus dem Schweregrad keinen objektiven Preis machen. Wenn Sie einen geordneteren Prozess für strittige Prämien suchen, lesen Sie, wie Prämienvorschläge und Teamabstimmungen funktionieren, und entscheiden Sie dann, ob diese Disziplin zu Ihrem Programm passt.

Der praktische Maßstab ist einfach: Bewerten Sie die Sicherheitslücke, priorisieren Sie ihre Behebung, ordnen Sie die gelieferten Nachweise ein und beraten Sie über den Betrag, bevor er zum Versprechen wird. Halten Sie diese vier Protokolle getrennt, dann lässt sich auch eine überraschende Zahl erklären, statt nur für eine Schlagzeile zu sorgen.