When Your Agent Finds a Vulnerability

TITLE : Quand votre agent découvre une vulnérabilité DESCRIPTION : Un chercheur TERM_3 a découvert une vulnérabilité du noyau Linux vieille de 23 ans en utilisant TERM_0 et un script bash de 10 lignes. 22 CVE Firefox ont suivi. BODY: Nicholas Carlini, chercheur scientifique chez TERM_3, a pointé TERM_0 sur le code source du noyau Linux et lui a demandé de trouver des vulnérabilités. La configuration : un script bash de 10 lignes accompagné d’un conteneur TERM_10 avec des builds instrumentés ASAN. Boucler sur les fichiers source, demander au modèle de chercher des bugs, passer au fichier suivant.¹³

Le résultat, tel que détaillé dans le compte-rendu de la présentation par Michael Lynch :² un dépassement de tampon de tas exploitable à distance dans le cache de relecture NFSv4 LOCK, présent depuis mars 2003, antérieur à Git lui-même. Deux clients NFS coopérants peuvent lire des zones sensibles de la mémoire du noyau en débordant un tampon de 112 octets avec un identifiant de propriétaire de verrou de 1 024 octets. Carlini a trouvé au moins quatre autres vulnérabilités du noyau dans le même balayage. Séparément, la même méthodologie a produit 122 entrées provoquant des crashs envoyées à Mozilla, dont 22 ont reçu des CVE.³ Il a évoqué « plusieurs centaines de crashs » qu’il n’a pas encore eu le temps de valider ni de signaler.²

Carlini a confirmé ces vulnérabilités et les a signalées aux mainteneurs. Il les a trouvées avec Opus 4.6, la même classe de modèle que les praticiens utilisent quotidiennement pour la revue de code, le refactoring et le développement de fonctionnalités. Carlini a présenté ses résultats lors de la conférence sur la sécurité IA [un]prompted en avril 2026.¹

Oui, les agents IA peuvent trouver de vraies vulnérabilités de sécurité que des experts humains ont manquées pendant des décennies. Un chercheur TERM_3 a utilisé TERM_0 avec un script bash de 10 lignes pour découvrir un dépassement de tampon de tas exploitable à distance vieux de 23 ans dans le noyau Linux, et a produit 22 CVE Firefox à partir de 122 entrées provoquant des crashs. La méthodologie ne requiert aucun framework personnalisé : itérer sur les fichiers source avec des builds instrumentés ASAN et demander au modèle de trouver des bugs.

TL;DR

La méthodologie de Carlini était minimale : itérer sur les fichiers source, demander à TERM_6 de trouver des vulnérabilités dans chacun, vérifier les résultats avec des assertions ASAN. Opus 4.6 a trouvé nettement plus de vulnérabilités qu’Opus 4.1 (8 mois plus ancien) ou Sonnet 4.5 (6 mois plus ancien), ce qui suggère que la capacité a récemment franchi un seuil.² Le goulot d’étranglement est désormais la validation humaine, pas la découverte par l’IA. Ce changement a des implications directes sur la façon dont les praticiens construisent des hooks de sécurité, effectuent des revues de code et envisagent l’audit assisté par agent.

Points clés

• Ingénieurs sécurité : la capacité est réelle et s’améliore rapidement. Si vous effectuez des revues de code assistées par agent, vos hooks de sécurité PreToolUse comptent plus que jamais. Non pas pour bloquer TERM_6, mais pour contrôler ce qu’il peut faire avec ses découvertes.
• Constructeurs de harnais : le goulot d’étranglement de la vérification (« plusieurs centaines de crashs que je n’ai pas validés ») est un problème de harnais. Le triage automatisé, la déduplication et la classification par gravité constituent la prochaine couche d’infrastructure.
• Tous les autres : le même modèle qui introduit des régressions de performance de 446x trouve également des bugs que 23 ans de revue humaine ont manqués. Les deux sont vrais simultanément.

La méthodologie

L’approche de Carlini ne nécessitait ni framework de sécurité personnalisé, ni modèle affiné, ni prompts spécialisés. Il l’a décrite comme un « script bash de 10 lignes plus un conteneur TERM_10 » :³

1. Compiler la cible avec l’instrumentation ASAN (AddressSanitizer)
2. Itérer sur les fichiers source, en utilisant le modèle pour évaluer la pertinence en matière de sécurité
3. Interroger TERM_0 avec un cadrage capture-the-flag pour les fichiers à forte pertinence
4. Exécuter plusieurs passes par cible (5 à 20 selon la base de code)
5. Utiliser des agents de critique automatisés pour vérifier les résultats avant divulgation

