Divulgation publique : les chercheurs qui lâchent l'éditeur

Trois zero-days Microsoft Defender lâchés dans la nature en quinze jours. Pas par un groupe APT, pas par un courtier d'exploits — par un chercheur indépendant qui a fini par claquer la porte après dix-huit mois de tentatives de communication constructive avec MSRC. Ce n'est pas un cas isolé, c'est un signal. Et il dit que le modèle de divulgation responsable, tel qu'on l'a connu pendant vingt ans, est en train de craquer sous le poids de pratiques qui ont progressivement déséquilibré un contrat moral autrefois fonctionnel. Les conséquences ne sont pas théoriques : elles se mesurent en jours d'exposition supplémentaires, en fenêtres d'exploitation non anticipées, et en SOC qui doivent défendre contre des menaces que leurs outils de patch management ne leur ont pas signalées. Voici ce qui se passe réellement, pourquoi les éditeurs en portent une responsabilité directe, et ce que les équipes défensives doivent changer maintenant.

Le contrat moral de la divulgation responsable : comment il a été cassé

Le deal historique entre chercheurs et éditeurs tenait sur trois engagements implicites, formalisés progressivement par des programmes comme Google Project Zero et les bug bounties majeurs. Premièrement, le chercheur remonte la faille de manière privée. Deuxièmement, l'éditeur la corrige dans un délai raisonnable — 90 jours est la norme établie par Project Zero depuis 2014. Troisièmement, le chercheur est crédité publiquement, ce qui lui apporte une reconnaissance professionnelle directement monnayable dans sa carrière.

Ce mécanisme a fonctionné pendant des années. Il a permis de corriger des milliers de vulnérabilités critiques avant qu'elles ne soient découvertes et exploitées par des acteurs malveillants. Google Project Zero, la plus grande success story du modèle, a documenté des centaines de cas où la divulgation coordonnée a précédé l'exploitation.

Mais depuis 2022-2023, et de manière de plus en plus visible en 2025-2026, le contrat dérive côté éditeurs. Les tickets MSRC se ferment "by design" alors que la preuve d'exploitation existe. Les bug bounties sont requalifiés à la baisse au moment du paiement — le chercheur soumet une vulnérabilité RCE pre-auth, elle est requalifiée en "information disclosure" à l'examen pour réduire la prime. Les patches sont publiés sans crédit, ou avec un crédit générique du type "external researcher" qui efface toute trace de qui a trouvé quoi.

Et les délais s'allongent. Neuf mois, douze mois, dix-huit mois entre soumission et publication du correctif ne sont plus des exceptions — ils sont devenus la norme pour une certaine catégorie de vulnérabilités que les éditeurs jugent trop complexes à corriger sans régression majeure. Pendant ce temps, le chercheur est tenu au silence par l'accord de divulgation coordonnée, pendant que des attaquants qui ont redécouvert la même faille par d'autres voies l'exploitent activement.

L'économie de la divulgation : pourquoi les chercheurs publient

Le résultat est mécanique et prévisible : un chercheur qui passe trois mois à fouiller un binaire, à développer un PoC stable et à documenter la chaîne d'exploitation n'accepte plus qu'on lui réponde "merci, c'est noté" suivi d'un silence radio de neuf mois, d'une requalification à 5 000 dollars d'une vulnérabilité qui en vaut 250 000 sur le marché, et d'un crédit "external researcher" dans les notes de bas de page du bulletin.

Il a alors plusieurs options. La première est de vendre la vulnérabilité à un courtier d'exploits. Le marché gris (et parfois noir) des zero-days est parfaitement organisé en 2026. Zerodium publie sa grille tarifaire : un zero-day RCE pre-auth sur Windows vaut jusqu'à 2 500 000 dollars. Un exploit Defender SYSTEM se monnaye sans difficulté à six chiffres. Ces prix reflètent la valeur que les acheteurs — services de renseignement, forces de l'ordre, mais aussi acteurs moins recommandables — accordent à ces vulnérabilités.

La deuxième option est la divulgation publique directe, sans coordination préalable. C'est ce qu'a fait le chercheur qui a publié les trois zero-days Defender en avril 2026. Cette option est moralement contestable — elle arme potentiellement des attaquants — mais elle est pragmatiquement compréhensible dans le contexte décrit. Et elle génère une pression publique immédiate sur l'éditeur, qui doit livrer un patch en urgence sous les projecteurs.

La troisième option — de plus en plus fréquente — est la divulgation avec délai d'avertissement raccourci. Plutôt que de respecter 90 jours, le chercheur notifie l'éditeur avec un délai de 7 à 14 jours, puis publie quel que soit l'état du patch. C'est une forme de pression organisée qui respecte formellement le principe de la notification préalable tout en supprimant la marge de manœuvre que les éditeurs utilisaient pour différer indéfiniment.

Les éditeurs qui ont créé l'incitation à publier

Microsoft, pour ne citer que lui, concentre le plus grand volume de critiques de la part de la communauté de recherche en sécurité. Le programme MSRC est devenu un guichet où la décision de payer ou non est opaque, les critères de gravité sont régulièrement revus à la baisse au moment du triage, et le délai entre soumission et accusé de réception formel s'est allongé au point de devenir une source de frustration documentée par plusieurs chercheurs de premier plan sur des conférences comme DEF CON et Black Hat.

