MDASH : la découverte de vulnérabilités par agents IA passe en défense de production
Le harnais MDASH de Microsoft orchestre plus de 100 agents IA spécialisés pour trouver, débattre et prouver des bugs noyau. Il a révélé 16 CVE Windows et obtenu 88,45 % sur CyberGym — le signal défensif, et le signal dual-use.
De quoi s’agit-il ?
MDASH — le « multi-model agentic scanning harness » de Microsoft Security — est un système d’IA qui audite du code source à la recherche de vulnérabilités exploitables. L’équipe Autonomous Code Security de Microsoft l’a dévoilé le 12 mai 2026, avec un résultat concret : 16 vulnérabilités dans la pile réseau et d’authentification de Windows, dont quatre critiques, toutes livrées dans le Patch Tuesday du jour. À l’occasion de Microsoft Build, le 2 juin 2026, l’entreprise a élargi la préversion privée et intégré les résultats de MDASH au portail Defender.
Ce qui rend MDASH intéressant, ce n’est pas un bug isolé. C’est l’affirmation, chiffres à l’appui, que la découverte de vulnérabilités pilotée par l’IA est passée de la démonstration de recherche à l’ingénierie défensive de production — et la leçon d’architecture qu’en tire Microsoft : l’avantage durable réside dans le système autour du modèle, pas dans un modèle en particulier.
Comment ça marche
MDASH est un pipeline par étapes, pas un simple prompt. Microsoft le décrit exécutant plus de 100 agents spécialisés sur un ensemble de modèles de pointe et de modèles distillés, chaque étape ayant son rôle, ses outils et ses critères d’arrêt propres.
Une étape Prepare ingère la cible, construit des index adaptés au langage et reconstitue la surface d’attaque en analysant les commits passés. Une étape Scan fait passer des agents auditeurs sur les chemins de code candidats, en produisant des résultats assortis d’hypothèses et de preuves. Une étape Validate introduit des agents contradicteurs qui plaident pour et contre l’accessibilité et l’exploitabilité de chaque résultat — le désaccord entre modèles est traité comme un signal plutôt que comme du bruit. Une étape Dedupe fusionne les résultats sémantiquement équivalents, et une étape Prove construit et exécute des entrées déclenchantes lorsque la classe de bug le permet, de sorte qu’un résultat candidat devient un résultat démontré et non une simple ligne de backlog.
Deux propriétés font l’essentiel du travail. D’abord, un ensemble de modèles divers : un raisonneur puissant pour l’audit, des modèles distillés moins coûteux pour les passes de débat à fort volume, et un second modèle de pointe indépendant comme contrepoint. Ensuite, l’extensibilité par plugins de domaine — par exemple un plugin de preuve spécifique à un composant, qui encode des invariants de système de fichiers que les modèles de base ne peuvent inférer seuls. Parce que le ciblage, la validation, la déduplication et la preuve sont indépendants du modèle par construction, remplacer un modèle par un plus récent relève de la configuration, pas de la réécriture.
Pourquoi c’est important
Les preuves publiées par Microsoft sont inhabituellement vérifiables pour ce genre d’annonce. Sur un pilote de périphérique privé truffé de 21 bugs volontairement injectés — du code jamais apparu dans les données d’entraînement d’aucun modèle — MDASH a signalé les 21, sans faux positif sur cette exécution. Sur des benchmarks rétrospectifs, il a retrouvé 96 % de cinq ans de cas confirmés par le Security Response Center dans le composant de journalisation CLFS, et 100 % des sept cas de la pile TCP/IP. Sur le benchmark public CyberGym, qui compte 1 507 tâches de reproduction réelles, il a atteint 88,45 %, meilleur score publié au lancement et environ cinq points devant l’entrée suivante ; à Build, Microsoft indiquait que ce chiffre avait dépassé 96 %.
L’avantage défensif est évident : cinq ans des bugs qui comptaient vraiment, retrouvés par un système capable aussi de les prouver. La tension dual-use est tout aussi réelle. Les deux failles détaillées par Microsoft — un use-after-free distant non authentifié dans le chemin de réception IPv4 de Windows, et un double-free pré-authentification dans le service de gestion de clés IKEv2, accessible par UDP en tant que LocalSystem — appartiennent précisément à la classe de bugs profonds, inter-fichiers et sensibles à la concurrence que les scanners mono-modèle manquent et que les chercheurs offensifs aguerris convoitent. Un harnais qui les trouve à grande échelle est un atout défensif quand ce sont les défenseurs qui l’exécutent en premier, et un modèle de menace quand la même capacité se diffuse. Microsoft a délibérément retenu les détails d’exploitation des deux failles, conformément à la divulgation responsable ; les deux étaient corrigées avant publication.
Défenses
Pour les défenseurs, les enseignements pratiques sont concrets. Évaluez les outils de recherche de vulnérabilités par ce qu’ils font avec un modèle — validation, déduplication, construction de preuve — et non par le modèle qu’ils utilisent ; un scanner qui s’arrête aux résultats candidats ne fait que déplacer la charge de triage. Étayez toute revendication de capacité sur des données que le modèle n’a jamais vues : des cibles privées ensemencées et le rappel rétrospectif sur votre propre base de cas historiques sont bien plus instructifs que les seuls classements publics. Faites de la preuve d’accessibilité le seuil d’acceptation, car les résultats non prouvés gonflent le backlog sans réduire le risque.
Partez du principe que la parité offensive arrive, et réduisez la fenêtre qu’elle exploite : traitez en priorité les classes de bugs que ces systèmes trouvent le mieux — défauts de sûreté mémoire et de concurrence sur des chemins accessibles depuis le réseau et non authentifiés — avec des langages à mémoire sûre, du fuzzing et une logique de réassemblage durcie. Enfin, retenez le risque systémique signalé par des observateurs externes : une couche d’orchestration coordonnant plus de 100 agents à travers l’identité, le cloud et le code a un large rayon d’impact ; la gouvernance et les frontières de permission autour d’un tel harnais doivent être conçues avant le déploiement, et non ajoutées après un incident.
Statut
Les vulnérabilités ci-dessous font partie des résultats critiques attribués à MDASH par Microsoft dans sa divulgation du 12 mai 2026. Elles ne figurent ici qu’à titre de références ; toutes étaient corrigées avant publication.
| Composant | Nature | Référence | Statut |
|---|---|---|---|
| Windows TCP/IP (réception IPv4) | Use-after-free distant non auth. → RCE | CVE-2026-33827 | Corrigé |
| Service de clés IKEv2 Windows | Double-free pré-auth → RCE LocalSystem | CVE-2026-33824 | Corrigé |
| Windows Netlogon (CLDAP) | Débordement de pile non auth. → RCE | CVE-2026-41089 | Corrigé |
| Client DNS Windows | Réponse UDP forgée → dépassement de tas → RCE | CVE-2026-41096 | Corrigé |
MDASH reste en préversion privée limitée (élargie à Build 2026). Source principale : Microsoft Security Blog, publié le 12 mai 2026, mis à jour le 3 juin 2026.
Sources
- → https://www.microsoft.com/en-us/security/blog/2026/05/12/defense-at-ai-speed-microsofts-new-multi-model-agentic-security-system-tops-leading-industry-benchmark/
- → https://www.microsoft.com/en-us/security/blog/2026/06/02/microsoft-build-2026-securing-code-agents-and-models-across-the-development-lifecycle/
- → https://www.infoq.com/news/2026/05/microsoft-mdash/
- → https://thehackernews.com/2026/05/microsofts-mdash-ai-system-finds-16.html