Comment les fichiers publics llms.txt permettent aux chercheurs d’exécuter du code au sein des grandes entreprises

Lorsqu’un fichier publié devient une commande

Une équipe de recherche en sécurité a rapporté qu’une machine au sein d’une entreprise du Fortune 500 exécutait du code qu’ils avaient publié, et que cela s’est produit environ quatre minutes après la mise en ligne du code. Deux autres appels sont survenus au cours de l’heure suivante. Selon eux, personne n’a exploité de CVE, n’a effectué de phishing sur un employé ni n’a touché au périmètre du réseau. Les chercheurs ont identifié quelques noms de fichiers officiels, diffusés via HTTPS par les entreprises elles-mêmes, qui indiquaient déjà aux agents d’intelligence artificielle de les utiliser.

Ces fichiers étaient publics et leurs noms n’avaient pas été réclamés. Les agents ont fait exactement ce pour quoi ils avaient été conçus. La même équipe affirme également qu’en scannant ces fichiers à grande échelle, ils sont tombés sur une attaque déjà en cours : un fichier d’instructions d’un fournisseur qui orientait les agents vers du code malveillant confirmé. Ce cas est présenté ci-dessous.

D’abord, les informations de contexte.

Pourquoi llms.txt est important ici

Pendant la majeure partie de l’histoire du Web, une page sur un site n’était qu’une simple page. Quelqu’un pouvait la lire, un robot de recherche pouvait l’indexer, mais personne ne la considérait comme une commande. Cela n’est plus le cas.

Aujourd’hui, les entreprises placent un nouveau type de fichier à la racine de leurs sites, à côté de robots.txt : llms.txt, et parfois un fichier plus long appelé llms-full.txt. Il ne s’agit ni d’un plan du site ni d’une notice légale. Il fonctionne comme un ensemble organisé de directives destinées aux agents IA, indiquant ce qu’il faut lire, quelles API appeler, quels paquets installer et quels domaines faire confiance. Les laboratoires de grands modèles publient les leurs, et l’outil Lighthouse de Google dans Chrome DevTools dispose désormais d’une vérification sous « agentic browsing » qui incite les sites à en fournir un. Le nombre de ces fichiers ne cesse d’augmenter.

L’équipe s’est efforcée de déterminer dans quelle mesure cette couche d’instructions s’était répandue. Leur comptage : 8 565 fichiers llms.txt sur 6 214 domaines en ligne, parmi environ 15 000 entreprises cataloguées. Parmi les éditeurs figuraient de grandes entreprises, des géants technologiques, des startups du secteur financier et des fournisseurs de services de défense.

Un fichier typique renvoie un agent vers la documentation, un journal des modifications et un forum communautaire, puis vers une ligne d’installation, similaire à pip install pour le SDK de l’entreprise. Ce contenu semble utile et officiel, et provient du domaine propre à l’entreprise via HTTPS. Un agent de codage IA qui souhaite s’intégrer à ce produit lira cette ligne et la mettra en œuvre.

La question suivante était presque embarrassamment simple : qui possède réellement ce nom de package sur PyPI ? Dans tous les cas, la réponse était personne. Ce nom figurait dans un fichier officiel de l’éditeur, et le package qu’il désignait n’avait jamais été réclamé. Qui arrive en premier, sert en premier.

Les chercheurs ont vérifié quelques autres fichiers, puis des centaines, puis la plupart d’entre eux, et ont constaté la même chose partout. Les instructions d’installation mentionnaient des packages et des domaines que personne n’avait enregistrés. Selon eux, il ne s’agissait pas de systèmes « potentiellement vulnérables », mais simplement de ressources disponibles. Ce n’était pas non plus du typosquatting. Les noms dans les fichiers étaient orthographiés correctement, il n’y avait donc aucune faute d’orthographe à détecter, car les enregistrements n’avaient jamais eu lieu.

Comment du code a fini par s’exécuter au sein de grandes entreprises

L’équipe a sélectionné un petit ensemble de noms de paquets présents dans les fichiers llms.txt d’entreprises bien connues et les a enregistrés sur PyPI et npm. Chaque paquet contenait un mécanisme de retour inoffensif, une balise minimale indiquant qu’une installation avait eu lieu sur l’infrastructure contrôlée par les chercheurs. Ensuite, ils ont attendu.

Le premier appel de retour est arrivé en moins de quatre minutes. Plus précisément, quelque part au sein d’une entreprise valant plusieurs centaines de milliards de dollars, un agent IA avait lu le fichier llms.txt sur le site de l’entreprise, trouvé une ligne pip install et l’avait exécutée. Le paquet provenait bien de PyPI, comme indiqué dans le fichier, mais il s’agissait en réalité du paquet des chercheurs. Le deuxième appel de retour, émanant d’une entreprise du classement Fortune 500, est arrivé en une heure, suivie de quelques dizaines d’autres provenant à la fois de startups et d’entreprises, certaines disposant d’équipes de sécurité plus importantes que l’ensemble du réseau professionnel des chercheurs.

