Claude Mythos détecte des failles plus vite qu'on ne les corrige

Le 14 octobre 2026, le PDG de Bank of America, Brian Moynihan, a donné le premier chiffrage précis de l'effort. Pour corriger les failles logicielles mises au jour par Claude Mythos, l'IA d'Anthropic, et par d'autres modèles, la banque a recruté environ 1 000 prestataires. Ils s'ajoutent aux quelque 3 000 personnes qui travaillaient déjà sur le sujet.

Depuis avril, les IA trouvent des failles par dizaines de milliers, dans le code des entreprises comme dans les logiciels libres dont tout le monde dépend. Les équipes, elles, n'arrivent plus à suivre : il faut corriger chaque faille, puis installer le correctif avant qu'un attaquant ne s'en serve. Et ce délai se compte maintenant en heures.

Pour une entreprise française, cela change deux choses. La mise à jour de sécurité devient une urgence, qu'on traite dans la journée au lieu de l'attendre au prochain cycle mensuel. Et la question de l'auto-hébergement se pose autrement :

Héberger un logiciel libre chez soi reste possible, à condition de savoir le corriger en un jour, pas en un mois.

Claude Mythos, c'est quoi ?

Claude Mythos est l'IA de cybersécurité d'Anthropic : un modèle capable de trouver et d'exploiter seul des failles de sécurité inconnues. Anthropic l'a présenté le 7 avril 2026 sous le nom de Claude Mythos Preview. Selon l'entreprise, il trouve des failles zero day, c'est-à-dire inconnues de l'éditeur, « in every major operating system and every major web browser », dans tous les grands systèmes d'exploitation et navigateurs. Dans un test sur le moteur JavaScript de Firefox, sans le bac à sable du navigateur, Mythos a produit 181 exploits fonctionnels. Le modèle précédent, Opus 4.6, en avait produit deux sur plusieurs centaines d'essais.

Anthropic a jugé ce modèle trop dangereux pour une diffusion large. Il l'a réservé à Project Glasswing, un programme de défense lancé avec onze partenaires : AWS, Apple, Broadcom, Cisco, CrowdStrike, Google, JPMorganChase, la Linux Foundation, Microsoft, NVIDIA et Palo Alto Networks. Plus de quarante organisations non nommées s'y sont ajoutées, puis environ 150 en juin. Anthropic a mis jusqu'à 100 millions de dollars de crédits sur la table, et 4 millions de dons à des fondations open source.

Depuis, deux versions ont suivi : Mythos 5 en juin, Mythos 5.1 en septembre. En juin, le gouvernement américain a brièvement suspendu leur diffusion avant de la rouvrir. En septembre, Anthropic écrivait encore que Mythos 5.1 n'était disponible que pour « a set of US organizations », un ensemble d'organisations américaines. Depuis le 6 octobre, son Cyber Verification Program l'ouvre à des organisations et chercheurs vérifiés, sans critère géographique affiché, en lien avec le gouvernement américain. Nous y revenons plus bas : l'accès reste un vrai sujet pour l'Europe.

Mythos n'est pas seul. OpenAI propose GPT-5.5-Cyber et Codex Security à des partenaires vérifiés, Google a Big Sleep et CodeMender, et des sociétés comme AISLE trouvent aussi des failles à grande échelle. Mythos est le plus médiatisé, et c'est autour de lui que les chiffres ont été publiés.

Ce que la vague de failles a coûté aux premiers concernés

Mozilla : plus de failles en un mois qu'en un an

Mozilla, qui développe Firefox, a travaillé avec Anthropic dès février. Le 21 avril, Firefox 150 corrigeait 271 failles trouvées par une version préliminaire de Mythos. Sur le mois d'avril, Mozilla a corrigé 423 bugs de sécurité, toutes origines confondues. En 2025, elle en corrigeait 20 à 30 par mois, soit 258 sur l'année d'après ses chiffres mensuels. Plus de cent personnes ont contribué aux correctifs.