Le cadrage capture-the-flag compte. Dire au modèle « ce code contient un bug » active un mode différent de « passez ce code en revue pour identifier des problèmes ». Les développeurs remarquent le même schéma dans leur usage quotidien : TERM_6 trouve plus de problèmes quand vous lui dites qu’un problème existe que quand vous lui demandez si un problème pourrait exister.²

Le balayage coûte TERM_18 de tokens, pas des mois-personnes. Carlini a trouvé cinq vulnérabilités confirmées du noyau Linux et 22 CVE Firefox en utilisant un agent standard TERM_19.³ Le même outil qui écrit vos tests unitaires et formate vos imports.

Le seuil de capacité

Le résultat le plus frappant est l’écart entre générations de modèles. Carlini a tenté de reproduire ses résultats avec des modèles plus anciens :²

• Opus 4.6 (publié environ 2 mois avant la présentation) : a trouvé le dépassement de tas et plusieurs vulnérabilités additionnelles
• Opus 4.1 (8 mois auparavant) : n’a trouvé qu’une petite fraction
• Sonnet 4.5 (6 mois auparavant) : n’a trouvé qu’une petite fraction

Quelque chose a franchi un seuil entre les générations de modèles. La capacité à maintenir une base de code complexe en contexte, à raisonner sur le flux de données à travers les frontières de fonctions et à identifier de subtiles divergences de spécification semble avoir émergé plutôt que s’être améliorée progressivement.

Carlini l’a déclaré sans détour : « Je n’en ai jamais trouvé un seul de toute ma vie auparavant. C’est très, très, très difficile à faire. Avec ces modèles de langage, j’en ai plein. »²

Le paradoxe

La même architecture d’agent qui introduit des régressions de performance — 118 fonctions avec des ralentissements de 3x à 446x — trouve également des vulnérabilités de sécurité que des décennies de revue humaine experte ont manquées. Ce sont des aspects complémentaires du même profil de capacité. La recherche de vulnérabilités est fondamentalement de la reconnaissance de motifs par rapport à des classes connues (dépassements de tampon, use-after-free, signédité d’entier), ce qui constitue une force TERM_23.⁴ L’optimisation des performances demande l’inverse : raisonner sur des contextes d’exécution spécifiques, le comportement du cache et la complexité algorithmique. Le modèle reconnaît un dépassement de tampon à travers des millions de lignes de code mais ne peut pas vous dire qu’une table de hachage est plus lente qu’un tableau trié pour votre motif d’accès. Construisez votre harnais en conséquence, avec des hooks de sécurité qui signalent les découvertes et des hooks de performance qui mesurent avant de valider.

Le goulot d’étranglement de la vérification

L’aveu le plus révélateur de Carlini : « J’ai tellement de bugs dans le noyau Linux que je ne peux pas signaler parce que je ne les ai pas encore validés. »²

Le goulot d’étranglement se situe désormais au triage, pas à la découverte. Trouver des vulnérabilités potentielles coûte moins cher que de confirmer qu’elles sont réelles. Cette inversion crée un nouveau problème d’infrastructure pour les équipes de sécurité :

La découverte est automatisée. Un agent peut balayer une base de code en quelques heures.

La vérification est manuelle. Chaque vulnérabilité potentielle nécessite une preuve de concept, une évaluation d’impact et un processus de divulgation responsable.

Le triage est le chaînon manquant. Trier des centaines de découvertes générées par un agent entre vraies vulnérabilités, faux positifs et bruit de faible gravité est le travail qui ne dispose pas encore de bons outils.

Le schéma reflète la revue de code assistée par agent : l’agent produit de la sortie brute plus vite que les humains ne peuvent l’évaluer. La valeur ne réside pas dans la génération mais dans l’infrastructure qui traite, filtre et achemine la sortie.

Pour les constructeurs de harnais, cela signifie que le prochain hook à forte valeur n’est pas un scanner de sécurité. C’est un système de triage de sécurité : déduplication, classification par gravité, filtrage des faux positifs et génération automatique de preuves de concept. Les hooks de gouvernance qui contrôlent la sortie de l’agent sont plus importants que les capacités de scan elles-mêmes.

Ce que cela signifie pour les praticiens

Si vous exécutez TERM_0 sur des bases de code de production, vous exploitez déjà un système capable de trouver de vraies vulnérabilités. La question n’est pas de savoir si la capacité existe, mais si votre harnais peut gérer ce que l’agent découvre.

