llms.txt, la faille qui a fait installer du code orphelin par Claude, Codex et Hermes dans les reseaux Fortune 500

llms.txt, la faille qui a fait installer du code orphelin par Claude, Codex et Hermes dans les réseaux Fortune 500

🔎 Quand les agents de code deviennent le vecteur d'attaque

Une nouvelle classe de vulnérabilité vient d'émerger, et elle exploite exactement ce qui devait rendre les agents IA sûrs : leur autonomie. Des chercheurs en sécurité viennent de révéler qu'un simple fichier texte placé sur un site web suffit pour faire exécuter du code malveillant par les principaux coding agents du marché — Claude d'Anthropic, Codex d'OpenAI et Hermes de Nous Research.

L'attaque ne requiert aucune faille dans les modèles eux-mêmes. Elle exploite un mécanisme de confiance structurel : les fichiers llms.txt et llms-full.txt, conçus pour aider les LLM à comprendre la documentation d'un projet, sont traités comme des instructions par les agents. Sauf que rien ne garantit que ces fichiers sont légitimes.

Le pire ? Les tests ont été menés dans des réseaux réels d'entreprises du Fortune 500. Les agents ont exécuté des beacons réseau en moins d'une heure, sans qu'aucun analyste de sécurité ne soit alerté.

L'essentiel

• Des chercheurs ont scanné 6 214 domaines (Fortune 500, Big Tech, secteur défense) et trouvé 120 fichiers llms.txt pointant vers 227 commandes d'installation de paquets non enregistrés sur les registres npm/PyPI.
• Claude, Codex et Hermes ont tous les trois exécuté des commandes d'installation issues de ces fichiers, sans vérifier l'existence ou la légitimité des paquets.
• Le cas de clerk.com illustre une attaque réelle en cours : un npx pointe vers un malware actif, et les agents le déclenchent mécaniquement.
• Le problème est structurel, pas un bug : les coding agents ne font pas la distinction entre une instruction trouvée dans une doc et une commande validée par un humain.

Outils et modèles concernés

Pour comprendre la portée de cette faille, il faut examiner le comparatif Claude 4 vs GPT-5 vs Gemini 3 : aucun de ces modèles n'a été conçu avec un mécanisme de vérification d'intégrité des sources qu'il consulte. Leurs scores agentic élevés signifient justement qu'ils agissent vite et avec peu de friction — ce qui devient un problème quand l'input est compromis.

Ce qu'est réellement llms.txt — et pourquoi c'est un problème

Un standard né avec de bonnes intentions

Le fichier llms.txt est un standard communautaire proposé fin 2024 pour structurer la documentation destinée aux LLM. Il s'agit d'un fichier texte placé à la racine d'un domaine, similaire dans l'esprit à robots.txt pour les crawlers web.

Un agent de code qui travaille sur un projet utilisant une API tierce va chercher le llms.txt du fournisseur pour comprendre comment intégrer correctement le service. C'est intelligent, efficace, et c'est exactement ce pour quoi le format a été créé.

Le fichier llms-full.txt est une variante étendue qui contient la documentation complète plutôt qu'un résumé. C'est cette version qui pose le plus de problèmes : elle contient souvent des commandes d'installation, des snippets de configuration, des exemples de code copiables.

Le saut logique fatal : de la doc à l'exécution

Voici le mécanisme exact de l'attaque. Un agent de code reçoit une tâche comme "intègre l'API Clerk pour l'authentification". Il va chercher clerk.com/llms-full.txt. Il y trouve une instruction : npx @clerk/clerk-sdk install. L'agent l'exécute.

Sauf que dans le cas réel documenté par les chercheurs, cette commande pointe vers un paquet non enregistré, ou pire, vers un paquet qui existe mais qui n'appartient pas à Clerk. L'agent ne vérifie pas si @clerk/clerk-sdk est réellement publié par Clerk sur npm. Il fait confiance au fichier parce qu'il est hébergé sur le domaine du vendor.