Sylvestre Ledru, directeur de l'ingénierie de Mozilla, a raconté l'intérieur de cette période dans l'émission Underscore_. D'habitude, Firefox recevait « une vingtaine de nouvelles vulnérabilités par mois ». En mars-avril, « en un mois on corrige plus de failles de sécu qu'en un an ». Avant 2026, il aurait estimé les failles latentes de Firefox à « 50, 60 peut-être ». Il parle d'un « ordre x10 ».

Deux détails de son récit comptent pour une entreprise. D'abord, Mozilla a tenu parce que les ingénieurs du fuzzing (le test automatique par données aléatoires) avaient déjà l'infrastructure pour absorber le flux : « heureusement, sinon je pense qu'on serait partis en burn-out ». Ensuite, il ne voit pas la vague retomber tout de suite :

Il prévoit « entre un an et deux ans » de « catastrophe dans le logiciel », le temps que tout le monde rattrape son retard.

Les responsables de grandes entreprises qu'il rencontre lui disent que pousser une mise à jour en quelques heures est « impensable » chez eux.

Bank of America, JPMorgan : des centaines de personnes à plein temps

Les banques américaines ont été parmi les premières à tester Mythos, à l'incitation des autorités, après une convocation de leurs PDG par le Trésor et la Réserve fédérale début avril. Bank of America a fini par chiffrer l'effort : environ 1 000 prestataires, et un coût de « a couple hundred million dollars plus » pour le trimestre. Ce montant inclut aussi des travaux de conformité anti-blanchiment, que la banque n'a pas séparés.

Chez JPMorgan, partenaire fondateur de Glasswing, Jamie Dimon parlait dès mai de « hundreds of people doing it full time », des centaines de personnes à plein temps. Selon la banque, corriger ses seules applications prendra « a year or so », un an environ. Le 6 octobre, Dimon a estimé que le risque cyber avait été multiplié par dix depuis Mythos, sans détailler son calcul.

Les logiciels libres : des bénévoles en première ligne

Le choc est plus rude pour les projets open source, souvent tenus par une poignée de mainteneurs. Selon Willy Tarreau, l'équipe sécurité du noyau Linux est passée de deux ou trois rapports par semaine il y a deux ans à cinq à dix par jour en 2026. Le 17 mai, Linus Torvalds a jugé la liste de sécurité du noyau « almost entirely unmanageable », presque totalement ingérable.

Ailleurs, même tableau. La boîte de réception sécurité d'OpenSSL est passée d'environ 9 à environ 70 rapports par mois. Daniel Stenberg, qui maintient curl, reçoit quatre à cinq fois plus de rapports qu'en 2024 et travaille 50 heures par semaine. Jean-Baptiste Kempf a publié en septembre une version de VLC qui corrige plus de 130 problèmes de sécurité, la plus grosse de son histoire. À PyCon US, des mainteneurs open source ont raconté que la sécurité, autrefois 20 % de leur temps, en prend maintenant « almost all », presque tout.

Les éditeurs changent de rythme

Les grands éditeurs ont réorganisé leurs mises à jour. Chrome a corrigé 1 072 bugs de sécurité en deux versions, plus que sur les 23 précédentes réunies. Microsoft corrigeait 112 failles au Patch Tuesday de janvier, et environ 1 400 en octobre. Cisco et Adobe sont passés à deux publications de sécurité par mois. Palo Alto Networks a publié 26 CVE en mai, contre moins de cinq un mois normal.

Pour une DSI, cela veut dire davantage de correctifs à installer, chez tous ses fournisseurs en même temps.

Le goulet d'étranglement est la correction

Le 6 octobre, Anthropic a affirmé que ses partenaires avaient trouvé « at least 129,000 » failles vérifiées entre avril et juillet. Le chiffre vient d'une enquête auprès de 33 partenaires, sans audit indépendant. Le tableau de bord qu'Anthropic tient pour les logiciels libres est plus parlant : au 2 octobre, 6 157 failles avaient été signalées à 591 projets, et 516 étaient corrigées. Environ une sur douze.