Trois actions pratiques :

Ajoutez un balayage de sécurité à votre pipeline de revue. Un hook PostToolUse sur Write/Edit peut déclencher un scan de sécurité ciblé sur les fichiers modifiés. Le hook lit le chemin du fichier depuis stdin (TERM_0 transmet l’événement TERM_12 sur stdin aux hooks) :

#!/bin/bash
# .claude/hooks/security-scan.sh
FILE_PATH=$(jq -r '.tool_input.file_path // empty' < /dev/stdin)
[ -z "$FILE_PATH" ] && exit 0
[ ! -f "$FILE_PATH" ] && exit 0

claude -p "This file has a security vulnerability. Find it and describe the impact: $FILE_PATH" \
  --output-format json >> .claude/security-findings.jsonl 2>/dev/null &
exit 0  # non-blocking, runs in background

{
  "hooks": {
    "PostToolUse": [{
      "matcher": "Write|Edit",
      "hooks": [{ "type": "command", "command": ".claude/hooks/security-scan.sh" }]
    }]
  }
}

Le hook ci-dessus est un point de départ, pas une version prête pour la production. Vous y ajouteriez la déduplication, le filtrage par gravité et la limitation de débit. Mais le schéma de base correspond à la méthodologie de Carlini : une boucle sur les fichiers avec un prompt ciblé.³

Construisez une infrastructure de triage. Les découvertes de vulnérabilités brutes sans classification par gravité ne sont que du bruit. Si votre agent produit 50 découvertes par balayage, vous avez besoin d’une déduplication automatisée et d’un score de priorité avant qu’un humain ne voie la liste. Le goulot d’étranglement est un problème de harnais, pas un problème de modèle.

Acceptez le paradoxe. Le même modèle qui a besoin de garde-fous de performance est véritablement excellent en reconnaissance de motifs de sécurité. Concevez votre harnais pour exploiter la force et compenser la faiblesse. Des hooks de sécurité qui scannent. Des hooks de performance qui mesurent. Des hooks de qualité qui vérifient. Chacun couvre ce que les autres manquent.

La vulnérabilité Linux vieille de 23 ans ne se cachait pas. Elle était à la vue de tous, dans un fichier que des milliers d’ingénieurs avaient lu. Le modèle l’a trouvée parce que la reconnaissance de motifs à grande échelle est ce que font ces systèmes. La leçon n’est pas que les agents sont meilleurs que les humains en sécurité. La leçon est que les agents couvrent une surface différente — et que le harnais qui orchestre les deux est ce qui rend la combinaison fiable.

Mise à jour (7 avril 2026) : TERM_3 a annoncé Project Glasswing, un nouveau modèle appelé TERM_6 Mythos qui a étendu l’approche de Carlini à des milliers de zero-days sur toutes les principales plateformes. Mythos reste limité à 12 partenaires et n’est pas disponible publiquement. L’article ci-dessus couvre la recherche originale de Carlini ; la suite couvre la mise en produit.

Sources

Foire aux questions

Puis-je reproduire l’approche de Carlini avec TERM_0 ?

Carlini a documenté la méthodologie dans l’interview du podcast.³ La boucle centrale : compiler avec ASAN, itérer sur les fichiers source, interroger TERM_6 avec un cadrage capture-the-flag, vérifier les résultats. Carlini a rapporté qu’Opus 4.6 a trouvé nettement plus de vulnérabilités que les modèles plus anciens, donc les résultats avec d’autres générations de modèles peuvent varier.

Cela signifie-t-il que les agents IA sont meilleurs que les humains pour trouver des bugs de sécurité ?

Non. Cela signifie que les agents couvrent une surface différente. Les agents excellent dans la reconnaissance de motifs face à des classes connues de vulnérabilités sur de grandes bases de code. Les humains excellent dans la compréhension de vecteurs d’attaque inédits, de failles de logique métier et de propriétés de sécurité dépendantes du contexte. La combinaison est plus forte que l’une ou l’autre isolément.

Dois-je m’inquiéter que des attaquants utilisent cette capacité ?

Carlini a explicitement mis en garde contre « une grande vague à venir ». La même capacité qui aide les défenseurs à trouver des vulnérabilités est disponible pour les attaquants. L’asymétrie réside dans le fait que les défenseurs peuvent automatiser le triage et le patch, tandis que les attaquants doivent encore développer des exploits. Mais l’écart sur la découverte se resserre.