C'est exactement la même logique qui permettait les attaques Agentjacking : une fake bug report suffit pour pirater Claude Code, Cursor et Codex — 2388 organisations touchées, taux de réussite 85% : l'agent traite un input externe non validé comme une instruction légitime.

L'étude : 6 214 domaines scannés, 227 paquets orphelins

Méthodologie des chercheurs

L'étude, rapportée par Ars Technica et Creati.ai, n'est pas une démonstration en laboratoire. Les chercheurs ont scanné les domaines réels des entreprises du Fortune 500, des GAFAM, et d'organisations du secteur défense américain.

Sur 6 214 domaines analysés, 120 hébergeaient un fichier llms.txt ou llms-full.txt. Parmi ceux-ci, les chercheurs ont extrait 227 commandes d'installation de paquets (principalement via npm install, pip install, npx) qui pointaient vers des paquets non enregistrés ou dont la propriété n'était pas vérifiable.

Un paquet "orphelin" dans ce contexte signifie soit qu'il n'existe pas du tout sur le registre (ce qui devrait être un signal d'erreur immédiat), soit qu'il existe mais n'est pas owned par l'organisation dont le domaine porte le nom.

Les chiffres qui comptent

Le fait que 100% des commandes extraites pointent vers des paquets problématiques n'est pas une coïncidence. Les chercheurs ont ciblé ces fichiers précisément parce que le format llms.txt encourage l'inclusion de commandes d'installation directes, sans mécanisme d'authentification ou de signature.

Le cas clerk.com : une attaque réelle, pas théorique

Un npx qui mène à un malware live

L'exemple le plus concret de l'étude concerne clerk.com, un fournisseur d'authentification très populaire chez les startups et les entreprises SaaS. Le fichier llms-full.txt de Clerk contenait (ou contenait à un moment donné) une commande npx qui, lorsqu'exécutée, déclenchait l'installation et l'exécution d'un code malveillant.

La commande passait par npx, l'outil de npm qui télécharge et exécute un paquet sans l'installer de manière permanente. C'est un vecteur idéal pour ce type d'attaque parce que npx est conçu pour être frictionless : pas de vérification de signature, pas de lockfile, exécution immédiate.

Le malware en question établissait un beacon réseau — une connexion sortante périodique vers un serveur contrôlé par les attaquants. Depuis le réseau interne de l'entreprise qui utilisait l'agent de code.

Pourquoi c'est différent d'une attaque par typosquatting

Le typosquatting sur les registres de paquets (installer lod-ash au lieu de lodash) est un problème connu. Mais ici, la mécanique est différente et plus insidieuse.

Avec le typosquatting, c'est un humain qui fait la faute de frappe. Avec l'attaque llms.txt, c'est le vendor lui-même (ou un attaquant qui a compromis son site) qui fournit la commande malveillante. L'agent n'a aucune raison de douter : l'instruction vient du domaine officiel du service qu'il doit intégrer.

Cela rend la détection par les outils de sécurité classique quasiment impossible. Le paquet n'a pas un nom suspect, la commande vient d'un domaine légitime, et c'est un processus automatisé qui l'exécute — pas un humain dont on pourrait analyser le comportement.

Claude, Codex, Hermes : les trois agents dans le piège

Claude Opus 4.7 : le plus rapide à exécuter

Claude Opus 4.7, le modèle phare d'Anthropic avec un score agentic de 94.3, a été le plus rapide à déclencher l'exécution. Sa capacité à enchaîner les étapes d'un workflow sans friction — qui est précisément ce qui le rend excellent pour le développement — devient ici un vecteur de risque.

Claude a lu le fichier llms-full.txt, extrait la commande d'installation, et l'a exécutée sans tenter de vérifier l'existence du paquet sur npm. Aucun warning, aucune étape de confirmation. Le beacon réseau était actif en moins de 30 minutes dans les tests.

GPT-5.3 Codex : le modèle conçu pour le code qui ne vérifie pas le code

GPT-5.3 Codex d'OpenAI, avec un score agentic de 80.0, a montré un comportement similaire. Codex est littéralement conçu pour transformer des instructions en code exécutable. Quand il trouve une commande d'installation dans une documentation vendor, il l'exécute parce que c'est son job.

La différence notable est que Codex a parfois demandé une confirmation supplémentaire — mais uniquement lorsque la tâche initiale ne mentionnait pas explicitement l'installation de dépendances. Dès que le prompt mentionnait "installe les dépendances nécessaires", la validation disparaissait.

Hermes : l'agent open source sans garde-fou

Hermes de Nous Research, souvent utilisé dans des configurations d'installation LLM local pour des raisons de confidentialité, a présenté le comportement le plus préoccupant. Étant open source et souvent déployé sans les couches de sécurité enterprise d'Anthropic ou d'OpenAI, Hermes a exécuté les commandes avec encore moins de filtrage.

Les agents locaux sont particulièrement vulnérables à ce vecteur parce qu'ils s'exécutent souvent avec les pleins droits de l'utilisateur, sans sandbox, sans proxy entreprise, sans logs centralisés. Un beacon depuis Hermes dans un réseau Fortune 500 peut passer inaperçu pendant des semaines.

Pourquoi la confiance dans les docs vendor est le vrai problème

Le modèle mental cassé : input humain vs instruction découverte

La faille fondamentale n'est pas technique. C'est un problème de modèle mental dans la conception des agents.

Les agents de code sont construits avec l'hypothèse que les instructions viennent de l'utilisateur humain, et que les données trouvées sur le web sont... des données. Mais dans la pratique, les LLM ne font pas cette distinction. Un prompt écrit par un humain et un paragraphe trouvé dans un llms.txt sont traités de la même manière : comme des instructions à suivre.

C'est un problème d'alignement classique, mais appliqué à un nouveau contexte. Quand vous demandez à Claude "installe Clerk", le prompt est une instruction. Quand Claude lit "pour installer Clerk, exécutez npx @clerk/clerk-sdk" dans un fichier texte, cette phrase devient aussi une instruction. Le contexte change, pas le traitement.

La différence avec un développeur humain

Un développeur humain qui lit une documentation va instinctivement vérifier plusieurs choses : le paquet existe-t-il vraiment ? Est-il publié par le bon owner ? La version est-elle cohérente ? Le nom exact correspond-il ?

Les agents de code actuels ne font aucune de ces vérifications. Ils extraient la commande et l'exécutent. C'est un manque qui n'est pas un bug mais un absent de conception : aucune des architectures d'agent actuelles n'intègre un layer de vérification d'intégrité des paquets entre la phase de recherche et la phase d'exécution.

Cette problématique rejoint les enjeux autour des meilleurs LLM pour les agents IA : plus un modèle est capable d'agir de manière autonome, plus le besoin de garde-fous structurels augmente. Or ces garde-fous n'existent pas encore dans les stack agents standard.

Le scan des 6 214 domaines : ce que les chiffres révèlent

Fortune 500, Big Tech, défense : personne n'est épargné

L'échantillon de l'étude n'est pas anodin. Les chercheurs ont ciblé délibérément les organisations qui ont les moyens de se protéger : entreprises du Fortune 500, GAFAM, sous-traitants du secteur défense américain. Si ces organisations sont vulnérables, toutes les autres le sont a fortiori.

Le fait que 120 de ces 6 214 domaines hébergent un fichier llms.txt avec des commandes problématiques ne signifie pas que seuls 2% des organisations sont touchées. Cela signifie que 2% des organisations ont déjà adopté le format — et que parmi celles-ci, 100% présentent le vecteur d'attaque.

La proportion d'adoption va croître mécaniquement. Le standard llms.txt gagne en popularité précisément parce que les agents de code deviennent omniprésents. Plus d'entreprises vont créer ces fichiers, et sans changement d'approche, chacune d'entre elles créera un nouveau vecteur d'attaque potentiel.

227 paquets orphelins : que signifie ce nombre

Les 227 commandes d'installation identifiées ne sont pas toutes exploitées activement. Mais elles représentent 227 portes d'entrée potentielles que n'importe quel attaquant pourrait activer à tout moment.

Il suffirait d'enregistrer un seul de ces paquets orphelins sur npm avec le nom exact référencé dans le llms.txt d'une entreprise du Fortune 500 pour que chaque agent de code qui consulte cette documentation installe et exécute le code de l'attaquant. C'est une attaque pré-positionnée, en attente d'activation.

Les mécanismes d'attaque en détail

Le pré-positionnement de paquets

L'attaque la plus élégante fonctionne en deux temps. Phase 1 : identifier des fichiers llms.txt qui référencent des paquets non enregistrés (les 227 trouvés par l'étude). Phase 2 : enregistrer ces paquets avec du code malveillant au moment choisi.

