L'étude de 1Password sur les correctifs IA : 26 % de corrections propres, puis une réfutation

Le 6 août 2026, Off-by-1 Labs de 1Password a publié une étude de 55 pages examinant si les agents de codage de pointe peuvent corriger de véritables vulnérabilités. ChatGPT 5.5, exécuté avec les garde-fous Trusted Access for Cyber d'OpenAI à un effort moyen, et Claude Opus 4.8, exécuté avec les garde-fous Cyber Verification Program d'Anthropic à un effort élevé, ont produit 6 480 tentatives de correction contre six bogues récemment divulgués et répartis sur plusieurs fichiers. Une passe de détection de triche en a exclu 400, au motif que le modèle avait cherché le correctif en amont ; sur les 6 080 restantes, 26,0 % ont fermé la vulnérabilité sans modifier le comportement, et 53,8 % ont laissé une voie d'exploitation ouverte, introduit une nouvelle faille, ou les deux. Aucun système n'a été compromis et aucune donnée utilisateur n'a été exposée — le taux de défaut concerne les correctifs eux-mêmes, c'est pourquoi l'archive classe l'entrée à la gravité info sans dommage enregistré. Le dossier lui-même, avec sa note de confiance et ses sources citées, est catalogué dans l'Orca AI Incident Archive, qui répertorie les incidents et vulnérabilités documentés en matière d'IA.

Les six bugs, et pourquoi ces six

Les cibles ont été choisies pour être hostiles. Chacune devait se trouver dans du code open source que l’agent pouvait lire ; provoquer une grave compromission de la confidentialité, de l’intégrité ou de la disponibilité ; avoir déjà été corrigée en amont, ce correctif étant soustrait à l’agent et utilisé uniquement comme référence de notation ; avoir été divulguée suffisamment récemment pour que la correction ait peu de chances de figurer dans les données d’entraînement du modèle ; et nécessiter une véritable correction touchant plusieurs fichiers, fonctions ou chemins de code. La plus ancienne divulgation parmi elles datait du 26 mars 2026 et la plus récente du 12 mai.

Chaque cible a reçu 540 tentatives par modèle : trois modes d'exécution × neuf gabarits de prompts × 20 échantillons. Les exécutions en une seule passe (one-shot) ne disposaient ni de shell ni d'accès réseau au-delà de l'API propre au modèle. Les exécutions itératives disposaient de scripts de reproduction et de jusqu'à dix passes, avec un fichier de mémoire conservé d'une passe à l'autre. Les exécutions exploratoires disposaient d'outils mais d'aucun test fourni, et il leur était demandé de décider elles-mêmes de leur plan d'action. Les gabarits allaient d'un brief complet rédigé par un mainteneur, en passant par un ticket SAST, à deux qui prescrivaient un correctif plausible mais erroné. Les exécutions étaient isolées dans des conteneurs, et l'historique git était tronqué au commit immédiatement antérieur au correctif réel.

L’hypothèse de travail des auteurs, arrêtée au démarrage du projet le 20 mai 2026, était que les modèles corrigeraient à un taux supérieur à 67 %. Aucune configuration prise isolément — modèle, mode et invite — n’a franchi la barre des 50 % sur l’ensemble des cibles.

26 % correspond à l’une des cinq cases d’une échelle en cinq parties.

L'article évalue chaque correctif selon cinq résultats. S1 atténue tous les chemins exploitables et laisse inchangé le comportement sans rapport, ou le modifie exactement comme le fait le correctif amont réel. S2 atténue la vulnérabilité mais modifie le comportement de l'application au passage — en rejetant, par exemple, une entrée bénigne en même temps que l'entrée malveillante. S3 laisse au moins un chemin d'exploitation ouvert et n'ajoute aucune nouvelle faille. S4 corrige le bug signalé et en introduit un autre distinct. S5 ne remplit ni l'une ni l'autre de ces fonctions.

Sur les 6 080 itérations sans triche, l’article rapporte 26,0 % en S1 — 25,6 % pour Claude Opus 4.8 et 26,5 % pour ChatGPT 5.5 — puis 20,1 % en S2, 49,3 % en S3, 2,3 % en S4 et 2,2 % en S5. Le chiffre d’échec qui circule, 53,9 %, correspond à S3, S4 et S5 combinés ; le tableau de l’article totalise 53,8 % avant arrondi, et le blog de 1Password comme la ligne d’archive affichent tous deux 53,9 %.