Anthropic le reconnaît lui-même : la découverte est limitée « by how quickly we can verify, disclose, and patch », par la vitesse à laquelle on peut vérifier, signaler et corriger. Corriger reste un travail humain. Chez Mozilla, un ingénieur écrit chaque correctif et un autre le relit : « We have not found it to be automatable », nous n'avons pas trouvé cela automatisable.

Nous lisons ces chiffres avec prudence : ils viennent pour l'essentiel d'Anthropic et de ses partenaires, et les mainteneurs qui les ont vérifiés de près les relativisent. Sur curl, un rapport Mythos annonçait cinq failles confirmées : une seule était réelle, de gravité basse. Stenberg a parlé d'un battage « primarily marketing ». Greg Kroah-Hartman, mainteneur du noyau stable, a ramené les « 79 failles Mythos » de Linux à dix vrais correctifs, environ une heure de travail. Chez Palo Alto, aucune des 75 failles trouvées n'était critique : « Volume does not equal severity », le volume n'est pas la gravité.

Mozilla, enfin, note que Mythos n'a trouvé aucun bug « that couldn't have been found by an elite human researcher », qu'un chercheur d'élite n'aurait pas pu trouver. Ce qui change, c'est le nombre et le prix : ces failles sont trouvées toutes à la fois, pour une fraction du coût d'une équipe humaine, et bientôt par n'importe qui.

Un correctif publié, un exploit dans l'heure

Tant qu'un correctif n'est pas installé, il sert de mode d'emploi aux attaquants : la différence entre l'ancienne et la nouvelle version montre exactement où se trouvait le problème. On parle alors de faille « n-day », connue et corrigée, mais pas encore partout.

Ce délai fond depuis des années. Selon Mandiant, il fallait en moyenne 63 jours pour qu'une faille soit exploitée en 2018-2019, et 5 jours en 2023. Pour 2025, Mandiant estime ce délai à -7 jours : l'exploitation précède souvent le correctif. Google observe 18 failles exploitées par mois de janvier à août 2026, contre 10,5 en 2025. Il attribue l'essentiel de la hausse à l'exploitation rapide de failles déjà corrigées, peut-être grâce à des IA qui comparent les versions.

Ce travail de comparaison, les IA le font très bien. En juin, Anthropic a donné à Mythos les correctifs publics de 18 failles de Firefox : il a produit une première preuve d'exploitation en 12 minutes environ, et un premier exploit fonctionnel en moins d'une heure. À partir des seuls fichiers binaires de Windows, sans code source, il a construit huit chaînes d'attaque complètes pour environ 2 000 dollars chacune. Anthropic résume : on ne parle plus de « n-day » mais de « N-hour ». Des chercheurs de l'université de Californie à Riverside reproduisent plus de la moitié de 100 failles du noyau Linux à partir du seul correctif, en 19 minutes et 4 dollars en moyenne.

La Banque centrale européenne a retenu la même échelle : une faille corrigée peut être identifiée par des criminels en « perhaps 30 minutes », peut-être 30 minutes. Conséquence directe : il faut installer les correctifs de sécurité dès leur sortie. Une entreprise qui les applique au rythme d'un comité mensuel laisse plusieurs semaines à des attaquants qui n'ont besoin que de quelques heures.

L'open source auto-hébergé est-il encore tenable ?

La question se pose naturellement. Quand un logiciel libre corrige une faille, le correctif est visible dans son dépôt public, parfois des semaines avant que les distributions ne le livrent. Un attaquant qui surveille le dépôt sait où frapper, et un agent d'IA peut le faire pour lui. Faut-il en conclure que l'open source hébergé chez soi est devenu trop risqué ?

Le correctif est public avant d'être installé

L'exemple de Copy Fail, une faille du noyau Linux, est parlant. Le correctif a été intégré au dépôt public le 31 mars 2026, avec un message qui ne parlait pas de sécurité. La faille n'a été divulguée que le 29 avril. Deux jours plus tard, l'agence américaine CISA l'inscrivait dans son catalogue des failles activement exploitées.

