Le problème du correctif silencieux : pourquoi « corrigé » ne veut pas dire « divulgué »

Un correctif silencieux, c’est la correction d’une faille de sécurité livrée sans CVE, sans avis de sécurité publié et sans en avertir la personne qui l’a signalée. Pour un défenseur, un correctif silencieux ne se distingue en rien d’une absence totale de correction : impossible de le citer, de le vérifier ou de savoir si la version que vous exécutez le contient. Une divulgation complète, ce n’est pas seulement du code fusionné. C’est une version corrigée dûment numérotée, un identifiant CVE, un avis de sécurité publié, une notification à l’auteur du rapport et une reconnaissance publique. Faites l’impasse sur ces éléments, et « corrigé » n’est plus qu’une affirmation privée, pas un résultat de sécurité.

La plupart des programmes de divulgation des vulnérabilités (VDP) considèrent la pull request fusionnée comme la ligne d’arrivée. Ce n’est que la moitié du chemin. La moitié « rapport et récompense » — réception, triage, récompense — concentre toute l’attention et tout l’outillage. La moitié « correction et divulgation », celle qui commence après que le code est corrigé, c’est là que même les programmes rigoureux échouent en silence. C’est cette histoire que nous racontons ici, à travers l’exemple récent le plus limpide d’un tel dérapage.

Le correctif Cursor que personne n’a pu vérifier

En juillet 2026, la couverture médiatique d’une vulnérabilité de Cursor s’est divisée sur une question qui ne devrait jamais prêter à ambiguïté : était-elle corrigée, oui ou non ?

Reprenons le fil des faits. Le 15 décembre 2025, l’entreprise de sécurité IA Mindgard a signalé une faille d’exécution de code sous Windows dans l’IDE Cursor à [email protected]. Le mécanisme est aussi vicieux que simple : un git.exe malveillant déposé à la racine d’un dépôt cloné s’exécute automatiquement dès l’ouverture du projet. Cursor lance git rev-parse --show-toplevel et, comme l’ordre de recherche de Windows inspecte le répertoire de travail avant les chemins système, c’est le binaire de l’attaquant qui s’exécute à la place du vrai Git, avec les privilèges du développeur et sans la moindre confirmation. Mindgard a confirmé la vulnérabilité jusqu’à Cursor 3.2.16 inclus, lors d’un test réalisé le 30 avril 2026.

Puis le rapport est tombé dans le silence. Selon la chronologie de Mindgard, les demandes de mise à jour de février, mars et avril 2026 sont restées sans réponse. Le 1ᵉʳ juin 2026, Mindgard a annoncé son intention de publier. Ce qu’elle a fait le 14 juillet 2026, sous la forme d’un compte rendu technique complet, 213 jours après le rapport initial.

Ce n’est qu’alors qu’un porte-parole de Cursor a déclaré à Dark Reading que l’entreprise avait « traité le problème le 13 juillet 2026 » et allait contacter Mindgard. Mais ce prétendu correctif ne mentionnait aucune version corrigée, ne s’accompagnait d’aucun avis de sécurité publié et ne portait aucun CVE. The Hacker News a passé en revue les avis de sécurité publiés par Cursor et n’a trouvé aucune entrée relative au problème au 15 juillet. Cursor 3.11 était sortie le 10 juillet, soit avant le correctif annoncé du 13 juillet : la dernière version publique que l’on pouvait citer ne le contenait donc pas.

C’est pourquoi des médias sérieux ont présenté le bug comme toujours non corrigé, même après que l’éditeur eut affirmé le contraire. Les deux affirmations étaient « vraies », parce que le correctif n’existait que sous la forme d’une assertion invérifiable. Un correctif que personne ne peut citer, confirmer ou rattacher à une version n’est, dans les faits, pas un correctif. Toute la leçon tient dans cette contradiction.

Qu’est-ce qu’un correctif silencieux ?

Un correctif silencieux, c’est une correction qui referme une faille pertinente pour la sécurité, mais qui n’est jamais présentée comme telle : pas de CVE, souvent pas d’avis de sécurité, parfois noyée dans une version sans rapport. Le code change ; le monde n’apprend jamais ce qui a changé, ni pourquoi. Une divulgation complète, à l’inverse, comporte cinq volets :

