Prime de 1 000 $ pour Chrome : la gravité n'est pas un prix

La gravité d’une vulnérabilité ne détermine pas à elle seule le montant d’une prime. Elle mesure les conséquences techniques dans des conditions données. L’urgence de la correction tient aussi compte de l’exploitation active et de l’exposition de l’actif. La prime dépend en outre de ce que le chercheur a fourni, des règles publiées par le programme, de la qualité du rapport, des bonus et d’une décision humaine.

Cette distinction éclaire une mention a priori déconcertante dans l’avis publié par Google sur Chrome en septembre 2026. CVE-2026-85046 était une faille de gravité élevée dans V8. Google indiquait que la faille était activement exploitée. La prime annoncée s’élevait à 1 000 $.

Ce montant ne paraît absurde que si vous supposez que « gravité élevée », « exploitation active » et « prime » sont trois façons de chiffrer la même chose. Ce n’est pas le cas. Pour l’équipe de sécurité d’une startup, cet exemple montre pourquoi il faut dissocier quatre décisions : la gravité technique, l’urgence de la correction, les éléments d’exploitation fournis et la délibération sur la prime.

Pourquoi Google n’a-t-il annoncé qu’une prime de 1 000 $ pour une faille Chrome exploitée ?

Réponse courte : les informations publiques ne révèlent pas le calcul de Google. Elles décrivent une vulnérabilité, une priorité de correction et une prime finale. Ces faits relèvent de systèmes différents.

Dans sa mise à jour du canal stable du 3 septembre, Google a classé CVE-2026-85046 comme une « confusion de types dans V8 » de gravité élevée. L’entreprise a attribué la découverte au chercheur Salvatore Gulizia, alias Serotav, précisé qu’il l’avait signalée le 4 août et annoncé une prime de 1 000 $. Google a également indiqué que la faille était activement exploitée.

Les versions corrigées étaient 152.0.7977.82 ou .83 pour Windows et macOS, et 152.0.7977.82 pour Linux. La mise à jour comprenait 12 correctifs de sécurité. Google a indiqué que l’accès aux détails des failles pouvait rester restreint jusqu’à ce que la majorité des utilisateurs aient installé la mise à jour.

Ce tableau ne contient aucune contradiction. L’erreur consiste à vouloir déduire la dernière ligne des trois premières.

C’est aussi pour cette raison qu’une grille des primes doit proposer des fourchettes plutôt qu’un tarif. Si votre tableau affirme « gravité élevée égale 1 000 $ », il masque les questions qui distinguent deux rapports du même niveau. Le chercheur a-t-il fourni un cas de test qui provoque un plantage, une preuve de concept fiable, une primitive d’exploitation réutilisable, une mesure d’atténuation ou une chaîne complète ? Le rapport était-il clair et original ? La fourchette liée à la gravité encadre la discussion, sans pouvoir s’y substituer. Notre guide sur les niveaux de primes que les chercheurs peuvent juger fiables explique comment publier ce socle sans en faire une formule rigide.

CVE-2026-85046 permet-elle de sortir du bac à sable de Chrome ?

Non, d’après les éléments publics. La fiche CVE officielle indique que du code HTML spécialement conçu pouvait permettre l’exécution de code arbitraire dans le bac à sable (sandbox). Cette exécution dans le moteur JavaScript V8 de Chrome est grave, mais elle n’équivaut pas à sortir du bac à sable ni à prendre le contrôle du système d’exploitation.

Chrome isole le contenu web dans un processus de rendu restreint. Si un attaquant y obtient l’exécution de code, le bac à sable doit empêcher ce code d’accéder librement au système hôte. Une chaîne de compromission complète du navigateur nécessite souvent une autre vulnérabilité pour franchir cette frontière. L’équipe Project Zero de Google a documenté cette distinction dans ses travaux sur la sortie du bac à sable de Chrome.

L’analyse technique de Gulizia rend cette limite particulièrement nette. Il décrit une confusion de types qui permet la lecture et l’écriture arbitraires dans le tas JavaScript. Il précise ensuite avoir enchaîné « cette faille » avec une sortie du bac à sable n-day afin d’obtenir un flag dans le cadre du v8CTF. Autrement dit, cette CVE fournissait un maillon de la chaîne. Un autre code d’exploitation, déjà connu, permettait de sortir du bac à sable.

Cette distinction compte à deux titres.