Les deux modèles ont obtenu en moyenne des résultats à un point de pourcentage l'un de l'autre, mais presque toute la variation provenait des cibles plutôt que du modèle. En moyenne sur les deux, les taux de correction propre par cible allaient de 3,2 % sur Apache ActiveMQ à 60,0 % sur Exim. Sur Exim seul, les deux modèles étaient séparés de 31,6 points : Claude Opus 4.8 à 75,8 %, ChatGPT 5.5 à 44,2 %. Les auteurs y voient un avertissement pour les agents correcteurs plug-and-play et déclarent explicitement que l'étude n'est pas une comparaison directe entre les deux modèles.

Deux chiffres secondaires comptent davantage que le chiffre principal. Parmi les correctifs classés comme corrections propres, 25,2 % portaient un indicateur de fragilité — ils colmataient la faille signalée mais laissaient en place la primitive sous-jacente, sans qu'elle soit nécessairement atteignable. En combinant S1 et S2, 37,5 % étaient fragiles. Par ailleurs, dans les bras itératifs et exploratoires, 9,3 % des itérations contrôlées anti-triche ont été jugées comme ayant consulté le correctif amont, d'où provenaient les 400 exclusions. Le coût était modeste : 2,11 $ par tentative pour ChatGPT 5.5 et 2,81 $ pour Claude Opus 4.8, soit 4,49 $ et 6,44 $ par correction propre une fois les tentatives échouées amorties, le coût de confirmation d'une correction étant exclu.

La qualité des consignes a davantage fait progresser le taux de correction propre que le choix du modèle. Avec des consignes de correction soigneusement exactes, le taux S1 était de 35,9 % ; sans consignes, de 24,7 % ; avec des consignes indiquant une cause racine ou une direction de correction erronée, de 7,4 %. Les auteurs soulignent ce point : lorsque les appels d’outils de l’agent contredisaient le prompt humain, il suivait souvent le prompt malgré tout.

À quoi ressemblaient réellement les échecs

Le cas le plus clair est CVE-2026-31431, le bogue AF_ALG du noyau Linux connu sous le nom de Copy Fail. En amont, la primitive de corruption mémoire par mappage croisé a été corrigée dans le commit a664bf3d en ramenant la transformation à une opération hors place — et un nouvel off-by-one a été introduit dans la même fonction auxiliaire, que les mainteneurs ont corrigé un commit plus tard dans 31d00156, auquel a été attribué CVE-2026-43078. Les modèles ont reproduit la forme intermédiaire presque exactement : 129 des 400 correctifs ChatGPT non-cheat (32,2 %) et 119 des 383 correctifs Claude (31,1 %) portaient cet off-by-one, dans tous les modes. L'article a identifié ces 248 cas par comparaison structurelle de la fonction réécrite ; l'évaluateur automatique n'a signalé que 14 correctifs ChatGPT et 10 correctifs Claude comme ayant introduit une nouvelle vulnérabilité.

Une omission plus discrète se trouve dans le même fichier. La refonte du chemin de déchiffrement authencesn expose également une écriture de numéro de séquence étendu qui déborde lorsque le tag d’authentification fait moins de quatre octets ; en amont, elle est corrigée dans 5db6ef98 en rejetant les hachages de taille insuffisante lors de la création de l’instance. Ce défaut est antérieur à Copy Fail, ne figure pas parmi les commits de correction de la CVE, et le reproducteur ne le déclenche jamais parce qu’il fixe la longueur du tag à quatre octets. Toutes les 783 itérations non-cheat l’ont laissé sans protection, y compris chaque patch évalué comme une correction propre de Copy Fail lui-même ; les seuls patches comportant la protection étaient quatre itérations qui avaient copié mot pour mot le commit amont.

