Les 500 zero-days de Claude Opus 4.6 : ce que révèlent trois correctifs

Le 5 février 2026, la Frontier Red Team d’Anthropic a publié des recherches indiquant que Claude Opus 4.6, sorti le jour même, avait trouvé et validé plus de 500 vulnérabilités de gravité élevée dans des logiciels open source — sans outils propres à la tâche, sans échafaudage personnalisé ni prompting spécialisé. Trois constats sont décrits en détail : un contrôle des bornes de pile manquant dans Ghostscript, une série d’appels à strcat non vérifiés dans OpenSC, et un débordement de tampon dans l’encodeur GIF CGIF qui dépend du comportement de la compression LZW lorsque son dictionnaire se remplit. Anthropic indique que les trois ont désormais été corrigés par leurs mainteneurs et, selon son récit, les bogues ont été trouvés, validés et signalés. Le billet note que nombre des projets sont maintenus par de petites équipes ou des bénévoles sans personnel de sécurité dédié, si bien que la charge de signalement et de correction leur est revenue. La propre entrée de l’archive pour ce constat, classée en gravité « info » sans préjudice réel consigné, figure dans l’Orca AI Incident Archive aux côtés des autres documents de politique et de divulgation de février 2026.

Ce qu'Anthropic a réellement publié

L’article est intitulé « Évaluer et atténuer le risque croissant de 0-days découverts par les LLM » et est attribué à la Frontier Red Team : Nicholas Carlini, Keane Lucas et Evyatar Ben Asher en tant que contributeurs égaux, avec Newton Cheng, Hasnain Lakhani, David Forsythe et Kyla Guru. La page porte une date de publication au 5 février 2026 et une note de modification datée du 6 février 2026 indiquant que la liste des auteurs a été mise à jour. L’archive cite l’article à red.anthropic.com, qui redirige désormais vers anthropic.com/research/zero-days.

La méthode compte davantage que le chiffre mis en avant. Anthropic indique avoir placé le modèle dans une machine virtuelle ayant accès aux dernières versions de projets open source, et lui avoir fourni des utilitaires standards ainsi que les outils qu’utiliserait un chercheur en sécurité humain — débogueurs et fuzzers —, mais sans instructions sur leur utilisation et, selon les termes de l’article, « aucun harnais personnalisé qui lui aurait donné des connaissances spécialisées sur la manière de mieux trouver des vulnérabilités ». Ce qui était testé, c’était le comportement du modèle par défaut.

L’équipe a restreint la recherche aux bogues de corruption de mémoire, en partant du principe qu’un plantage est plus facile à confirmer qu’une erreur de logique. Anthropic précise clairement qu’il s’agit d’un filtre, et non d’une garantie : « toutes les entrées qui font planter un programme ne sont pas des vulnérabilités de haute gravité ». Les plantages ont donc été renvoyés au modèle pour qu’il les critique, les déduplique et les reclasse par ordre de priorité, puis à des personnes. « Pour notre première série de résultats, nos propres chercheurs en sécurité ont validé chaque vulnérabilité et rédigé les correctifs à la main. À mesure que le volume de résultats augmentait, nous avons fait appel à des chercheurs en sécurité externes (humains) pour nous aider à valider et à développer les correctifs. » L’automatisation des correctifs, indique l’article, était encore en cours de développement.

Trois bugs, et les correctifs qui ont suivi

Les trois exemples traités partagent une même structure : un outil automatisé avait déjà échoué, et le modèle a trouvé le bug en raisonnant sur autre chose que la mutation des entrées.

• Ghostscript, l'interpréteur PostScript et PDF. Le fuzzing, puis l'analyse manuelle, n'ont rien donné. Le modèle a ensuite consulté l'historique Git du projet, trouvé un commit décrit dans le billet comme ajoutant « stack bounds checking for MM blend values » aux charstrings Type 1, en a déduit que le code antérieur à ce commit était vulnérable, puis est allé chercher d'autres sites d'appel qui n'avaient pas reçu le même traitement. Il en a trouvé un dans gdevpsfx.c — le billet cite la ligne 292 — et a construit un fichier qui fait planter le programme. Le dépôt le confirme : le commit 87486fb801 de Chris Liddell, daté du 5 septembre 2025, est intitulé « Type 1 charstrings: add stack bounds checking for MM blend values ». Un correctif ultérieur de Ken Sharp, le commit 4e392a82 daté du 26 janvier 2026, ajoute des contrôles de limites juste avant cet appel dans le convertisseur de polices, rattaché au Bug 709080, dont le rapport est intitulé « Ghostscript Incomplete fix for Type 1 MM blend stack bounds check ». Un commit du 13 février 2026 a étendu les contrôles de limites dans le même convertisseur. Aucun des messages de commit ne dit qui a signalé le bug.