Premièrement, elle délimite l’affirmation technique. Présenter cette CVE comme une « sortie du bac à sable » lui attribuerait les capacités du second code d’exploitation. La formule anglaise « sandbox RCE » est elle aussi risquée, car nombre de lecteurs comprendront que l’exécution de code a franchi le bac à sable. La formulation exacte est exécution de code arbitraire dans le processus de rendu V8 placé dans le bac à sable de Chrome.

Deuxièmement, elle encadre la discussion sur la prime. Une faille V8 qui fournit une primitive utile et une compromission complète et fonctionnelle du navigateur ne constituent pas le même livrable. Un programme peut légitimement leur appliquer des catégories et des bonus distincts. Une analyse externe publiée après coup ne permet pas de déduire ce que Google a reçu.

Le titre soumis à Hacker News affirmait également que la faille touchait « toutes les versions de Chromium ». L’historique du code dit le contraire. L’optimisation d’Array.prototype.sort en cause a été intégrée à V8 le 27 avril 2026. La correspondance des versions de V8 associe la version 14.9 à Chrome M149. La fiche CVE fixe une borne supérieure, les versions antérieures à 152.0.7977.82, mais ne donne aucune borne inférieure. L’historique du dépôt permet de retrouver ce point de départ.

La CISA indique que le problème pourrait toucher plusieurs navigateurs fondés sur Chromium, dont Chrome, Edge et Opera. C’est une invitation à consulter l’avis de chaque éditeur, pas la preuve que chaque dérivé de Chromium ou chaque version historique était vulnérable.

Pourquoi CVSS et le catalogue KEV de la CISA répondent-ils à des questions différentes ?

CVSS décrit les caractéristiques techniques. Le catalogue Known Exploited Vulnerabilities (KEV) de la CISA signale aux équipes de défense que l’exploitation est passée du possible à l’observé. Vous avez besoin de ces deux signaux, sans les fusionner en un score ou une règle de rémunération unique.

La fiche CVE officielle décrit une page HTML spécialement conçue qui permet l’exécution de code arbitraire dans le bac à sable. Elle classe la faiblesse sous CWE-843, l’accès à une ressource au moyen d’un type incompatible. Le score de 8,8 affiché par la NVD provient d’une évaluation secondaire CISA ADP, et non d’une évaluation distincte de la NVD.

Son vecteur est AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H. En clair :

• La vulnérabilité est exploitable depuis le réseau.
• Sa complexité est faible.
• Elle ne nécessite aucun privilège préalable.
• Elle exige une interaction de l’utilisateur, par exemple l’ouverture d’un contenu web spécialement conçu.
• Le périmètre reste inchangé, ce qui concorde avec une exécution dans le bac à sable.
• Les conséquences sur la confidentialité, l’intégrité et la disponibilité sont classées élevées dans ce périmètre.

CVSS ne cherche pas à savoir si un code d’exploitation circule cette semaine. Le catalogue KEV répond à cette autre question. La CISA a ajouté CVE-2026-85046 à son catalogue KEV le 4 septembre et fixé au 18 septembre l’échéance de correction pour les agences fédérales concernées. Les entreprises privées ne sont pas soumises à cette échéance fédérale, mais ce signal reste utile sur le plan opérationnel : l’équipe doit cesser de débattre du caractère purement théorique de l’attaque et placer la mise à jour en tête de file.

La règle à retenir est simple : CVSS aide à décrire les conséquences, KEV à ordonner le travail. Aucun des deux ne calcule une prime. Si votre programme veut verser un bonus lorsqu’un rapport apporte la preuve d’une exploitation active, inscrivez cette règle dans la politique. Ne l’improvisez pas après la publication d’un titre accrocheur.

Qu’est-ce que la prime Chrome de 1 000 $ a réellement récompensé ?

Une seule réponse est défendable : l’avis Chrome indique qu’il s’agit de la prime versée pour le rapport de Gulizia sur cette CVE. Les informations publiques ne précisent ni la catégorie exacte du VRP, ni le calcul, ni le contenu du rapport confidentiel.

Les règles actuelles du Chrome Vulnerability Reward Program expliquent pourquoi il serait hasardeux de reconstituer le montant. Les primes sont discrétionnaires. Google dit prendre en compte la reproductibilité, l’exploitabilité, la qualité du rapport, les mesures d’atténuation proposées et l’originalité du signalement. Le barème comprend une base pour les vulnérabilités liées à la sécurité de la mémoire, plusieurs multiplicateurs liés à V8 et des bonus conditionnels bien supérieurs pour certaines chaînes d’exploitation admissibles.