Leur conclusion est qu’ils n’ont pas contourné la sécurité de qui que ce soit, mais ont abusé d’une chaîne de confiance.

Comment les agents découvrent ces fichiers par eux-mêmes

L’expérience a ensuite cherché à déterminer à quel point peu d’indications étaient nécessaires. Les chercheurs ont testé cinq configurations différentes sur deux interfaces CLI agnitives, leur ayant donné la même phrase 100 fois, sans y inclure rien d’autre que le nom d’un fournisseur. La phrase demandait à l’agent d’utiliser tous les documents de ce fournisseur pour créer et exécuter un projet Node.js avec son SDK.

C’était toute l’instruction. Elle ne contenait aucune URL, aucun lien vers de la documentation et aucune mention de llms.txt. Il n’y avait ni injection d’instruction, ni attaquant impliqué, ni ingénierie sociale. L’agent a trouvé le canal d’instructions par lui-même, car retrouver la documentation officielle d’un fournisseur est précisément à cela qu’il a été conçu. L’équipe a compté combien des 100 exécutions par configuration ont fait appel à llms.txt, a vu la commande et a installé un paquet que personne n’avait enregistré.

Ces paquets étaient inactifs par conception, ne servant qu’à émettre un signal. Tout ce qui s’était produit jusqu’alors relevait de recherches contrôlées. Ce qui suit concerne un incident distinct découvert lors de l’analyse du corpus.

Un cas déjà présent dans le monde réel

Une découverte a stoppé net l’équipe, car cela se produisait déjà.

Clerk, un fournisseur d’authentification dont les SDK sont utilisés dans de nombreuses applications Next.js en production, publie une documentation destinée aux agents IA. Un agent qui suit cette piste accède au guide llms.txt de Clerk contenant des solutions pour la protection par authentification, lequel inclut cette commande :

npx clerk-next-fix-auth-protection

L’agent lit ce texte et l’exécute, ce qui n’est pas vraiment surprenant pour des instructions provenant directement du fournisseur.

Le problème ne réside pas dans un nom de package mal orthographié. La commande brute clerk-next-fix-auth-protection est le binaire fourni à l’intérieur du package ciblé de Clerk, @clerk/eslint-plugin. La documentation indique aux agents d’installer d’abord ce package ciblé avant d’appeler la commande brute. Cependant, si cette commande est exécutée avant que le package ne soit installé localement, npx cherche son nom dans le registre public npm, où Clerk ne l’a jamais publié en tant que package indépendant.

Quelqu’un d’autre l’a enregistré à sa place. D’après la description des chercheurs, le paquet ne contient aucun code fonctionnel, mais dès son installation, il déclenche des mécanismes qui envoient le nom d’utilisateur de l’installateur, le nom de la machine, le répertoire de travail ainsi qu’une date et heure à un serveur externe à chaque installation. Il est catalogué sous le nom MAL-2026-11069 selon la classification CWE-506, code malveillant intégré, et a été signalé par OSV.dev de Google ainsi que par Amazon Inspector. La documentation, la fenêtre d’exécution ouverte et l’exécution automatique resteraient identiques que le payload récupère un nom d’utilisateur ou dépose une backdoor complète. Le mécanisme de distribution constitue la vulnérabilité, tandis que le payload n’est qu’un choix parmi plusieurs options.

Cette recherche a été communiquée à l’équipe de sécurité de Clerk, qui a réagi rapidement et a résolu le problème. Le rapport souligne qu’il ne s’agit en aucun cas d’une critique envers Clerk. Un tiers a enregistré le paquet en abusant de la confusion des noms liés à npx, et Clerk n’avait aucun contrôle sur cela. L’équipe présente ce cas comme un exemple confirmé de problème structurel qui concerne tout fournisseur publiant des documents lisibles par des agents.

Pourquoi les contrôles actuels ne détectent pas cela

Tous les signaux sur lesquels repose une configuration de sécurité indiquent ici la mauvaise direction. Un agent qui rencontre un fichier llms.txt voit un fichier servi via HTTPS depuis le domaine officiel, dans un format standard destiné à être utilisé par des systèmes d’intelligence artificielle, publié par l’entreprise ou par un partenaire en qui elle a confiance. L’agent a peu de raisons de douter de quoi que ce soit, car le fichier est conçu pour être la source d’autorité.

Lorsque le fichier indique d’installer un outil ayant l’air interne, l’agent ne s’arrête pas pour vérifier si le nom appartient à l’entreprise. Il n’examine pas l’espace de noms PyPI, et il ne remarque pas non plus qu’un lien vers la documentation mène à un domaine dont l’enregistrement a expiré il y a trois mois. Il fait simplement ce que dit le fichier.

