Anthropic affirme que Claude a découvert cinq chaînes d’exploitation et des vulnérabilités critiques

Cinq recherches, pas un audit indépendant

Anthropic a publié un rapport décrivant l’utilisation d’un modèle de recherche interne, qui n’a pas été rendu public, pour chercher des vulnérabilités dans des logiciels largement utilisés. L’entreprise présente cinq chaînes d’exploitation : l’une dans Chrome, une autre dans Safari, un contournement de l’écran de verrouillage d’Android, un déni de service à distance dans Windows et une exécution de commandes à distance sous Linux. Il s’agit des déclarations d’Anthropic au sujet de ses propres travaux, et non de résultats vérifiés de manière indépendante dans les documents disponibles.

Le rapport fournit des détails techniques et indique que les vulnérabilités ont été signalées aux fournisseurs concernés. Anthropic affirme que les failles décrites ont été corrigées, mais le niveau de détail rendu public varie selon les cinq cas et ne permet pas de considérer chaque chaîne comme une démonstration reproduite par des tiers. En outre, le modèle utilisé était interne et non publié : ces résultats ne prouvent pas que n’importe qui puisse obtenir les mêmes capacités avec un modèle accessible au public.

Il faut distinguer la découverte d’une faille, la construction d’une preuve de concept et la démonstration d’un impact dans une configuration précise. Le document donne des exemples de ces trois étapes, mais la description d’Anthropic ne constitue pas une évaluation externe du taux de réussite, des ressources nécessaires ou de la généralisation de la méthode à d’autres produits. Elle ne suffit pas non plus à attribuer au modèle, à lui seul, l’ensemble du travail d’analyse, de sélection et de vérification qui entre dans une recherche en sécurité.

Chrome et Safari : des chaînes qui combinent plusieurs failles

Pour Chrome, Anthropic décrit une chaîne qui commençait par une corruption de mémoire dans V8, le moteur JavaScript. Selon le rapport, l’exploitation s’appuyait ensuite sur d’autres défauts pour franchir des limites de mémoire et les protections d’isolation du navigateur, jusqu’à permettre l’exécution de code en dehors du bac à sable. La démonstration citée par l’entreprise ouvrait l’application Calculatrice dans Chrome, avec sa configuration par défaut, sur macOS. Cet exemple illustre l’impact allégué dans des conditions précises ; il ne démontre pas que toutes les installations ou versions étaient vulnérables.

La publication indique que Google a attribué 62 identifiants CVE aux découvertes et qu’à la date du rapport, les problèmes avaient été corrigés dans Chrome 156. Anthropic les décrit comme présentant une gravité élevée ou critique. L’entreprise rattache à cet ensemble 13 échappements du bac à sable et 21 vulnérabilités qui auraient pu compromettre le processus renderer. Ces chiffres correspondent au décompte communiqué par Anthropic : ils ne doivent pas être interprétés comme 62 chaînes d’exploitation complètes et indépendantes.

Pour Safari, le rapport décrit une attaque différente, visant à contourner la politique de même origine, qui empêche normalement une page de lire les données d’autres sites. Anthropic présente une combinaison d’un use-after-free dans JavaScriptCore, d’un accès en lecture et en écriture hors d’une zone protégée et d’une vulnérabilité dans le mécanisme IPC du bac à sable. La chaîne aurait permis d’accéder à des données locales du navigateur et de modifier un indicateur de sécurité pour désactiver la politique de même origine. L’entreprise précise que l’attaque ne reposait pas sur l’exécution de code arbitraire : elle combinait un accès à la mémoire et des modifications d’état.

Ce cas montre pourquoi une faille isolée ne suffit pas toujours à expliquer l’ensemble du risque. Certaines conditions décrites relevaient de comportements prévus qui, combinés à d’autres faiblesses, auraient contribué à l’attaque. Anthropic affirme qu’Apple a accusé réception du signalement et mis en place un correctif disponible pour les utilisateurs. L’article ne fournit pas d’évaluation externe permettant de mesurer le nombre d’utilisateurs exposés ou l’ampleur d’une exploitation réelle.

Android, Windows et Linux : trois cibles et trois types d’impact

