L'IA trouve les failles plus vite que vous ne les corrigez

Deux actualités ont émergé cette semaine qui, ensemble, devraient alerter toutes les équipes de développement et de sécurité.

Commençons par la plus importante : Anthropic a annoncé Claude Mythos Preview, un nouveau modèle d'IA jugé trop dangereux pour être publié. La raison ? Il est redoutablement efficace pour détecter les failles de sécurité. On ne parle pas d'exemples artificiels tirés de challenges CTF. Mythos a découvert un bug vieux de 27 ans dans OpenBSD, l'un des systèmes d'exploitation les plus sécurisés au monde. Il a trouvé une faille dans FFmpeg que les outils de test automatisés avaient sollicitée cinq millions de fois sans jamais la détecter. Il a enchaîné plusieurs vulnérabilités du noyau Linux pour passer d'un accès utilisateur ordinaire à un contrôle total de la machine. Des milliers de zero-days dans tous les grands systèmes d'exploitation et navigateurs, dont la plupart n'étaient pas corrigés avant qu'Anthropic ne les signale.

Anthropic ne rend pas le modèle public. À la place, ils ont lancé Project Glasswing, qui donne accès à une quarantaine d'organisations (dont certaines des plus grandes entreprises technologiques au monde) pour analyser et corriger leur propre code. Ils mettent également à disposition 100 millions de dollars de crédits d'utilisation et 4 millions de dollars destinés aux fondations de sécurité open source.

Deuxième actualité, plus modeste mais peut-être plus instructive : CVE-2026-39987, une faille d'exécution de code à distance sans authentification dans Marimo, un notebook Python open source populaire chez les data scientists. Score CVSS : 9,3. La vulnérabilité se trouvait dans un endpoint WebSocket (/terminal/ws) qui ne vérifiait tout simplement pas l'authentification, alors que tous les autres endpoints WebSocket du code le faisaient. Sysdig a déployé des honeypots et a observé une exploitation dans les 10 heures suivant la divulgation publique. Dix heures.

Ce que ces deux histoires ont en commun

Le fil conducteur entre Mythos et le CVE Marimo est le même : la fenêtre entre l'existence d'une vulnérabilité et son exploitation s'est effondrée.

Avec Mythos, nous faisons face à une IA capable de trouver des bugs que des chercheurs humains ont manqués pendant des décennies. Avec le cas Marimo, nous voyons des attaquants qui weaponisent une faille divulguée avant même que la plupart des équipes aient lu l'avis de sécurité. Les deux pointent dans la même direction : la rapidité de correction et la maîtrise de la surface d'attaque ne sont plus des disciplines optionnelles. Ce sont des questions de survie.

Et voilà ce qui m'inquiète. Le responsable du red teaming frontier chez Anthropic estime que les modèles open-weight atteindront le niveau de détection de bugs de Mythos d'ici six à dix-huit mois. Cela signifie que cette capacité ne restera pas indéfiniment confinée derrière une préversion de recherche fermée. Elle va se répandre.

Ce que cela signifie pour les équipes de développement

Si vous développez des applications web, des API ou quoi que ce soit avec une couche WebSocket, le bug Marimo devrait vous sembler dangereusement familier. Un seul endpoint qui a sauté l'authentification. Tous les autres faisaient les choses correctement. C'est le genre d'incohérence qui passe à travers la revue de code, franchit les tests QA, et reste en production pendant des mois.

Dans notre travail PHP et Docker avec des clients enterprise, nous observons ce schéma en permanence. Une équipe ajoute un nouvel endpoint, le copie d'un existant, supprime le middleware d'auth « temporairement » pendant le développement, et il part en production. Le reste de l'application est parfaitement verrouillé. Une seule route ne l'est pas. C'est tout ce qu'il faut.

Lorsque nous réalisons des tests de pénétration pour des studios de jeux vidéo et des plateformes de voyage, nous cherchons spécifiquement ces incohérences. L'endpoint de debug complètement ouvert derrière un load balancer. Le panneau d'administration qui vérifie l'authentification mais pas les autorisations. L'API de staging qui s'est retrouvée accidentellement pointée en DNS vers la production. Ce sont ces bugs qui génèrent des vulnérabilités CVSS 9+, et ce sont exactement les failles logiques que les modèles d'IA de la classe Mythos vont commencer à trouver à grande échelle.

Le volet mobile compte aussi

Si vous vous dites « c'est un problème côté serveur, mon appli mobile est tranquille », réfléchissez-y à deux fois. Dans nos projets iOS et Android natifs, nous avons vu des applications qui font confiance au serveur pour gérer toute la validation de sécurité. Si le backend est compromis via une faille comme CVE-2026-39987, tout ce que l'application mobile envoie et reçoit est exposé. Tokens d'API, données utilisateurs, identifiants de session.