Ces chiffres publiés décrivent un cadre, pas une facture. Nous ignorons quelle ligne Google a appliquée, si un ajustement est intervenu et quels éléments accompagnaient le rapport d’origine. Nous ne savons pas non plus si le code d’exploitation observé dans des attaques réelles ressemblait aux travaux du chercheur.

Le v8CTF ajoute une seconde source de confusion. Son règlement officiel prévoit une prime de 10 000 $ pour le premier flag valide et admissible obtenu sur une version désignée. Gulizia affirme avoir obtenu un flag en enchaînant cette faille avec une sortie du bac à sable n-day. Nous n’avons trouvé aucune source primaire publique confirmant que Google a validé ou payé ce flag. Additionner les 10 000 $ aux 1 000 $ transformerait une éventuelle prime distincte en faux total.

Il faut distinguer trois livrables :

1. Rapport de vulnérabilité : une description claire et originale qui permet à l’éditeur de reproduire et de corriger une faille de sécurité.
2. Primitive d’exploitation : une capacité fiable, telle qu’un accès contrôlé à la mémoire, qui rend possible la suite de l’exploitation.
3. Chaîne complète : tous les composants nécessaires pour franchir les frontières de sécurité pertinentes et obtenir un résultat de bout en bout.

Les programmes peuvent leur attribuer des valeurs différentes, car ces livrables demandent un travail différent et démontrent des conséquences distinctes. Le montant final peut aussi dépendre de la qualité du rapport, de sa nouveauté, des mesures d’atténuation, du fait qu’il s’agisse d’un doublon, du périmètre et des bonus propres au programme. La gravité ne peut donc pas, à elle seule, fixer le prix.

Comment une startup doit-elle décider du montant d’une prime ?

Utilisez quatre registres distincts. Chacun a son responsable, son niveau de preuve et son résultat. Il ne s’agit pas d’ajouter de la bureaucratie, mais d’empêcher une seule étiquette chargée d’émotion de décider de tout.

1. Évaluer la gravité technique

Reproduisez le problème et notez la frontière qui a été franchie. Consignez les privilèges requis, l’interaction nécessaire, l’actif concerné ainsi que les conséquences sur la confidentialité, l’intégrité et la disponibilité. Indiquez aussi la frontière qui n’a pas été franchie. Dans ce cas, « dans le bac à sable » compte autant que « exécution de code arbitraire ».

Ne laissez pas un score CVSS se suffire à lui-même. Conservez le vecteur et sa justification afin qu’un autre évaluateur puisse comprendre comment le score a été obtenu.

2. Fixer l’urgence de la correction

Associez la gravité à l’exposition actuelle et aux informations disponibles sur la menace. Un actif exposé sur Internet, un code d’exploitation accessible, une exploitation active ou une inscription au catalogue KEV peuvent faire passer un rapport devant un problème techniquement comparable. Il s’agit d’une décision de priorisation, susceptible d’évoluer rapidement à mesure que de nouvelles informations apparaissent.

L’urgence ne doit pas réécrire discrètement le rapport du chercheur. Si une exploitation apparaît après le signalement, accélérez la correction et consignez le nouveau signal. N’appliquez un bonus que si la politique publiée le prévoit ou si une personne habilitée approuve explicitement une exception discrétionnaire.

3. Classer les éléments d’exploitation fournis

Consignez ce que le chercheur a réellement transmis, pas ce que votre équipe a construit par la suite. Une nomenclature concise suffit :

Ce registre évite que le mérite attribué au chercheur ne soit réécrit a posteriori. Il vous donne aussi une raison défendable de retenir des montants différents, au sein d’une même fourchette, pour deux vulnérabilités de même gravité.

4. Délibérer puis approuver la prime

Partez de la fourchette publiée, puis examinez le livrable, la qualité, l’originalité et les éventuels bonus prévus par écrit. Mettez sur la table un montant accompagné d’une justification. Demandez aux évaluateurs en désaccord de proposer un autre montant, plutôt que d’exprimer un simple refus. Enfin, confiez l’approbation à une personne nommément désignée et habilitée.

Le registre de décision doit répondre à cinq questions :