Pour Android, Anthropic décrit un contournement qui aurait permis d’extraire des photos et d’autres données personnelles d’un téléphone Pixel 9 verrouillé. La recherche combinait l’analyse de parties du code open source, la rétro-ingénierie de composants de Google Play et des tests sur un appareil physique. La chaîne signalée franchissait plusieurs protections : le transfert USB, l’autorisation de jumelage, la vérification d’un code et un contrôle portant sur l’envoi de fichiers. Selon la publication, Google aurait corrigé le problème. L’extrait du rapport ne fournit pas la liste complète des versions concernées ni des appareils exposés.

Sous Windows, la découverte concernait une lecture hors limites dans l’implémentation du protocole QUIC du noyau. Anthropic affirme qu’un attaquant distant pouvait envoyer quelques paquets à un serveur répondant aux requêtes HTTP/3 et provoquer son plantage et son redémarrage. L’entreprise indique que Microsoft a corrigé la faille et lui a attribué l’identifiant CVE-2026-33096. Les travaux décrits reposaient sur l’analyse d’un exécutable et des outils de rétro-ingénierie ; l’impact signalé est un déni de service, et non une prise de contrôle à distance.

Pour Linux, Anthropic fait état d’un use-after-free causé par une condition de concurrence dans la pile réseau du noyau, sur des systèmes dotés d’un listener MPTCP. La chaîne alléguée comportait deux étapes : révéler une adresse du noyau, puis détourner le flux de contrôle afin d’exécuter une commande avec les privilèges administrateur. L’entreprise indique que la vulnérabilité a reçu l’identifiant CVE-2026-98432, qu’elle a été corrigée en amont et que le correctif a été reporté dans les branches stables encore maintenues. Anthropic estime que sa preuve de concept mettait environ 48 minutes à obtenir une adresse du noyau, puis cinq minutes supplémentaires à atteindre l’exécution de commandes. Ces durées décrivent cette démonstration, et non une garantie de performance générale.

Ces trois exemples ne sont pas équivalents : le cas Windows concerne une interruption à distance du service, tandis que les exemples de Chrome et de Linux décrivent une exécution de code ou de commandes dans les conditions détaillées. Le cas Android porte sur l’accès à des données sans déverrouiller l’appareil. L’évaluation du risque doit tenir compte du produit, de la version, de la configuration et des correctifs installés, et pas seulement de la gravité annoncée.

La méthode : plusieurs scanners et une vérification en aval

Anthropic attribue une partie des résultats à une plateforme qui exécute de nombreux agents d’analyse en parallèle. L’entreprise affirme mesurer la contribution de chaque scanner et suivre la couverture du code. Les stratégies décrites consistent notamment à chercher des failles fonction par fonction, à poursuivre des objectifs précis — comme l’exposition de données — et à vérifier si une application enfreint le modèle de menace qu’elle documente.

Le rapport mentionne également l’analyse automatisée de variantes : après confirmation d’une découverte, des cas similaires sont recherchés. Anthropic affirme que les résultats passent par un processus standardisé de vérification et d’évaluation du risque. Ce point compte, car émettre une hypothèse de faille ne suffit pas à établir qu’elle est reproductible ou exploitable. Toutefois, la publication ne détaille pas en profondeur l’ensemble des critères d’acceptation, le nombre de faux positifs ni une comparaison contrôlée avec des équipes humaines ou d’autres outils.

Pour les développeurs, Anthropic recommande d’intégrer l’analyse de sécurité à la revue des modifications de code, en plus de corriger les vulnérabilités déjà connues. L’objectif est préventif : examiner les nouvelles modifications peut aider à repérer les défauts avant leur intégration. Mais une recommandation ou une analyse automatisée ne garantit pas que toutes les failles seront détectées, ni que le logiciel obtenu sera exempt de vulnérabilités. L’efficacité dépend de la portée de l’analyse, du contexte disponible, de la revue humaine et de la réponse de l’équipe.

La publication met également en avant l’augmentation des ressources de calcul pendant les tests et la diversité des scanners. Selon l’entreprise, ces choix de configuration et de méthode ont accru le nombre de vulnérabilités découvertes dans son processus. Cela ne signifie pas qu’une hausse des ressources produira toujours de meilleurs résultats ni qu’un modèle générera des découvertes exactes sans vérification. L’accent mis sur la vérification montre justement que la détection et la confirmation sont deux étapes distinctes.

Ce que le rapport change pour les défenseurs — et ce qu’il ne démontre pas