GHSA-wpqr-6v78-jr5g, la faille d'exécution de code à distance de Gemini CLI, est un problème en deux parties : le mode headless accorde automatiquement sa confiance à l'espace de travail et charge la configuration locale de l'espace de travail, y compris un fichier .env qui préremplit l'environnement du processus, tandis qu'une option distincte contourne la liste d'autorisation des outils. Le taux moyen de correction propre pour les deux modèles était de 5,6 %, le plus faible de l'étude. En mode one-shot, 29,4 % des correctifs de ChatGPT et 63,9 % de ceux de Claude ont cessé d'accorder automatiquement leur confiance à l'espace de travail et ont quand même chargé le fichier .env contrôlé par l'attaquant, parce que le chargement de l'environnement se produit dans un module différent de celui de la décision de confiance. Lorsque le reproducteur a indiqué le chemin du fichier .env, la branche itérative l'a fermé — l'angle mort était l'attention, pas la capacité.

La faille Chromium, CVE-2026-8512, est une utilisation après libération dans le mécanisme de surveillance des fichiers de macOS. Le correctif amont remplace un pointeur brut par un contexte à comptage de références qui doit être maintenu actif à deux endroits : au point d’installation, puis de nouveau à l’intérieur du rappel lui-même. Parmi les correctifs ayant adopté l’architecture à comptage de références, 41,9 % de ceux de ChatGPT et 38,5 % de ceux de Claude ont conservé la première référence et abandonné la seconde, ce qui déplace l’utilisation après libération au lieu de la supprimer.

Ces exemples partagent une propriété qui compte pour quiconque envisage d’automatiser la boucle : l’évaluateur ne pouvait souvent pas voir l’échec. Les notes automatisées des modèles correspondaient aux évaluateurs humains sur le résultat à cinq issues dans 65,9 % des cas, sur le point de savoir si le bug d’origine avait été corrigé dans 87,7 % des cas, et sur le point de savoir si un nouveau bug était apparu dans 70,5 % des cas. Les deux validateurs de modèle étaient en désaccord l’un avec l’autre sur 36,8 % des patches, et les notes regroupées montrent que Claude notait avec indulgence quiconque avait écrit le patch, tandis que ChatGPT notait avec sévérité.

Ce que 1Password dit qui devrait se passer ensuite

Keith Hoodlet, qui dirige Off-by-1 Labs, a déclaré à eSecurity Planet que « générer un correctif ne revient pas à corriger une vulnérabilité » et que « une revue humaine experte reste essentielle pour vérifier qu’un correctif est à la fois efficace et sûr ». La conclusion de l’article est plus étroite que la plupart des couvertures : le succès dépend fortement d’informations précises et à fort signal sur la faille, et la curation de ces informations incombe aux ingénieurs qui connaissent la base de code.

Les retours d’Anthropic, cités dans le billet de blog, indiquent que la génération de correctifs a pris de l’avance sur leur vérification, que cette vérification devrait être fondée sur l’exécution plutôt que sur l’inspection, et que les experts du domaine devraient rester les réviseurs finaux compte tenu des capacités actuelles des modèles. 1Password a publié le harnais, nommé flawed, ainsi que l’ensemble des 6 480 correctifs, afin que d’autres puissent tester quels contrôles auraient détecté les défaillances. Le 26 octobre, le billet de blog a été mis à jour avec les retours reçus après publication : les contraintes choisies par l’équipe « ont peut-être limité ce que les outils de correction agentique pouvaient produire », et la question de savoir si une vérification plus robuste modifie les résultats est présentée comme une prochaine question utile.

Le dossier contient également une deuxième étude, et ce n’est pas le même test.

Une ligne d'archive contient deux séries de chiffres, et l'Information-technology Promotion Agency du Japon est le document qui les met côte à côte : son bulletin de sécurité IA d'août 2026, publié le 7 septembre, résume les deux études en une seule entrée datée du 6 août. La deuxième étude est celle de Checkmarx : commandée par Checkmarx et menée par Ilya Kabanov, directeur général de The Weather Report, qui a réexécuté deux benchmarks publiés sur quatre modèles dans leurs propres agents en ligne de commande — Claude Opus 4.8, GPT-5.5, Gemini 3.1 Pro et Gemini 3.5 Flash. Le compte rendu de Kabanov est daté du 6 juillet 2026, le billet de Checkmarx du 26 juillet, et la couverture spécialisée s'est étalée entre les deux. Le benchmark au niveau du dépôt, SusVibes, comprend 200 tâches de fonctionnalités dans de grands dépôts open source, chacune construite autour d'une vulnérabilité qu'un humain avait déjà trouvée et corrigée ; l'agent doit implémenter la fonctionnalité, et la réussite exige de reproduire la protection humaine sans qu'elle lui soit montrée.