• OpenSC, un utilitaire en ligne de commande pour les données de cartes à puce. Ici, le modèle a recherché des appels à des fonctions risqués et a trouvé des opérations successives strcat écrivant dans un tampon filename de 4096 octets, après un calcul de taille qui soustrayait la longueur d'une chaîne d'entrée mais ajoutait ensuite d'autres chaînes sans revérifier. Le billet note que les fuzzers existants atteignaient rarement ce chemin en raison des préconditions impliquées. Le commit 33ab343a5c d'OpenSC du 19 janvier 2026 a ajouté une vérification que la chaîne ajoutée fait exactement 64 octets, et la pull request #3554, fusionnée le 25 janvier 2026, a remplacé les appels strcat restants dans tout le projet par strlcat ; son auteur a qualifié la fonction d'« aimant pour tous les outils d'analyse statique et les CVE ».

• CGIF, un encodeur GIF. La bibliothèque supposait que les données compressées seraient toujours plus petites que l'entrée non compressée, ce qui est presque toujours vrai. Le modèle a déduit que LZW construit un dictionnaire de taille fixe, et que lorsque le dictionnaire se remplit, les codes d'effacement insérés dans le flux peuvent rendre la sortie « compressée » plus longue que l'entrée — ainsi, un tampon dimensionné pour N+2 codes pourrait recevoir plus de N+1. Le billet indique que même une couverture de lignes et de branches à 100 pour cent pourrait ne pas révéler cela, car cela nécessite une séquence particulière d'opérations. La pull request #84 de CGIF, fusionnée le 19 janvier 2026 et publiée le même jour en tant que v0.5.1, corrige précisément cela : « Les codes d'effacement de réinitialisation manquaient dans le calcul de la borne supérieure de la taille des données LZW. »

Ces correctifs ont été intégrés avant la publication de la recherche — CGIF et OpenSC le 19 janvier 2026, OpenSC de nouveau le 25 janvier, Ghostscript le 26 janvier — et Anthropic a déclaré dans l’article avoir « commencé à les signaler et constater l’intégration de nos premiers correctifs » avant de rendre l’affaire publique. Les dépôts enregistrent les modifications de code ; ils n’enregistrent pas qui a déposé les signalements, de sorte que le lien entre les conclusions du modèle et ces commits précis repose sur le compte rendu d’Anthropic et sur la mesure dans laquelle les défauts décrits correspondent aux diffs.

The researcher who said the OpenSC bug was not real

Public scrutiny of the individual findings did not start and end with Anthropic. On 14 February 2026 K. Reid Wightman, an industrial security researcher posting as @reverseics on infosec.exchange, published a review of the OpenSC example arguing the bug could not be triggered: the input string was already checked to be 64 bytes at line 5138, he wrote, which capped the buffer at 4095 bytes including the terminator. "I spent about an hour looking at the code to debunk their finding," he wrote.

He edited the same post on 17 February 2026 to withdraw the challenge. "Looks like the version of code I was looking at, already had a fix for anthropic-discovered bug(s)," the edit reads, before conceding the arithmetic: "but yes without the strlen() check on 'fp' the overflow could actually be triggered. The humble pie has been eaten." The check he had relied on was the one added to OpenSC on 19 January 2026 — before Anthropic published, and before most readers would have gone looking. The archive does not flag the record as disputed, and here the challenge was retracted by the person who raised it.

OpenSC's own maintainers answered the same question in their tracker. In discussion #3575, opened on 17 February 2026 by a user asking whether Anthropic's claims were legitimate, OpenSC maintainer frankmorgner replied the same day: "We received two bug reports from anthropic, which were both verified by humans." He said the fixes were in pull request #3554 and would be in the next release, and that commit 33ab343 was "a change that was introduced after anthropic reported the problem."

Le volet gouvernance : enquêtes, blocage et 90 jours

Ce qui fait de ce billet un document de politique plutôt qu’une simple note de recherche, c’est sa seconde moitié. Parallèlement à la publication du modèle, Anthropic indique avoir introduit des sondes spécifiques à la cybersécurité qui mesurent les activations à l’intérieur du modèle pendant qu’il génère une réponse, et avoir mis à jour ses processus d’application des règles pour recourir à une détection fondée sur ces sondes. Cela va plus loin que la détection : « nous pouvons mettre en place une intervention en temps réel, y compris bloquer le trafic que nous détectons comme malveillant ». Anthropic reconnaît le coût — « Cela créera des frictions pour la recherche légitime et certains travaux défensifs » — et dit vouloir travailler sur ce point avec la communauté de la recherche en sécurité. Aucun taux de détection, taux d’erreur ni procédure de recours n’est publié.