Les règles de discrétion qui laissaient aux distributions le temps de préparer leurs paquets s'effacent aussi. L'équipe du noyau demande de traiter tout bug trouvé par IA comme public, puisque d'autres l'auront probablement trouvé le même jour. Et la liste qui coordonne les distributions considère en général qu'un correctif déjà présent dans un dépôt public ne justifie pas d'embargo. Le travail des distributions se fait donc à découvert.

L'intuition est juste sur un point : en auto-hébergé, c'est vous qui testez, planifiez et installez. La CISA le rappelle : les mainteneurs open source « are not the equivalent of a software producer », ils ne sont pas tenus de vous livrer quoi que ce soit.

Le code fermé n'est pas mieux protégé

Mais le raisonnement s'arrête là. Ne pas publier son code ne protège plus. Les huit chaînes d'attaque Windows d'Anthropic ont été construites sans le code source. Akamai a fait analyser par une IA les correctifs de trois Patch Tuesday de Microsoft, pour 0,14 dollar en moyenne par rapport.

Parmi les logiciels on-premise les plus attaqués figurent d'ailleurs de nombreux produits propriétaires. Fin août, près de 22 000 adresses IP de serveurs Exchange exposés sur Internet n'avaient pas appliqué un correctif critique ; en Allemagne, le BSI estime qu'environ 85 % des serveurs Exchange on-premise restent vulnérables. Citrix, Fortinet et Ivanti remplissent le catalogue de la CISA, même si des logiciels libres exposés sur le Web, comme WordPress ou Drupal, y figurent aussi en bonne place. À l'inverse, Google a compté environ 5 000 CVE du noyau Linux entre janvier et août 2026, sans aucune faille zero day exploitée.

Ce qui ne tient plus : le service exposé, corrigé une fois par mois

Ce qui est remis en cause, c'est une façon d'exploiter l'open source auto-hébergé : le service exposé sur Internet et corrigé une fois par mois. LiteLLM, une passerelle open source que beaucoup d'entreprises hébergent elles-mêmes pour accéder aux LLM, en est l'illustration. Les premières attaques ciblées sur une faille critique sont arrivées 36 heures après l'indexation de son avis de sécurité. Pendant ce temps, seules 26 % des failles exploitées connues ont été entièrement corrigées en entreprise en 2025, avec un délai médian de 43 jours selon le rapport DBIR 2026 de Verizon, cité par Tenable. Le CERT-EU estime les cycles de correction des entreprises à 30 à 60 jours, et fixe l'objectif à quelques jours pour les failles critiques exposées.

La question à se poser est donc moins « libre ou propriétaire ? » que celle-ci : qui, chez vous, sait appliquer un correctif critique sur un service exposé dans les 24 heures ? LiteLLM montre qu'une fois l'avis largement diffusé, 36 heures suffisent aux attaquants, alors que le correctif était disponible depuis une semaine. Si votre équipe en est capable, l'auto-hébergement reste un choix défendable. Sinon, il faut soit sortir le service d'Internet, soit confier son exploitation à quelqu'un qui s'y engage par contrat. Le SaaS ne fait pas disparaître le risque : selon le même rapport Verizon, 48 % des violations impliquent un tiers. Il le déplace vers un fournisseur dont il faut vérifier les engagements, et la nationalité.

C'est cohérent avec ce que nous écrivions sur les LLM en local : la souveraineté ne se confond pas avec l'auto-hébergement, et le coût réel d'un déploiement on-premise est dans son exploitation. Mettre à jour en quelques heures en fait partie. Une nuance, enfin, que nous avions soulevée à propos de LiteLLM et des passerelles, victimes en mars de versions piégées publiées sur PyPI : mettre à jour vite, c'est installer rapidement une version vérifiée et issue d'une source officielle, en laissant quelques heures à une éventuelle compromission pour être repérée.

L'Europe sans accès à l'outil, mais pas au problème