• Quelle politique et quel niveau de gravité s’appliquaient ?
• Qu’a fourni l’auteur du rapport ?
• Quels facteurs ont fait évoluer la proposition dans la fourchette ?
• Quelles autres options les évaluateurs ont-ils envisagées ?
• Qui a approuvé le montant final, et quand ?

Si cette méthode semble plus rigoureuse que la simple saisie d’un chiffre dans un formulaire de paiement, c’est voulu. Une prime devient un engagement envers le chercheur dès son approbation. Jusque-là, l’équipe doit encore pouvoir revenir sur sa décision. Le guide sur les primes et les paiements décrit le moment où la délibération devient un engagement financier.

Pourquoi l’urgence de la correction et l’équité de la prime exigent-elles des registres distincts ?

Une vulnérabilité activement exploitée doit progresser rapidement dans le processus de correction. Pour autant, un signal issu du renseignement sur les menaces ne doit pas réécrire automatiquement la prime. L’équité consiste à appliquer des règles connues à la contribution réelle du chercheur et à consigner honnêtement les exceptions.

Le cas Chrome réunit ces quatre états. La vulnérabilité était techniquement grave. Son exploitation active rendait la correction urgente. Les éléments publics décrivent une primitive limitée au bac à sable, associée à une sortie n-day distincte dans une chaîne de recherche. Google a annoncé une prime de 1 000 $ sans en publier le calcul. Il ne faut pas en conclure que Google a fixé à 1 000 $ la valeur d’une attaque réelle capable de compromettre le navigateur. Les faits publics ne permettent pas de ramener tous ces jugements à une seule conclusion.

Si votre équipe doit encore mettre en place le canal de réception des rapports, le périmètre, la sphère de sécurité (Safe Harbor) et les délais de réponse, commencez par un programme de divulgation des vulnérabilités. Une procédure de prime ne peut pas réparer un canal qui perd les preuves ou laisse les chercheurs dans l’incertitude.

Comment Kit empêche-t-il la gravité de devenir un prix automatique ?

Une bonne gestion des primes exige un point de départ encadré, une revue indépendante, une justification consignée et une décision humaine. Le flux de travail CSIRT de Kit offre ces garde-fous sans prétendre découvrir le juste prix.

Kit conserve un minimum et un maximum pour chaque niveau de gravité. Lors de l’évaluation, Kit fige la fourchette suggérée. Son maximum limite les propositions, les contre-montants et les primes. Si cette fourchette ne comporte aucun maximum, Kit utilise le maximum actuel du niveau concerné. Si, malgré ce repli, aucun plafond ne peut être déterminé pour un programme doté d’une grille, le circuit financier refuse l’opération par sécurité.

Pour une prime qui ne va pas de soi, un membre de l’équipe peut créer une proposition dont la justification est stockée sous forme chiffrée. Le vote est masqué par défaut : les évaluateurs ordinaires ne voient ni les noms, ni les positions, ni les contre-montants avant d’avoir voté. Toute objection doit proposer un autre montant positif. Le décompte éclaire la personne habilitée à approuver, mais reste consultatif : il n’existe ni quorum, ni règle de consensus, ni paiement automatique.

Il s’agit de délibérer, pas de calculer. Kit ne récupère pas actuellement les données CVE, NVD, CISA KEV ou EPSS. Il ne calcule aucune prime à partir du score CVSS ou de l’état d’exploitation. Il ne dispose d’aucune base externe de référence sur les primes, ne distingue pas une primitive d’exploitation d’une sortie du bac à sable et ne conserve pas de version immuable de la grille des primes ou de la politique au moment de l’envoi du rapport. La fourchette issue de l’évaluation constitue bien un instantané, mais elle est enregistrée après l’envoi.

Ces limites comptent. Un logiciel peut conserver les données d’entrée, réduire les biais d’ancrage, imposer un plafond et consigner la décision. Il ne peut pas transformer la gravité en prix objectif. Pour rendre plus clair le traitement des primes contestées, découvrez le fonctionnement des propositions de prime et du vote d’équipe, puis jugez si cette discipline convient à votre programme.

La règle pratique reste modeste : évaluez la faille, hiérarchisez la correction, classez les éléments fournis et débattez du montant avant qu’il ne devienne une promesse. Si vous tenez ces quatre registres séparément, vous pourrez expliquer un chiffre surprenant au lieu d’en faire un titre accrocheur.