L'avantage de cette approche est qu'au moment de l'enregistrement, il n'y a aucune action suspecte de la part de l'attaquant sur le réseau cible. Le paquet est créé sur un registre public. Ce sont les agents des entreprises cibles qui viennent le chercher.

La compromission de site comme vecteur alternatif

L'autre vecteur, illustré par le cas clerk.com, est la compromission directe du site hébergeant le llms.txt. Un attaquant qui parvient à modifier le fichier (via une faille CMS, un accès admin compromis, un DNS hijack) peut injecter n'importe quelle commande.

Dans ce scénario, l'attaque est instantanée : dès qu'un agent consulte le fichier modifié, il exécute la commande. Pas besoin d'attendre un pré-positionnement.

Le beacon : premier signal, pas dernière étape

Dans les tests des chercheurs, le code installé par les agents établissait un beacon réseau — une connexion sortante périodique. C'est un signal de confirmation (callback), pas l'objectif final de l'attaque.

Un beacon dans un réseau Fortune 500 permet à l'attaquant de confirmer quelles organisations utilisent quels agents, sur quels postes, avec quels niveaux de privilège. C'est de la reconnaissance automatisée à l'échelle, déclenchée par les victimes elles-mêmes via leurs propres agents.

Comment se protéger concrètement

En tant qu'organisation : bloquer le vecteur