L’article soutient également que le calendrier de divulgation est désormais lui-même un problème. « Les fenêtres de 90 jours standard de l’industrie pourraient ne pas résister à la vitesse et au volume des bogues découverts par les LLM », affirme-t-il, et il avertit que les modèles « pourraient bientôt dépasser la vitesse et l’échelle même de chercheurs humains experts ». C’est un fournisseur qui soutient que la norme à l’aune de laquelle il sera jugé doit être remplacée, et c’est la partie du dossier qui a la plus longue portée.

Qu’est-ce qui a changé par la suite ?

Le 20 février 2026, Anthropic a ouvert Claude Code Security en tant qu’aperçu de recherche limité pour les clients Enterprise et Team, avec un accès accéléré gratuit pour les mainteneurs de l’open source — la capacité ayant été transformée en produit quinze jours après la recherche. VentureBeat a rapporté le lancement et indiqué avoir demandé à Anthropic le taux de faux positifs avant et après auto-vérification, le nombre de vulnérabilités divulguées dont les correctifs ont été déployés par rapport à celles encore en triage, ainsi que les garde-fous qui distinguent l’utilisation par un attaquant de celle par un défenseur ; il a rapporté que le chercheur principal du projet était indisponible et que l’entreprise avait refusé de partager les mécanismes spécifiques de détection d’attaquants.

Les correctifs continuaient aussi de bouger, et pas toujours dans la même direction. Le correctif de CGIF pour l’allocation décrite par Anthropic a été livré dans la v0.5.1 le 19 janvier 2026 ; le 21 février 2026, la pull request #103 a corrigé un dépassement d’entier 32 bits introduit par ce même calcul d’allocation, publié sous la v0.5.2 le lendemain pour les GIF à la taille maximale de 65 535 × 65 535 pixels. Réparer un calcul de bornes, il s’avère, est sa propre petite source de bugs de bornes.

Lire correctement le nombre

La phrase d'Anthropic elle-même est « plus de 500 vulnérabilités de gravité élevée ». Axios, que l'entreprise a informé en premier, les a décrites le jour de la publication comme « plus de 500 vulnérabilités zero-day jusqu'alors inconnues », chacune validée par un membre de l'équipe d'Anthropic ou par un chercheur en sécurité externe. Les deux descriptions renvoient au même ensemble, mais une seule reprend les termes du fournisseur, et ni l'une ni l'autre n'est accompagnée d'une liste, d'une correspondance CVE ou d'une répartition par gravité. Le décompte est celui d'Anthropic, les évaluations de gravité sont celles d'Anthropic, et les trois projets traités dans l'article sont les seuls que le public puisse vérifier.

L’analyse indépendante qui a suivi a surtout pris le chiffre au pied de la lettre et débattu de ce qu’il signifie. Mitch Ashley, de Futurum Group, a écrit le 24 février 2026 que le résultat « compte davantage pour ce que la méthode révèle que pour le décompte », et que la véritable contrainte se situe en aval : « Faire remonter plus de vulnérabilités plus rapidement ne réduit pas la surface d’attaque. Cela construit une file d’attente plus grande devant un processus en aval qui ne peut pas absorber le volume. » Il s’agit d’une critique du pipeline de divulgation plutôt que du résultat, et elle rejoint le même point qu’Anthropic a soulevé à propos des fenêtres de 90 jours.

Ce que le dossier n’établit pas

L’archive attribue à cet enregistrement la confiance A et la gravité info, sans préjudice réel consigné ni indicateur de contestation. Cette notation concerne la qualité de la documentation de l’événement, et non le degré d’audit de l’affirmation sous-jacente, et il vaut la peine de garder cette différence à l’esprit. Personne en dehors d’Anthropic n’a vérifié les 500. Aucun taux de faux positifs n’a été publié. Les correctifs des trois projets nommés sont réels et datables, et constituent la corroboration la plus solide disponible — mais ils corroborent trois exemples, pas le total.

Ce qui reste, donc, c’est une annonce bien documentée, avec un noyau vérifiable et un reste invérifiable : un fournisseur qui rapporte une capacité, trois diffs en amont qui correspondent à sa description des bugs, et une intention déclarée d’encadrer les usages abusifs de cette capacité au niveau du modèle. L’archive la classe comme une politique, ce qui est la bonne étagère. La revendication de capacité sera tranchée par celui qui publiera le quatrième patch.