En 2024, au moins trois chercheurs ayant soumis des vulnérabilités critiques à Microsoft ont témoigné publiquement — avec preuves à l'appui — que leurs soumissions avaient été fermées comme "not a security issue" ou "by design", avant d'être réouvertes quelques mois plus tard après exploitation in-the-wild. Ce pattern — rejeter la soumission du chercheur, attendre l'exploitation, puis corriger discrètement — est perçu par la communauté comme une forme de déni organisé qui permet à l'éditeur d'économiser sur les primes tout en évitant la publicité d'une reconnaissance publique des vulnérabilités.

Google et Apple ne sont pas exempts de critiques, mais leur gestion des bug bounties et leurs délais de réponse sont globalement considérés comme meilleurs. La différence se mesure dans les chiffres : Google a versé plus de 12 millions de dollars en primes de bug bounty en 2023. Microsoft, avec une surface logicielle bien plus large, est très en dessous proportionnellement.

Les conséquences opérationnelles pour les équipes défensives

Ce déplacement du modèle de divulgation a deux conséquences directes pour les équipes qui défendent des systèmes en production, et elles modifient substantiellement ce que signifie "avoir une bonne posture de sécurité".

Conséquence 1 : la fenêtre entre publication et exploitation de masse se rétrécit à l'état de peau de chagrin. Quand un PoC est publié directement sans coordination préalable, il n'y a pas de patch disponible. La fenêtre d'exposition commence au moment de la publication et se termine... au moment où un patch est livré, qui peut être plusieurs semaines plus tard. Pendant ce temps, votre posture défensive repose entièrement sur votre capacité de détection comportementale — pas sur l'existence d'un patch.

Conséquence 2 : les patches ne couvrent plus l'ensemble du risque connu. Quand un chercheur publie un zero-day sans correctif disponible (ce que certains appellent une "zero-day disclosure sauvage"), le Patch Tuesday habituel devient mécaniquement insuffisant. Votre workflow de patch management, conçu pour appliquer des correctifs disponibles, ne peut rien contre une vulnérabilité connue publiquement mais non corrigée. Ce cas de figure était rarissime il y a cinq ans. Il devient régulier.

La conséquence opérationnelle est claire : la posture de détection doit primer sur la posture de remédiation dans les scénarios post-divulgation sauvage. Surveiller les comportements anormaux — un MsMpEng.exe qui spawne un cmd.exe, un service qui écrit hors de son arborescence habituelle, un processus de sécurité qui établit des connexions sortantes inhabituelles — devient plus rentable que la course aux patches sur des vulnérabilités dont le correctif n'existe pas encore.

C'est un changement culturel important pour beaucoup d'équipes qui ont structuré leur SOC autour des CVE et des patches. La détection comportementale exige un investissement initial plus important — baseline, tuning, gestion des faux positifs — mais c'est la seule défense effective contre les vulnérabilités publiées sans correctif.

Ce que les RSSI doivent faire maintenant

Face à ce nouveau paradigme, voici les adaptations concrètes à engager.

Action 1 — Étendre la veille au-delà des CVE officielles. Les vulnérabilités qui font l'objet d'une divulgation sauvage ou d'une publication avec délai raccourci n'entrent pas toujours immédiatement dans les bases CVE. Il faut surveiller les comptes Twitter/X et Mastodon de chercheurs reconnus, les repositories GitHub qui publient des PoC, les forums de sécurité spécialisés. FullDisclosure et les listes de sécurité de Google Project Zero sont des sources à intégrer dans votre veille.

Action 2 — Préparer des règles de détection comportementale pour les outils de sécurité eux-mêmes. Si les zero-days récents ciblent MsMpEng.exe, il faut des règles qui détectent les comportements anormaux de ce processus spécifiquement. Le SIEM et l'EDR doivent avoir des règles qui alertent quand un processus de sécurité fait des choses qu'il ne fait normalement pas : connexions réseau sortantes, création de processus enfants, accès à des chemins inhabituels.

Action 3 — Implémenter une politique de moindre privilège sur les agents de sécurité. Un agent EDR ou antivirus qui tourne avec des privilèges SYSTEM est une cible attrayante. Certains éditeurs permettent de limiter les privilèges de leurs agents dans des environnements de production — explorez cette option pour réduire l'impact potentiel d'une compromission de l'agent lui-même.

Action 4 — Tester régulièrement la détection comportementale via des red team exercises. La question n'est plus "est-ce que notre EDR détecte les malwares connus ?" mais "est-ce que notre stack de détection identifie des comportements anormaux sur nos outils de sécurité eux-mêmes ?". Cette question nécessite des exercices spécifiques qui sont encore rares dans la plupart des organisations.

Conclusion

Les trois zero-days Defender d'avril 2026 ne sont pas un accident. Ils sont l'aboutissement logique d'une décennie de dégradation des relations chercheurs/éditeurs, accélérée par des pratiques de bug bounty de plus en plus perçues comme prédatrices par la communauté qui génère la valeur.

Les RSSI doivent intégrer cette nouvelle donne dans leur modélisation de risque : compter sur le calendrier de patch d'un éditeur ne suffit plus. Il faut compter sur sa propre capacité de détection comportementale, son hygiène d'accès, et la résilience de son architecture face à des vulnérabilités connues mais non corrigées. La fenêtre entre "vulnérabilité connue publiquement" et "patch disponible" peut désormais durer des semaines. C'est pendant cette fenêtre que l'attaquant est le plus actif. Et c'est précisément là que la détection comportementale fait la différence entre un incident détecté et un incident découvert a posteriori dans un rapport d'audit.