Au cours des derniers mois, nous avons utilisé un modèle de recherche interne non publié pour trouver des vulnérabilités critiques dans certains des logiciels les plus utilisés au monde, tels que les navigateurs et les systèmes d'exploitation. Dans cet article, nous partageons les détails de cinq chaînes d'attaque, qui ont mené à l'exécution de code à distance et à d'autres impacts critiques avec une interaction utilisateur minimale, voire nulle. Ces chaînes d'attaque démontrent la capacité du modèle à créer des exploits sophistiqués en plusieurs étapes, à la fois dans des logiciels open source et propriétaires. Toute vulnérabilité dans ces produits pourrait affecter des milliards d'utilisateurs. Ils figurent également parmi les logiciels les plus critiques pour la sécurité au monde, ce qui en fait un baromètre pour tester la recherche de vulnérabilités et les capacités cyber des modèles.
Nous avons signalé chaque vulnérabilité au fournisseur concerné dans le cadre de notre divulgation coordonnée des vulnérabilités, qui donne aux développeurs 90 jours pour corriger le problème et 45 jours supplémentaires avant que nous discussions des détails au-delà de ce qui est déjà inclus dans un avis public.
1. Exécution de code à distance en un clic dans Chrome
Après une sollicitation initiale, Claude a écrit une chaîne d'exploit complète permettant à un attaquant d'exécuter du code arbitraire en tant qu'utilisateur, en dehors du bac à sable du navigateur. Notre preuve de concept lance l'application Calculatrice depuis un navigateur Chrome sous macOS avec sa configuration par défaut en quelques secondes après le chargement de la page, sans aucune interaction supplémentaire de l'utilisateur :
- Claude a découvert une vulnérabilité dans le moteur JavaScript de Chrome, V8, qui permettait à une page web malveillante de corrompre la mémoire de tas de V8.
- Claude a découvert une seconde vulnérabilité pour sortir du bac à sable de la région mémoire de V8 et contourner l'ASLR. Cette étape a localisé le code de Chrome en mémoire et utilisé une chaîne de return-oriented programming (ROP) pour prendre le contrôle total du processus de rendu.
- Le moteur de rendu compromis était confiné par le bac à sable de processus de Chrome. Claude a ensuite découvert une condition de course dans CacheStorage. Le moteur de rendu compromis a utilisé cette condition de course pour lire la mémoire en dehors du bac à sable et connaître la disposition mémoire du processus privilégié du navigateur.
- Enfin, Claude a découvert une use-after-free dans FedCM, la fonctionnalité de connexion fédérée de Chrome, qui permettait à l'exploit d'exécuter du code arbitraire en dehors du bac à sable.
Nous avons signalé nos conclusions à Google : 62 CVE ont été attribuées et corrigées à partir de Chrome 156, toutes classées critiques ou de gravité élevée. Parmi elles figurent 13 évasions de bac à sable et 21 vulnérabilités qui auraient pu être utilisées pour compromettre le moteur de rendu.
2. Une chaîne d'exploit en un clic dans Safari
Après une sollicitation initiale, Claude a écrit une chaîne d'exploit permettant au JavaScript de n'importe quel site web de contourner complètement la politique de même origine (SOP). L'exploit pouvait accéder à l'historique Safari d'un utilisateur, à ses cookies et à d'autres données sensibles, et pouvait envoyer des requêtes HTTP authentifiées vers d'autres domaines et lire les réponses. Par exemple, si l'utilisateur est connecté à son compte de messagerie, l'attaquant peut désormais lire ses e-mails ; s'il est connecté à son compte bancaire, l'attaquant peut consulter les soldes ou tenter des virements.
Pour ce faire, Claude a contourné plusieurs couches de protection intégrées à Safari :
- Claude a découvert une vulnérabilité de use-after-free (UAF) dans JavaScriptCore, le moteur JavaScript de Safari, qui est écrit en C++. Certaines opérations sur les TypedArray écrivaient via des pointeurs périmés vers de la mémoire libérée, écrasant les métadonnées des TypedArray.
- Le Gigacage de WebKit atténue ce type d'attaque en isolant les données des TypedArray dans une région mémoire distincte. Claude a découvert que certaines variables de cette région étaient utilisées pour indexer d'autres régions, ce qui lui a donné une primitive de lecture/écriture arbitraire en dehors du Gigacage.
- Tout le JavaScript des sites web s'exécute dans le bac à sable WebContent, qui empêche les bogues comme l'UAF d'atteindre les données sensibles du navigateur stockées sur disque. Claude a découvert une vulnérabilité dans le mécanisme IPC du bac à sable qui permettait à l'exploit de lire l'historique, les cookies et les bases de données de session de Safari stockés sur disque.
- Enfin, Claude a utilisé l'UAF pour écraser une variable en mémoire et désactiver le SOP, permettant à la page de l'attaquant de lire des données de n'importe quelle autre origine.
Cette chaîne est intéressante parce qu'il s'agit d'une attaque uniquement basée sur les données qui ne repose jamais sur l'exécution de code arbitraire. Elle utilise plutôt un accès complet en lecture/écriture à la mémoire du processus du navigateur pour modifier un indicateur de sécurité, une taille d'objet et une URL. Plusieurs de ces faiblesses ne sont pas des vulnérabilités en elles-mêmes, mais des comportements intentionnels qui deviennent exploitables lorsqu'ils sont combinés.
Apple a accusé réception de notre signalement le jour même où nous l'avons soumis et a rapidement mis en œuvre un correctif. Ce correctif est disponible pour les utilisateurs.
3. Contournement de l'écran de verrouillage d'Android
Après une invite initiale, Claude a rédigé un exploit permettant à un attaquant d'extraire des photos et d'autres informations personnelles d'un téléphone Android volé sans le déverrouiller. Ce travail a combiné trois méthodes : l'analyse du code source des parties open source d'Android, la rétro-ingénierie et la désobfuscation des binaires des services Google Play, et des tests en direct sur un Google Pixel 9 physique. Cela a mis au jour un large éventail de vulnérabilités dans les composants aussi bien open source que propriétaires. Claude a ensuite enchaîné trois d'entre elles dans l'exploit final.
Android possède plusieurs couches de protection contre cette attaque. Claude a trouvé un moyen de contourner chacune d'elles :
- Un téléphone Android verrouillé est conçu pour ne pas transférer de données via USB. Claude a découvert qu'un hôte USB avec un paramètre spécifique permettait de contourner cette protection.
- Le protocole de transfert d'appareil à appareil refuse les commandes de données provenant de pairs non autorisés. Claude a trouvé un moyen de passer outre la vérification d'autorisation et de démarrer le processus d'appairage.
- L'appairage est protégé par un accord de clé authentifié qui demande à l'utilisateur de vérifier un code à six chiffres. Claude a trouvé une faille qui permettait d'ignorer cette vérification et de se comporter comme si l'utilisateur avait appuyé sur « Autoriser ».
- Les transferts USB ne sont pas censés transporter le contenu des fichiers, comme l'impose une vérification codée en dur. Claude a trouvé un mécanisme de secours qui envoyait des octets bruts via USB et qui n'était pas couvert par cette vérification. L'exploit demandait le contenu des fichiers par son intermédiaire.
Ce problème a été corrigé par Google.
4. Déni de service à distance sous Windows
Après une invite initiale, Claude a rédigé un exploit qui aurait permis à un attaquant de faire planter à distance n'importe quelle machine Windows répondant à des requêtes HTTP/3 en utilisant l'implémentation native de Windows. La difficulté dans ce cas résidait dans l'identification de la vulnérabilité en premier lieu. À la suite de cette invite initiale, nous avons signalé cette vulnérabilité directement à Microsoft, qui l'a corrigée et lui a attribué la référence CVE-2026-33096.
La vulnérabilité identifiée par Claude était une lecture hors limites liée à la sécurité de la mémoire dans l'implémentation de QUIC par le noyau Windows. Un attaquant pouvait atteindre ce chemin de code vulnérable à distance via le réseau et envoyer quelques paquets de données à un serveur à l'écoute pour faire planter et redémarrer la machine. En envoyant ces requêtes de manière répétée, il est possible de faire planter le serveur en continu, ce qui entraîne une perte d'accès au serveur pour l'ensemble des utilisateurs. Nous estimons qu'il existe probablement plusieurs millions de serveurs de ce type à l'écoute sur Internet.
Claude a découvert cette vulnérabilité grâce à l'analyse binaire. Nous avons fourni au modèle une copie de l'exécutable Windows et demandé à Claude de rétro-ingénierer le fonctionnement du logiciel à l'aide des outils de rétro-ingénierie existants (tels que Ghidra), d'écrire un programme C entièrement annoté reproduisant les fonctionnalités pertinentes, de comparer le comportement du programme reproduit à celui du binaire pour garantir l'exactitude, puis d'étudier le code à la recherche de vulnérabilités. Lorsque nous avons demandé à Claude d'identifier les problèmes potentiellement plus à risque, il a fait remonter cette vulnérabilité exploitable à distance.
5. Exécution de code à distance sans clic sous Linux
Bien que cet article se concentre sur des produits tiers, notre travail sur l'open source s'est poursuivi. Avec Claude, nous avons découvert des vulnérabilités d'élévation de privilèges locaux sur OpenBSD, FreeBSD et Linux ; plusieurs évasions de bac à sable dans des infrastructures de sandboxing populaires ; et de nombreuses vulnérabilités dans des applications web importantes. Nous avons également trouvé des vulnérabilités d'exécution de code arbitraire déclenchables à distance (sans clic) dans la pile réseau du noyau Linux, qui ont depuis été corrigées en amont et divulguées publiquement. Nous détaillons un tel exemple ci-dessous.
Après une invite initiale, Claude a rédigé un exploit permettant à un attaquant distant d'envoyer des paquets à des serveurs Linux dotés d'un écouteur TCP multipath afin d'exécuter des commandes arbitraires en tant que root, sans aucune identification ni interaction de l'utilisateur. La vulnérabilité sous-jacente est un bug de type UAF induit par une condition de course dans la pile réseau du noyau. L'exploitation complète comporte deux étapes clés :
- Dans la première étape, l'attaquant vainc le KASLR à distance. Il exploite la condition de course pour faire lire au noyau un champ de longueur contrôlé par l'attaquant afin de copier des octets supplémentaires et de les lui renvoyer, et tant qu'un de ces dépassements de lecture contient un pointeur du noyau dans la réponse, l'attaquant découvre la disposition de l'espace d'adressage du noyau.
- Dans la deuxième étape, l'attaquant détourne le flux de contrôle. Il exploite le même bug UAF pour provoquer un débordement de tampon et écraser un pointeur de fonction de rappel avec l'adresse d'une charge utile qu'il a déjà placée en mémoire du noyau via une fonctionnalité ordinaire du protocole. Lorsque le noyau invoque la fonction de rappel, la charge utile enchaîne une série d'appels à des fonctions existantes du noyau, se terminant par l'exécution d'une commande shell choisie par l'attaquant en tant que root.
Une propriété facilitatrice de cette condition de course est qu'une course perdue ne fait qu'échouer la poignée de main sans faire planter tout le système, de sorte qu'un attaquant déterminé peut réessayer indéfiniment jusqu'à réussir. Dans notre preuve de concept, il faut 48 minutes pour divulguer un pointeur du noyau et cinq minutes supplémentaires pour parvenir à l'exécution de la commande shell. Cette vulnérabilité (CVE-2026-98432) a été corrigée en amont et rétroportée vers toutes les branches stables du noyau maintenues.
Ce que nous avons appris
Tout au long de notre processus d'utilisation de Claude pour ce travail de sécurité, nous avons identifié un certain nombre d'enseignements qui ont façonné notre approche. Nous pensons que deux d'entre eux sont particulièrement importants.
L'augmentation du calcul au moment du test et la diversité des scanners augmentent considérablement le nombre de vulnérabilités que vous trouvez. Nous avons construit une plateforme qui exécute un grand nombre d'agents de scan en parallèle, mesure chaque scanner selon le nombre de vulnérabilités supplémentaires qu'il apporte à l'ensemble, et suit la couverture de manière dynamique afin que les scanners traitent l'intégralité de la base de code.
Les stratégies vont de la couverture pure (y a-t-il une vulnérabilité dans cette fonction ?) à l'approche par objectifs (cette application expose-t-elle quelque chose qui pourrait compromettre les données des clients ?) en passant par l'approche fondée sur le modèle de menace (y a-t-il quelque chose dans cette application qui contourne son modèle de menace documenté ?). Nous avons également utilisé Claude pour mener une analyse automatisée de variantes sur chaque résultat confirmé. Tous les résultats passent par un pipeline standardisé de vérification et d'évaluation des risques, ce qui nous permet d'expérimenter librement de nouveaux scanners sans abaisser notre barre de qualité.
Corriger l'arriéré existant ne résout qu'une moitié du problème ; l'autre moitié consiste à réduire le rythme auquel de nouvelles vulnérabilités entrent dans la base de code. Pour cela, nous recommandons l'analyse au moment des PR. Nous avons intégré des directives de sécurité directement dans notre processus de développement via un plugin Claude Code, que nous avons publié publiquement.
Ce que cela signifie pour les défenseurs
Les modèles de pointe ont la capacité de découvrir et de combiner plusieurs vulnérabilités en un exploit fonctionnel. Ces compétences ont historiquement été le domaine de quelques équipes spécialisées possédant une expertise sur ces cibles. Désormais, c'est quelque chose que les modèles peuvent faire avec peu d'intervention humaine, puis le prouver en produisant un exploit fonctionnel que n'importe qui peut exécuter et vérifier.
Donner aux défenseurs accès à des modèles puissants est essentiel pour leur permettre de prendre de l'avance sur les attaquants dans le correctif des systèmes. Récemment, nous avons publié une version étendue de notre Programme de vérification cyber, qui rend des capacités cyber avancées et des classificateurs de blocage réduits disponibles pour les professionnels de la sécurité qualifiés. Il comprend l'accès à nos modèles les plus performants, notamment Claude Opus 5.5, Claude Sonnet 5.5, Claude Mythos 5.1, ainsi que d'autres nouveaux modèles à l'avenir. Notre conseil aux défenseurs reste le même : analyser votre propre code est plus important que jamais.
Auteurs & remerciements
Contributeurs
Nicholas Carlini, David Dworken, Xinyang Ge, Ben Morris, Milad Nasr, Chris Rohlf, Luna Tong