1. Une version corrigée dûment numérotée. « Corrigé dans la 3.12.0 », pas « corrigé ».
2. Un identifiant CVE, pour que la faille porte un nom stable et interrogeable.
3. Un avis de sécurité publié décrivant la vulnérabilité, les versions touchées et la mesure d’atténuation.
4. Une notification à l’auteur du rapport l’informant que le correctif est livré.
5. Une reconnaissance publique pour le chercheur qui l’a découverte.

Qu’il en manque un seul, et les utilisateurs ne peuvent plus répondre à la seule question qui compte pour eux : suis-je protégé, et à partir de quelle version ?

Pourquoi les éditeurs le font : raisons innocentes et raisons intéressées

Les raisons couvrent tout un spectre. À l’extrémité innocente : un mainteneur n’a jamais réalisé qu’un bug avait une dimension de sécurité, ou une toute petite équipe n’a aucun processus pour demander un CVE et rédiger un avis. À l’extrémité intéressée : la réticence à admettre publiquement l’existence de la faille, la crainte pour son image, ou l’espoir qu’une correction discrète fera disparaître le problème.

L’intention ne change rien au résultat. Que le silence vienne d’un mainteneur débordé ou d’un service de communication anxieux, le défenseur situé en aval reçoit la même chose : un correctif qu’il ne peut pas voir.

Pourquoi un correctif silencieux profite aux attaquants, pas à vous

Un correctif silencieux ne protège pas les utilisateurs. Il donne aux attaquants un avantage sur eux. C’est le point contre-intuitif, et il mérite d’être dit clairement.

Comme le résume Tod Beardsley, de Rapid7 : « quand vous corrigez en silence, vous communiquez les détails de la vulnérabilité, exclusivement, à des attaquants criminels aguerris ». Toute l’asymétrie est là. Lorsqu’un correctif atterrit dans une base de code publique, les attaquants motivés comparent les versions corrigée et non corrigée (le fameux diff), reconstituent la faille à partir de la modification et la transforment en arme, souvent en quelques jours. Ce travail est largement à la portée de tout adversaire compétent qui parcourt l’historique des commits avec de mauvaises intentions.

Les défenseurs, eux, ne font pas cela. Ils ne rétro-conçoivent pas chaque commit discret de chaque dépendance. Ils comptent sur les avis de sécurité pour savoir ce qui a changé et si cela les concerne. Un correctif silencieux trace donc une ligne nette : la faille devient parfaitement visible pour la petite population prête à la traquer, et reste invisible pour la vaste population qui aurait appliqué le correctif si seulement on l’en avait informée. Ceux qui mettent à jour dans les temps, qui lisent les avis, qui font tout comme il faut, sont précisément ceux qui restent exposés, tandis que les attaquants sont, eux, « informés ».

Le silence n’achète pas la sécurité par l’obscurité. Il offre à l’attaquant une longueur d’avance.

La moitié du cycle de vie que tout le monde oublie

La plupart des équipes modélisent le cycle de vie de la divulgation ainsi : rapport → triage → correction. Le modèle complet y soude trois étapes supplémentaires : → CVE → avis → notification. Cette fin de parcours n’est pas une politesse. Les normes la codifient.

Les normes ISO/IEC 29147 (divulgation des vulnérabilités) et ISO/IEC 30111 (traitement des vulnérabilités) définissent les obligations de l’éditeur, et un avis de sécurité publié en fait explicitement partie : une description de la vulnérabilité, les versions touchées et la mesure d’atténuation, idéalement au format lisible par machine CSAF 2.0 afin que les scanners et les équipes en aval puissent l’exploiter automatiquement. En divulgation coordonnée, l’avis paraît en même temps que le correctif ou peu après. « Jamais » n’est pas une option que la norme envisage.

Il existe aussi des compteurs, et ils mesurent l’intégralité du chemin jusqu’à la divulgation publique, pas seulement la fusion :

Ce sont les délais d’équité admis par le secteur. Mesuré à l’aune de n’importe lequel d’entre eux, un rapport accusé de réception en décembre et toujours dépourvu d’avis ou de CVE en juillet suivant n’est pas « en cours ». Il est en retard au regard de toutes les références publiées qui existent.

Un CVE n’est pas facultatif, et les éditeurs en attribuent eux-mêmes