Nous avons vu cela dans des applications de santé et d'IoT où le client mobile stocke des données sensibles en local et les synchronise avec un backend que l'équipe croyait sûr parce que « il est derrière un pare-feu ». La faille Marimo était exploitable via une simple connexion WebSocket non authentifiée. Les pare-feux n'aident pas si la porte est déjà ouverte depuis l'intérieur de la couche applicative.

Les nouvelles exigences de l'App Store d'Apple pour la conformité au SDK watchOS et iOS 26 ajoutent également une pression sur les délais. Les équipes qui s'empressent de respecter ces échéances d'avril tout en maintenant la sécurité de leurs backends se retrouvent exactement dans le type de situation sous pression où les vérifications d'authentification se font oublier.

Une action concrète à mener dès maintenant

Voici une étape concrète : auditez chaque endpoint WebSocket et temps réel de votre application pour vérifier la cohérence de l'authentification. Pas seulement « l'app exige-t-elle une connexion ? » mais « est-ce que chaque endpoint, y compris les endpoints de debug, terminal, monitoring et internes, applique réellement l'auth ? »

La vulnérabilité Marimo existait parce que leur endpoint WebSocket terminal utilisait websocket.accept() sans appeler validate_auth(). Leurs autres endpoints l'appelaient. Cet écart — un appel de fonction manquant dans un seul fichier — représentait un RCE pré-auth CVSS 9,3.

Si vous faites partie d'une équipe qui gère des applications web ou des API, prenez une heure cette semaine pour faire un grep dans votre codebase afin de trouver les handlers d'acceptation WebSocket. Vérifiez-les un par un. Si vous utilisez Starlette, FastAPI, Express avec ws, ou n'importe quel framework qui traite les connexions WebSocket comme un chemin séparé du middleware HTTP, vous avez probablement des endpoints qui contournent votre stack d'auth habituelle. Trouvez-les avant que quelqu'un d'autre ne le fasse.

La vue d'ensemble

Anthropic présente Project Glasswing comme une approche « défenseurs en premier ». L'idée est de donner aux gentils une longueur d'avance avant que les capacités de la classe Mythos ne se généralisent. C'est une position raisonnable, mais elle repose aussi sur une prémisse inconfortable : la seule façon de se protéger contre une IA qui trouve des bugs est de la construire en premier et d'espérer corriger plus vite que les attaquants n'exploitent.

Dans notre travail de sécurité consistant à configurer Cloudflare et Akamai pour la protection DDoS de grandes plateformes de voyage, nous vivons déjà dans un monde où les attaques automatisées se déplacent plus vite que les temps de réponse humains. La différence avec la découverte de vulnérabilités assistée par IA, c'est que les attaques ne seront pas seulement plus rapides. Elles seront plus intelligentes. Au lieu d'un scanning par force brute, vous ferez face à une exploitation ciblée de failles logiques qu'aucune règle WAF ne peut intercepter, car l'attaque ressemble à une requête légitime.

Cela change la façon dont vous architecturez vos défenses. Les règles statiques ne suffisent plus. Vous avez besoin d'une sécurité en couches : authentification à chaque endpoint, segmentation réseau appropriée pour qu'un serveur de notebook compromis ne puisse pas atteindre votre base de données de production, et une surveillance réelle — pas seulement de l'agrégation de logs, mais une véritable détection d'anomalies sur ce que font vos connexions WebSocket.

Nous avons évoqué ce changement avec nos clients auparavant. Cette semaine l'a rendu bien moins théorique.

La suite

L'industrie de la sécurité est sur le point de devenir beaucoup plus active. Les modèles d'IA capables de trouver des milliers de zero-days en une semaine vont contraindre les mainteneurs de logiciels à un sprint permanent. Les projets open source avec de petites équipes — comme Marimo — seront les plus touchés, car ils n'ont pas les ressources nécessaires pour corriger au rythme que la menace exige désormais.

Si votre équipe construit sur des outils open source de data science, des notebooks de développement, ou tout outillage interne conçu pour des réseaux de confiance mais qui se retrouve désormais à portée d'internet, voici votre signal d'alarme. Traitez chaque outil de votre stack comme faisant partie de votre surface d'attaque. Patchez agressivement. Et ne supposez pas que parce que quelque chose est « interne », c'est sûr.

Si tout cela ressemble à une conversation que votre équipe doit avoir, parlons-en.