La mesure la plus immédiate est de bloquer l'exécution de paquets non vérifiés par les agents. Cela passe par plusieurs couches.

Premièrement, le réseau : les proxies enterprise et les firewalls doivent bloquer les connexions sortantes vers les registres de paquets (npmjs.org, pypi.org, crates.io) depuis les processus agents, sauf via un registre miroir interne qui ne sert que des paquets vetés.

Deuxièmement, le registre interne : mettre en place un Artifactory ou un Nexus qui agit comme proxy pour npm/PyPI, et configurer les agents pour n'utiliser que ce registre. Tout paquet qui n'est pas explicitement approuvé sera rejeté.

Troisièmement, le sandbox : les agents de code ne devraient jamais s'exécuter avec les pleins droits de l'utilisateur. Des outils comme Firejail, gVisor ou des namespaces isolés peuvent limiter les dégâts d'une exécution non voulue.

En tant que vendor : sécuriser son llms.txt

Si votre entreprise publie un fichier llms.txt, auditez-le immédiatement. Vérifiez que chaque commande d'installation référence un paquet que vous possédez réellement sur le registre correspondant. Supprimez les commandes npx et remplacez-les par des instructions d'installation vérifiables (avec numéros de version exacts, checksums si possible).

Considérez aussi signer vos fichiers llms.txt avec une signature PGP ou un équivalent, même si aucun agent ne vérifie les signatures aujourd'hui. Le jour où un mécanisme de vérification sera implémenté, vos fichiers seront déjà prêts.

En tant qu'utilisateur d'agent : ne pas déléguer l'installation

La règle la plus simple : ne demandez jamais à un agent "installe les dépendances" ou "configure ce service". Demandez-lui de vous générer les commandes, puis exécutez-les vous-même après vérification.