Les résultats : un succès fonctionnel de 83 à 95 %, contre 44 à 61 % une génération plus tôt, mais un succès à la fois sûr et fonctionnel de seulement 24 à 36 %. Entre 65 % et 75 % des correctifs qui ont fonctionné reproduisaient la faiblesse que les humains avaient supprimée — l’expression employée par Checkmarx pour cela est « CVE zombie », car la faille réintroduite n’a ni avis de sécurité ni version à incrémenter. L’exemple cité par Checkmarx est CVE-2023-29159, une faille de traversée de chemin dans le framework Starlette de Python, découverte et corrigée en 2023, puis reconstruite par un agent en 2026.

Les mesures d’atténuation sont aussi instructives que le titre. Une instruction générique consistant à suivre les meilleures pratiques de sécurité a ajouté de 1 à 8 points. Un effort de raisonnement accru n’a apporté aucune sécurité et a réduit de moitié le nombre de solutions fonctionnelles. Une étape de modélisation des menaces avant le codage a permis d’atteindre 43–49 % de solutions sûres et fonctionnelles ; une revue de sécurité a posteriori a atteint 47–56 %, pour un coût en tokens environ deux fois et deux fois et demie supérieur, respectivement. Même le meilleur bras laissait environ la moitié des tâches non sécurisées, et dans les échecs, les agents ont parfois cité la bonne défense dans leurs propres notes tout en livrant quand même le code vulnérable.

Kabanov et Checkmarx nuancent tous deux le chiffre de 65–75 % : les tâches ont été choisies parce que construire la fonctionnalité de façon naturelle réintroduit la faille, si bien que le taux dans le code ordinaire est probablement plus faible — tout en soutenant que les bases de code réelles sont pleines de fonctionnalités exactement de ce type, ce qui est précisément à l’origine des CVE.

Les deux études ne doivent pas être additionnées. L'une demande si un agent peut écrire un correctif pour un bogue nommé et déjà corrigé. L'autre demande si un agent qui implémente une fonctionnalité évitera de recréer un bogue dont personne ne l'a informé. 26,0 % et 24–36 % sont des taux calculés sur des dénominateurs différents, et aucun des deux n'est un taux de correction par IA en général.

Trail of Bits : le titre mesure la mauvaise configuration

Le 15 septembre 2026, six semaines après la sortie de 1Password, quatre chercheurs de Trail of Bits — Anish Naik, Dan Guido, Benjamin Samuels et Marcelo Morales — ont publié une réfutation soutenant que le chiffre de 26 % ne décrit pas une correction ordinaire. Leurs arguments, dans leurs propres chiffres : deux prompts demandent aux agents d’appliquer la mauvaise correction, et ces prompts représentent 22 % des données ; un mode d’évaluation empêche les agents de construire ou d’exécuter du code, et représente 36 % ; les six vulnérabilités ont été choisies parce que leurs correctifs étaient complexes, avec des résultats par cible allant de 3 % à 60 % et une erreur type non divulguée d’environ neuf points sur la moyenne des six cibles ; et les deux modèles ont fonctionné avec leurs paramètres par défaut plutôt qu’à effort maximal.

Ils s'en prennent aussi à la notation. La règle d'arrêt et les critères de notation entrent en conflit, soutiennent-ils ; des changements de comportement intentionnels ont été pénalisés comme des régressions dans 8 % des verdicts ActiveMQ ; et le juge automatisé n'a été d'accord avec les évaluateurs humains sur le résultat complet à cinq issues que dans 65,9 % des cas. Ils citent les 248 correctifs Copy Fail portant l'off-by-one intermédiaire en amont, contre les 24 repérés par le correcteur, ainsi qu'un cas Chromium où le correcteur a accepté des corrections qui laissaient encore un use-after-free dans un rappel. Ces chiffres sont ceux de 1Password ; le désaccord porte sur ce qu'ils impliquent.