L’excuse la plus courante pour justifier un CVE manquant — en attribuer un serait difficile ou réservé à quelques acteurs — ne résiste pas à l’examen du fonctionnement réel du système. Les identifiants CVE sont attribués par les CVE Numbering Authorities (CNA), et de nombreux éditeurs sont leur propre CNA. Lorsqu’un éditeur ne l’est pas, des CNA tiers, des CERT et des plateformes comme HackerOne peuvent en attribuer un pour son compte. Être éditeur n’est en rien un obstacle à l’obtention d’un CVE ; c’est souvent la voie la plus simple pour en obtenir un.

Le propre historique de Cursor le démontre. D’autres vulnérabilités de Cursor en 2026 ont bel et bien reçu des CVE et des avis : la RCE de contournement de confiance MCP de Check Point, les RCE « DuneSlide » par injection d’invite sans clic de Cato Networks, et des failles RCE au niveau du système d’exploitation couvertes par SecurityWeek. La machinerie existait et fonctionnait. Elle n’a simplement jamais été braquée sur le rapport du git.exe. Le silence relève donc d’une lacune de processus, pas d’une lacune de capacité : un choix quant aux rapports qui reçoivent le traitement complet et ceux que l’on abandonne discrètement.

« Corrigé mais non divulgué » est un dépassement de SLA, pas un ticket clos

Ce changement de perspective transforme la manière de mener un programme. La plupart des VDP disposent d’un statut terminal signifiant « c’est corrigé » : resolved, fix_verified, closed, paid. Un rapport l’atteint dès la fusion du correctif, et le ticket disparaît du tableau.

Ce statut est un mensonge par omission. Un rapport corrigé mais dépourvu de CVE, d’avis et de notification au chercheur n’est pas terminé. Il est en infraction : envers le travail du chercheur, envers le droit des utilisateurs à savoir qu’ils sont exposés, et envers les normes qui définissent ce qu’est une divulgation. Le rapport Cursor était, de l’aveu même de l’éditeur, « traité » le 13 juillet. Il était aussi, simultanément, en infraction sur les trois plans. Les deux étaient vrais parce que « traité » et « divulgué » sont deux états distincts, et un seul d’entre eux était suivi.

Le périmètre d’exposition rend le coût concret. Cursor compte plus d’un million d’utilisateurs actifs quotidiens, plus d’un million d’abonnés payants et plus de 50 000 entreprises utilisatrices. Chacun d’eux a traversé la période de non-divulgation sans pouvoir répondre à « suis-je protégé, et à partir de quelle version ? », car la réponse n’a jamais été publiée. Un correctif silencieux fait croître son préjudice à la mesure de la base d’utilisateurs qu’il réduit au silence.

Traitez « corrigé mais non divulgué » comme vous traitez déjà un SLA d’accusé de réception dépassé : comme un dépassement qui s’affiche en rouge, pas comme un ticket qui se ferme en silence.

Une liste de contrôle de divulgation que l’on peut mettre en place

L’angle mort qu’aucune couverture d’incident ne comble est l’angle opérationnel : comment rendre un correctif silencieux impossible à classer comme terminé dans votre propre programme ? La voici. Elle est délibérément réalisable sur les mêmes rails qui suivent déjà la réception et le triage.

1. Ajoutez un statut terminal disclosed. Un rapport n’est pas terminé à fix_verified ; il doit passer par disclosed. Faites-en un verrou de clôture, exactement comme resolved aujourd’hui. Pas de divulgation, pas de « terminé ».
2. Déclenchez une demande de CVE à fix_verified. Le passage à l’état « corrigé » devrait automatiquement inviter à ouvrir une demande de CVE — auprès de votre propre CNA ou d’un CNA tiers — et enregistrer l’identifiant attribué sur le rapport. Pas d’identifiant, pas de clôture.
3. Attachez un modèle d’avis et une étape de publication. Réutilisez l’espace public de votre politique de sécurité pour publier un avis — versions touchées, atténuation et reconnaissance —, mis en forme pour CSAF afin que les machines puissent le lire. Le modèle transforme « rédiger un avis » d’une page blanche en un formulaire.
4. Posez-lui un compteur de divulgation. Ajoutez un SLA de divulgation — « avis publié dans les N jours suivant fix_verified » — et faites-le transiter par la même mécanique « à risque » et « dépassé » que vous utilisez déjà pour l’accusé de réception. Au-delà de N jours, cela devient un dépassement sur le tableau, remontée à l’astreinte, pas un ticket clos et invisible.
5. Regroupez reconnaissance et notification. Rattachez la reconnaissance du chercheur figurant dans l’avis à votre tableau d’honneur et à votre parcours de réputation, et envoyez un message « votre rapport est désormais public » via votre registre existant de communication avec les chercheurs. La boucle se referme avec la personne qui l’a ouverte.