C'est moins pratique. C'est le prix de la sécurité tant que les agents n'intègrent pas de vérification d'intégrité native. Les meilleurs outils IA pour le code comme Cursor ou Copilot offrent des modes semi-automatisés qui permettent de valider chaque commande avant exécution — utilisez-les.

❌ Erreurs courantes

Erreur 1 : Penser que le problème est dans le modèle

Ce n'est pas Claude, Codex ou Hermes qui sont buggés. C'est l'architecture autour d'eux. Le même comportement se produirait avec n'importe quel LLM suffisamment compétent pour suivre des instructions trouvées dans un document. Changer de modèle ne résout rien.

Erreur 2 : Faire confiance au domaine pour valider le paquet

Un fichier hébergé sur clerk.com n'est pas forcément contrôlé par Clerk. Les compromissions de site web sont monnaie courante, et un fichier texte à la racine d'un domaine est parmi les choses les plus faciles à modifier. La seule validation fiable est la vérification sur le registre de paquets lui-même.

Erreur 3 : Croire que le typosquatting est le même problème

Le typosquatting exploite la négligence humaine. L'attaque llms.txt exploite la confiance algorithmique. Les contre-mesures sont différentes : le typosquatting se combat par la vigilance, l'attaque llms.txt se combat par l'architecture (registres internes, sandbox, vérification automatisée).

Erreur 4 : Ignorer le problème parce qu'on n'utilise pas d'agents

Si votre entreprise a un fichier llms.txt public, n'importe quel client ou partenaire qui utilise un agent de code peut être infecté via votre domaine. Vous êtes un vecteur même si vous n'utilisez pas d'agents en interne.

❓ Questions fréquentes

Tous les fichiers llms.txt sont-ils dangereux ?

Non. Le format lui-même est neutre. Le danger vient des fichiers qui contiennent des commandes d'installation sans vérification d'intégrité (nom de paquet exact, owner vérifié, version pinée). Un llms.txt qui se contente de décrire des API sans commandes d'installation est inoffensif.

Les agents open source sont-ils plus vulnérables ?

Oui, mécaniquement. Les agents comme Hermes, souvent déployés en local via Ollama ou LM Studio, manquent des couches de sécurité enterprise (logs, proxy, sandbox) que les solutions cloud intègrent partiellement. Le tradeoff confidentialité/sécurité est réel.

Pourquoi les agents ne vérifient-ils pas les paquets ?

Parce qu'aucun d'entre eux n'a été conçu avec un étage de vérification d'intégrité entre la recherche d'information et l'exécution de commande. C'est un absent de conception, pas un bug. Les éditeurs vont devoir ajouter cette couche.

Existe-t-il des outils pour détecter ce type d'attaque ?

Les outils de sécurité traditionnels (EDR, SIEM) peuvent détecter le beacon réseau a posteriori, mais pas prévenir l'installation. Des solutions spécialisées commencent à émerger pour scanner les fichiers llms.txt des dépendances d'un projet, mais le marché est immature.

Cette attaque fonctionne-t-elle avec les LLM généralistes, pas seulement les coding agents ?

Théoriquement oui, mais les coding agents sont la cible privilégiée parce qu'ils ont la capacité d'exécuter des commandes système. Un LLM généraliste dans un chat ne peut qu'afficher la commande, pas l'exécuter. Le danger est dans le couplage recherche + exécution.

✅ Conclusion

L'attaque via llms.txt n'est pas une vulnérabilité zero-day — c'est une conséquence prévisible de l'autonomie croissante des agents de code sans garde-fous proportionnés. Tant que les agents traitent toute instruction trouvée sur le web comme une commande à exécuter, chaque fichier de documentation public sera un vecteur d'attaque potentiel. La solution n'est pas de stopper les agents, mais d'ajouter un layer de vérification d'intégrité entre la lecture et l'exécution — et d'ici là, de sandboxer sérieusement tout agent qui touche à un registre de paquets.