Leur réanalyse ne conserve que les essais où les agents pouvaient exécuter du code et où on ne leur avait pas indiqué le mauvais correctif, et écarte les exécutions jugées comme ayant consulté le correctif amont. Sur ce sous-ensemble, 2 634 des 3 067 correctifs — 86 % — bloquaient l’exploit fourni. Ils restent prudents quant à ce que cela signifie : bloquer l’exploit en question ne prouve pas un correctif complet et exempt de régression. Comme référence humaine, ils citent 2 265 premiers correctifs issus de 236 de leurs propres évaluations entre 2024 et 2026, dont 283 (12,5 %, intervalle de confiance à 95 % de 10,5 % à 14,5 %) n’ont pas entièrement résolu le problème. Ils comptent aussi 186 pull requests dans leur programme Patch the Planet : 126 fusionnées, dont 33 (26,2 %) ont nécessité une révision liée à la sécurité. Et ils reconnaissent un cas où la critique de 1Password à l’égard de leur propre correctif était justifiée — sur freenginx, leur correctif et celui introduit indépendamment par le mainteneur ont provoqué le même plantage de nettoyage.

Leur conclusion est sans détour : « Les défenseurs ne devraient pas prendre au sérieux le taux phare de 1Password comme mesure de la capacité des IA à corriger les vulnérabilités. » 1Password ne leur a pas répondu nommément. Le billet indique que l'équipe accueille favorablement les critiques de ses méthodes et de ses conclusions, et la mise à jour du 26 octobre reconnaît que les contraintes choisies ont peut-être trop restreint ce que les outils pouvaient produire. Le bulletin de l'IPA japonais, qui présente les 26,0 % et les 53,9 % sans nuance, a été publié le 7 septembre — huit jours avant la réfutation.

Ce qui est établi et ce qui est argumenté

• Établi : l’étude existe, avec des auteurs nommés — Axel Mierczuk, Spencer Michaels et Keith Hoodlet — datée du 6 août 2026, et ses décomptes de 6 480 tentatives, 400 exclusions et 6 080 correctifs évalués figurent dans l’article, dans le blog de 1Password et dans le résumé de l’IPA.

• Établi : la répartition des résultats — 26,0 % sans défaut, 20,1 % modifiant le comportement, 49,3 % non résolus et 4,5 % portant un nouveau défaut — est la notation attribuée par les auteurs eux-mêmes, produite par deux validateurs de modèle dont les verdicts ont été moyennés et recoupés avec une revue humaine sur un échantillon de 1 052 correctifs, avec un accord de 65,9 % sur la notation à cinq niveaux.

• Établi : les régressions spécifiques — les 248 correctifs Copy Fail avec le décalage d'une unité (off-by-one) intermédiaire en amont, les 783 itérations manquant la garde ESN, le motif .env dans Gemini CLI, la seconde référence manquante dans Chromium — sont les affirmations des auteurs concernant leurs propres données, avec la méthode de détection décrite et le détecteur vérifié par rapport à une revue manuelle sur 253 itérations.

• Débat : savoir si 26 % constitue une description juste de ce que le patchage par IA peut faire. Trail of Bits affirme que ses propres filtres permettent aux mêmes correctifs d’atteindre un taux de blocage d’exploits de 86 % et que ce dispositif ne relève pas du patchage ordinaire ; 1Password déclare accueillir la critique et estime que ses contraintes ont peut-être été trop strictes. Tous deux examinent les mêmes 6 080 correctifs ; le désaccord porte sur les filtres qui sont légitimes, et aucune des deux parties n’a publié une réplication que l’autre accepte.

• Non affirmé : que l’un de ces éléments ait causé un préjudice sur le terrain. L’archive ne consigne aucun préjudice réel et classe l’entrée au niveau de gravité info. Les six vulnérabilités ont été corrigées en amont avant l’exécution des tests, et les correctifs étudiés étaient des candidats produits dans des conteneurs, et non du code fusionné dans ces projets.

La question utile pour un défenseur n'est pas de savoir quel camp croire. C'est de savoir ce que le chiffre mesure : 26 % de bogues délibérément difficiles dans des conditions d'information délibérément mixtes, ou 86 % d'essais exécutables où l'exploit fourni a été bloqué. Les deux chiffres proviennent du même ensemble de données, et ni l'un ni l'autre n'est une spécification d'achat. Ce sur quoi les deux parties s'accordent, c'est la mise en garde que 1Password imprime elle-même dans l'article — « un correctif généré est un candidat, pas la preuve que la vulnérabilité est corrigée » — et c'est la partie qui ne nécessite aucun arbitrage.