La confiance est également transitive. Le fichier llms.txt n’a pas besoin d’être hébergé sur le site de l’entreprise cible. Les agents tirent du contexte de tiers fiables tels que les documents d’un partenaire, la référence SDK d’un fournisseur ou la page de configuration d’un projet communautaire. Si l’agent fait confiance à ce tiers et que le fichier de ce dernier pointe vers un paquet non réclamé, la chaîne fonctionne de la même manière.

La détection d’endpoint n’a pas non plus émis de signal. Pour un outil EDR ou un proxy, cela ressemble à un développeur qui exécute un gestionnaire de paquets légitime : une commande pip install vers pypi.org, un domaine autorisé par tout proxy d’entreprise, avec un agent de codage déployé intentionnellement par l’entreprise en tant que processus parent. Il n’y a ni anomalie ni alerte. L’échec se situe en amont, dans l’écart entre l’instruction et son exécution, et l’endpoint ne peut pas le détecter car on ne lui a jamais posé la bonne question.

Données transformées en code

Pendant des décennies, les contenus étaient consommés par les gens. Aujourd’hui, ce sont souvent des agents d’IA qui les lisent en premier, les interprètent et y agissent. C’est l’erreur de catégorie dans laquelle l’industrie s’est engagée ensemble : la frontière entre les données et le code a disparu. Tout ce qui se trouve sur votre site n’est plus simplement du contenu ; c’est une entrée opérationnelle, en réalité du code exécuté dans l’environnement d’autrui avec les privilèges que possède l’agent.

Cela renverse une ancienne hypothèse. Les pages et les documents étaient considérés par défaut comme à faible risque, car personne ne les traitait comme des éléments exécutables, ce qui faisait qu’aucun budget n’était alloué à leur intégrité. Lorsque les données deviennent du code, l’intégrité des données devient une ligne budgétaire au sein de la sécurité.

Mieux qu’un simple fichier

llms.txt n’est pas l’ensemble de la surface d’attaque. C’est la première fissure indiquant que le sol a bougé. Chaque surface à laquelle un agent est connecté devient un endroit où des instructions peuvent arriver, et aucun de ces endroits n’a été conçu avec des contrôles d’intégrité.

Pensez à ce qu’un agent reçoit réellement : des dépôts officiels de GitHub, de la documentation, des communautés et des forums, vos tickets ainsi que votre courrier électronique. Pendant vingt ans, il s’agissait de contenus écrits pour les humains, et personne n’a mis en place de contrôles d’intégrité car ces contenus ne pouvaient rien faire. Ce monde a disparu. L’ensemble des données auxquelles les agents sont connectés est devenu silencieusement une surface d’exécution.

Le véritable sujet n’est ni un fichier ni un registre. Les données elles-mêmes ont changé de nature, et l’industrie de la sécurité est encore en train de rattraper son retard.

Les chiffres derrière la recherche

• Taille du corpus : 8 565 fichiers llms.txt provenant de 6 214 domaines actifs, sélectionnés parmi une liste d’environ 15 000 entreprises.
• Six écosystèmes ont été touchés : PyPI, npm, RubyGems, NuGet, crates.io et Packagist. Du côté des domaines, il s’agit de noms .dev et .io expirés ainsi que de sous-domaines orphelins sur Render, Vercel, Fly et Netlify, tous accessibles.

Que peuvent en tirer les défenseurs

Les chercheurs décrivent llms.txt comme seulement le premier fil qu’ils ont exploré, et prévoient l’apparition de davantage de modes de défaillance. Voici quelques implications pratiques issues de leurs constatations :

• Vérifiez vos propres fichiers destinés aux agents. Chaque nom de package, domaine et sous-domaine qu’ils mentionnent doit être enregistré, géré et surveillé.
• Exécutez les commandes indiquées dans la documentation en utilisant le nom de package spécifié. Un simple nom binaire peut être résolu via un registre public si l’installation locale n’a pas eu lieu.
• Considérez les documents de tiers que vos agents consultent comme faisant partie de la chaîne d’approvisionnement, car la confiance provient d’eux.
• N’oubliez pas que les outils standard de gestion des points d’accès ne détectent qu’une installation normale de package et ne la signaleront pas ; par conséquent, les contrôles doivent être mis en place plus tôt, lors des instructions et de la recherche dans le registre.

Selon l’énoncé de divulgation, aucun dommage n’a été causé lors de l’expérience. Aucune donnée persistante n’a été déployée, aucune information n’a été extraitée ; les résultats sont communiqués de manière responsable aux organisations concernées, et les noms des entreprises restent confidentiels tant que les correctifs sont en cours.