Le résultat le plus important pour les équipes de sécurité est que, selon Anthropic, un modèle a pu relier plusieurs défauts dans des produits complexes et construire des preuves de concept aux impacts variés. La recherche automatisée pourrait élargir les capacités d’analyse du code et accélérer l’étude de variantes. Cette capacité peut aussi être utilisée à des fins offensives ; les découvertes renforcent donc l’importance de gérer les correctifs, de limiter l’exposition et de tester les systèmes avec autorisation.

Anthropic estime que ces compétences, auparavant concentrées dans des équipes spécialisées, pourraient devenir accessibles à des modèles avec peu d’intervention humaine. Il s’agit d’une interprétation de l’entreprise fondée sur ses expériences ; le rapport ne présente pas de comparaison indépendante quantifiant le volume de travail humain nécessaire ni la rapidité du processus par rapport aux méthodes habituelles. Il ne permet pas non plus de conclure qu’un attaquant inexpérimenté pourrait reproduire facilement les cinq chaînes.

Le document précise que le modèle était un système de recherche interne qui n’a pas été publié. Il serait donc erroné de transposer automatiquement ces résultats aux versions publiques de Claude ou de supposer qu’une interface accessible reproduit le même comportement. L’accès aux outils, le temps de calcul, les informations de départ, les limites de sécurité et la supervision humaine peuvent modifier sensiblement le résultat.

La prudence est particulièrement importante lorsqu’on compare cette publication à d’autres incidents de sécurité. Le texte d’Anthropic sur les vulnérabilités de produits tiers ne confirme pas qu’une entreprise extérieure ait pénétré les systèmes internes d’Anthropic, et ne fournit pas de données sur une éventuelle attaque de Cathedral. Ce sont deux sujets distincts. Au vu des informations disponibles ici, rien ne permet d’affirmer qui aurait accédé à quels systèmes, combien de temps cela aurait pris ou quelles données auraient été obtenues.

Pour les organisations qui gèrent des logiciels, la conclusion pratique n’est pas de compter sur un modèle pour trouver toutes les failles. Il est préférable de tenir à jour l’inventaire des actifs, d’installer les mises à jour, d’examiner les composants exposés et de valider les découvertes dans un environnement autorisé. Les équipes peuvent s’appuyer sur des outils automatisés, mais doivent conserver des contrôles d’accès, une revue humaine et des procédures de divulgation coordonnée. Le rapport présente des exemples concrets de risques et de correctifs signalés ; il ne garantit pas la sécurité et ne démontre pas une capacité universelle.

Comment interpréter la portée opérationnelle de ces découvertes

Les détails techniques sont utiles parce qu’ils permettent de distinguer les types d’impact et de comprendre comment des failles peuvent se renforcer mutuellement. Dans une analyse défensive, une chaîne peut être plus importante qu’un défaut isolé si elle combine une vulnérabilité mémoire et un moyen de franchir une frontière de sécurité. La priorité de la réponse doit néanmoins s’appuyer sur l’exposition réelle, les versions déployées, la disponibilité des correctifs et les mesures d’atténuation possibles, et non uniquement sur une démonstration spectaculaire.

Les équipes peuvent utiliser les découvertes publiées pour vérifier leurs inventaires et les mises à jour des produits concernés, sans chercher à reproduire une chaîne contre des systèmes tiers. Toute étude d’une vulnérabilité doit être menée dans un laboratoire contrôlé, avec autorisation et des versions préparées pour les tests. Une preuve de concept de sécurité peut entraîner des effets indésirables si elle est exécutée en production ou contre l’infrastructure d’un tiers.

La recommandation d’intégrer des revues au processus de développement ne supprime pas non plus la nécessité d’une défense en profondeur. Les contrôles automatisés peuvent détecter des motifs connus ou signaler du code suspect, tandis que l’analyse humaine apporte du contexte et permet d’évaluer le risque. Aucun de ces mécanismes ne garantit à lui seul une couverture complète. Leur intérêt réside dans la combinaison de la détection, de la validation, de la correction et du suivi.

En somme, le rapport présente des éléments détaillés sur ce qu’Anthropic affirme avoir réalisé dans une recherche interne et sur les démarches de signalement et de correction qu’elle attribue aux fournisseurs. C’est un signal important sur l’évolution de la recherche assistée par des modèles, mais sa portée doit rester circonscrite : les résultats d’une entreprise, sur des systèmes précis et avec un modèle non publié, sans réplication indépendante documentée dans les sources disponibles.

Poursuivre l’exploration

Corrections et transparence

Si vous repérez une information incorrecte ou obsolète, envoyez-nous la page et la source à vérifier.