Les entreprises européennes subissent la même vague de correctifs que les américaines, sans disposer de l'outil qui l'a déclenchée. Aucun partenaire européen n'est nommé dans Glasswing. Dans l'Union européenne, seule l'ENISA, l'agence européenne de cybersécurité, teste Mythos 5 depuis septembre. Aucune banque de la zone euro ni l'ANSSI n'ont d'accès confirmé. Christine Lagarde a parlé d'un accès qui « divides the level playing field between the U.S. and the rest of the world », qui fausse la concurrence entre les États-Unis et le reste du monde.

La BCE n'en tire pas une excuse. « Lack of access is not an excuse for inaction », a prévenu Frank Elderson, vice-président de sa supervision. Une lettre du 7 juillet demande aux grandes banques européennes un plan d'action contre les menaces cyber liées à l'IA avant le 31 octobre 2026. Côté français, BNP Paribas a prolongé son partenariat avec Mistral AI, qui a développé son propre modèle cyber selon Bloomberg ; son DSI, Marc Camus, résume l'enjeu : « The game changer is the speed at which we have to address vulnerabilities and the scale ».

L'ANSSI, elle, parle d'un « problème de cadence » et d'un risque de saturation des équipes. Dès le début avril, avant même l'annonce de Mythos, son directeur général Vincent Strubel jugeait au Forum InCyber que « cette bataille sur les vulnérabilités est en train d'être perdue ». En octobre, aux Assises de Monaco, il a appelé à « sortir d'une dimension un peu marketing » des grands vendeurs d'IA. Pendant ce temps, la directive NIS2, qui impose des obligations de gestion des vulnérabilités à des milliers d'entreprises, n'est toujours pas transposée en France : le projet de loi Résilience a été retiré de l'ordre du jour de l'Assemblée le 6 octobre. Nous avions déjà décrit cette dépendance numérique européenne ; Mythos en donne une illustration très concrète.

Ce qu'une DSI peut faire dès maintenant

Pas besoin d'avoir accès à Mythos pour se préparer. Les recommandations du NCSC britannique, du CERT-EU et de l'ANSSI se recoupent, et la plupart relèvent du patch management, la gestion des correctifs, plus que de l'IA.

1. Inventorier ce qui est exposé sur Internet. C'est là que la fenêtre d'exploitation est la plus courte. Ce qui n'a pas besoin d'être accessible publiquement passe derrière un VPN ou un accès zero trust : la CISA reconnaît ce retrait comme une mesure qui laisse plus de temps pour corriger.
2. Fixer un délai cible en heures pour les failles critiques exposées. Les agences fédérales américaines ont trois jours pour les cas les plus graves depuis juin 2026. Un comité de changement mensuel ne suffit plus.
3. Automatiser ce qui peut l'être : mises à jour automatiques des systèmes, correctifs du noyau sans redémarrage (Livepatch, kpatch) quand ils existent, protections temporaires par pare-feu applicatif quand le correctif n'est pas disponible.
4. Exiger des délais de correction de vos fournisseurs, éditeurs comme SaaS, et les inscrire au contrat, comme on le fait pour la disponibilité dans un SLA.
5. Vérifier avant d'installer : aller vite vers une version signée et issue d'une source officielle, pas vers la dernière version parue sur un dépôt de paquets.
6. Budgéter la correction, et pas seulement la détection. Bank of America et JPMorgan montrent l'ordre de grandeur : des centaines, voire des milliers de personnes pendant des mois.
7. Utiliser l'IA en défense, de préférence européenne ou open source pour ne pas créer une nouvelle dépendance, comme le recommande le Campus Cyber. Pour comparer les fournisseurs sous cet angle, voir notre page sur l'IA souveraine.

Questions fréquentes sur Claude Mythos

Qu'est-ce que Claude Mythos ?

Claude Mythos est un modèle d'IA d'Anthropic, présenté le 7 avril 2026 sous le nom de Claude Mythos Preview, capable de trouver et d'exploiter seul des failles de sécurité inconnues dans les grands systèmes d'exploitation et navigateurs. Anthropic ne l'a pas ouvert au public : il est réservé à des organisations et chercheurs vérifiés dans le cadre de Project Glasswing, puis du Cyber Verification Program. Ses versions suivantes, Mythos 5 et Mythos 5.1, sont sorties en juin et en septembre 2026.