Mettez cela en place, et un rapport ne pourra physiquement pas atteindre l’état « terminé » tant qu’il reste un correctif silencieux. Le tableau de statuts impose la divulgation comme il impose déjà le triage.

Comment Kit tient les correctifs silencieux à l’écart du tableau

La verticale CSIRT de Kit gère déjà la moitié « rapport et récompense » d’un VDP sur des rails de SLA, et c’est précisément le socle dont a besoin la moitié « divulgation ». Pour être clair sur ce qui est livré par rapport à ce que cet article propose : les SLA d’accusé de réception et de résolution par niveau de gravité, la mécanique de statuts « à risque » et « dépassé », l’escalade vers l’astreinte, les transitions de statut auditables, la synchronisation de conformité en aval et le parcours de reconnaissance du tableau d’honneur sont autant de fonctionnalités déjà en production. Kit n’a rien à voir avec le bug de Cursor, et aucun outil n’empêche un éditeur d’écrire du mauvais code.

Ce que l’architecture de Kit apporte réellement, c’est le socle qui rend un correctif silencieux structurellement difficile à dissimuler :

• Des compteurs de SLA avec états « à risque » et « dépassé », déjà appliqués aux objectifs d’accusé de réception et de résolution par niveau de gravité. C’est ce même mécanisme de compteur qui fait tourner un SLA de divulgation : « avis publié dans les N jours » emprunte le chemin de dépassement identique.
• L’escalade vers l’astreinte, pour qu’un compteur qui dérive alerte un humain au lieu de vieillir en silence — toute la différence entre le rapport Cursor resté sans réponse pendant des mois et un dépassement qui remonte à la surface.
• Des transitions de statut auditables par rapport, de sorte qu’ajouter un état disclosed qui verrouille la clôture est une extension du cycle de vie existant, pas un nouveau système.
• La synchronisation de conformité en aval et un parcours de reconnaissance via le tableau d’honneur, pour que la reconnaissance du chercheur dans un avis et la notification « vous êtes désormais public » circulent sur des rails qui existent déjà.

Un correctif silencieux est, structurellement, un dépassement de SLA qu’aucun outil actuel ne mesure. Kit mesure déjà les dépassements de SLA. Braquer cette même discipline sur la divulgation, voilà la marche à suivre — et sa place est sur le tableau même qui suit l’accusé de réception et le triage.

À retenir : la divulgation est une transition de statut, pas une fusion

Un programme de divulgation des vulnérabilités n’est pas terminé quand le correctif est livré. « Corrigé mais non divulgué » est une infraction envers le rapport, envers le travail du chercheur et le droit des utilisateurs à savoir, et cela devrait s’afficher en rouge sur le tableau même qui suit l’accusé de réception et le triage.

L’histoire de Cursor n’est pas un scandale isolé. C’est le mode de défaillance par défaut de tout programme dont le cycle de vie s’achève discrètement à « fusionné ». Le remède n’est pas plus de rigueur dans la correction — ces équipes corrigent déjà avec rigueur. C’est de traiter le CVE, l’avis, la notification et la reconnaissance comme des transitions de statut obligatoires par lesquelles un rapport doit passer avant de pouvoir être déclaré terminé.

Si vous mettez en place le volet réception, commencez par comment mettre en place un programme de divulgation des vulnérabilités. Pour ce qui se passe quand la relation se rompt avant le correctif, voyez quand les chercheurs rendent tout public et notre analyse des SLA et de l’équité dans le paiement des primes de bug bounty. Et si vous vendez en Europe, les obligations de divulgation imposées par le Cyber Resilience Act de l’UE font passer l’étape de l’avis du statut de bonne pratique à celui de loi. C’est le chapitre final de toutes ces histoires : le rapport n’est pas terminé tant qu’il n’est pas divulgué.