Qu'est-ce que Project Glasswing ?

Project Glasswing est le programme lancé par Anthropic le 7 avril 2026 pour donner accès à Claude Mythos à des organisations qui maintiennent des logiciels critiques, afin qu'elles corrigent leurs failles avant que des capacités équivalentes ne se diffusent. Il réunit onze partenaires fondateurs, dont AWS, Apple, Google, Microsoft et la Linux Foundation, plus de quarante autres organisations au lancement et environ 150 de plus en juin 2026. Anthropic y a consacré jusqu'à 100 millions de dollars de crédits et 4 millions de dons à l'open source. Depuis le 6 octobre 2026, Glasswing est intégré au Cyber Verification Program.

Peut-on utiliser Claude Mythos en Europe ?

Pas à notre connaissance pour une entreprise européenne. En septembre 2026, Anthropic réservait Mythos 5.1 à un ensemble d'organisations américaines ; depuis le 6 octobre, son Cyber Verification Program l'ouvre à des organisations et chercheurs vérifiés, sans critère géographique affiché, en lien avec le gouvernement américain. Dans l'Union européenne, seule l'ENISA, l'agence européenne de cybersécurité, teste Mythos 5 depuis septembre 2026. Aucune banque de la zone euro ni agence nationale comme l'ANSSI n'a d'accès confirmé au 16 octobre 2026.

Combien de failles Claude Mythos a-t-il trouvées ?

Anthropic affirme que ses partenaires ont trouvé au moins 129 000 failles vérifiées entre avril et juillet 2026, chiffre déclaré par 33 partenaires et non audité. Sur les logiciels open source, Anthropic avait signalé 6 157 failles à 591 projets au 2 octobre 2026, dont 516 corrigées. Chez Mozilla, une première passe de Mythos a conduit à 271 failles corrigées dans Firefox 150.

Faut-il abandonner l'open source auto-hébergé à cause de l'IA ?

Non. Aucune autorité de cybersécurité ne le recommande, et une bonne part des logiciels on-premise les plus exploités sont propriétaires (Exchange, Citrix, Fortinet). Ce qui devient intenable, c'est un service exposé sur Internet et corrigé une fois par mois, qu'il soit libre ou non. Un logiciel open source auto-hébergé reste défendable si l'équipe sait appliquer un correctif critique dans les 24 heures, ou si le service n'est pas exposé publiquement.

En combien de temps faut-il appliquer un correctif de sécurité ?

Pour une faille critique sur un service exposé à Internet, en heures ou en quelques jours. Mandiant estime qu'en 2025, l'exploitation précédait en moyenne la publication du correctif de 7 jours, et des IA tirent aujourd'hui d'un correctif une preuve d'exploitation en quelques minutes, et un exploit en moins d'une heure. La CISA impose trois jours aux agences fédérales américaines pour les cas les plus graves ; le CERT-EU recommande de corriger « within days, not weeks ».

Qu'est-ce qu'une faille zero day ?

Une faille zero day est une vulnérabilité inconnue de l'éditeur du logiciel, donc sans correctif disponible le jour où elle est découverte ou exploitée. Une faille « n-day », à l'inverse, est déjà connue et corrigée, mais reste exploitable sur toutes les machines où le correctif n'a pas été installé. Les IA comme Claude Mythos trouvent des zero days à grande échelle, et accélèrent aussi l'exploitation des n-days.

---

Mythos n'a pas inventé de nouvelles attaques. Il a rendu bon marché ce qui coûtait cher : trouver une faille, et comprendre un correctif. Le temps qui sépare une faille corrigée d'une faille exploitée était une marge de sécurité. Elle a disparu. Pour une entreprise, la question à se poser cette semaine est simple : combien de temps nous faut-il pour installer un correctif critique sur nos services exposés ? Si la réponse se compte en semaines, c'est par là qu'il faut commencer, quel que soit le logiciel.