Le fichier llms.txt est une innovation récente visant à communiquer avec les IA générative, mais elle poserait un risque important en matière de sécurité. Nous avons donc cru bon vous expliquer la nature de cette menace.
Imaginez une phrase que vous n’avez jamais écrite et qui est publiée sur votre propre domaine. Aucun client ne la lira jamais, mais n’importe quel assistant IA la répétera comme un fait. Il peut s’agir d’une ligne de support qui appelle un attaquant. Dans d’autres cas, ce sera plutôt outil « obligatoire » appartenant à quelqu’un d’autre, ou encore un ensemble de serveurs de noms qui ne sont pas les vôtres. Toutes ces menaces font parties des conséquences potentielles du risque apporté par le fichier llms.txt d’un site web.
Implanter cette phrase ne nécessite aucune violation de vos serveurs ni aucune ligne de code malveillant. Il faut simplement modifier un fichier de confiance silencieux, que la plupart des entreprises ont oublié de publier. Pire encore, d’après un récent audit, si ce fichier est installé, aucun mécanisme de l’hébergeur moyen ne le surveille. Il n’est pas analysé par le moindre scanner, moniteur de disponibilité, vérificateur humain ou même une signature.
Sur les 110 domaines de l’industrie de l’hébergement recensés qui servent le fichier, aucun ne comporte un contrôle qui remarquerait qu’il a changé. Le fichier conçu pour rendre une entreprise lisible par les machines en est donc un que personne ne garde. Il repose pourtant sur une infrastructure de confiance dont les agents d’IA répètent les mots comme s’ils étaient propres à l’entreprise. On peut donc s’inquiéter de cette vulnérabilité totalement ignorée par l’industrie.
Une vaste étude expose le risque potentiel associé au fichier llms.txt
Une récente analyse a audité la posture de crawl par l’IA de 736 sociétés d’hébergement et d’infrastructure. Les chercheurs ont constaté, dans un recensement distinct, que 110 d’entre elles publient un fichier sur /llms.txt. Il s’agit d’un catalogue en langage clair écrit pour les agents d’IA et les robots, qui le lisent et agissent en conséquence
L’industrie de l’hébergement a mis en place un nouveau canal de contenu avec trois propriétés qui ne devraient pas coexister : les machines le consomment et le reproduisent à l’identique, les humains ne le regardent jamais et il n’existe aucun modèle de sécurité nulle part pour sa surveillance.
La spécification ne contient aucune sécurité, intégrité ou disposition d’authentification. Il n’y a pas non plus de travail de normalisation adjacent de l’IETF. On ne trouve rien non plus dans la pile de sécurité WordPress, où aucun fournisseur majeur ne documente une surveillance du contenu llms.txt.
L’étude n’a rien découvert sur les 110 domaines eux-mêmes. Aucun ne signe le fichier, et seulement huit l’indiquent. 28 d’entre eux ne l’ont jamais écrit du tout, parce qu’un plugin SEO l’a fait.
À l’heure actuelle, il n’existe aucun cas documenté d’altération malveillante du fichier llms.txt. Cela ne signifie pas que l’industrie n’a rien à craindre. Chaque composant de l’attaque a déjà été démontré séparément, et le fichier se trouve sur des domaines d’infrastructure-industrie de confiance dont les assistants d’IA répètent le mot comme un fait. La menace est donc déjà bien réelle.
Le fichier llms.txt: Un canal de confiance sans modèle de sécurité
La convention llms.txt existe depuis 21 mois. Jeremy Howard de Answer.AI l’a proposé le 3 septembre 2024 à titre gracieux pour les modèles linguistiques.
Il s’agit d’un index concis selon un chemin bien connu. Celui-ci indique à un système d’IA ce qu’est un site et où se trouve sa documentation lisible par machine. Cette approche est similaire à la façon dont robots.txt indique aux bots où ne pas aller et dont sitemap.xml leur dit ce qui existe.
La proposition est élégante, utile et fait 11 kilo-octets de long. Elle ne contient toutefois aucune occurrence de « sécurité », « intégrité », « signature », « authentification », « désinfecter », « falsifier » ou « vérifier » d’une quelconque manière sur le plan de la sécurité. Cette lacune représente donc une vulnérabilité pour l’intégrité des données inclues dans le fichier.
Aucun mécanisme de vérification n’est en place
Il n’y a actuellement aucun modèle de confiance ni de mécanisme de provenance. Aucune orientation n’existe sur qui peut être écrit le fichier ou comment un consommateur pourrait vérifier qu’il est authentique.
La même chose est vraie au niveau du groupe de travail sur les préférences en matière d’IA de l’IETF, qui est ce qui se rapproche le plus d’un processus normalisé dans cet espace.
Il consiste à rédiger un vocabulaire pour exprimer les préférences d’utilisation. Son projet principal indique clairement qu’il « ne prévoit aucun mécanisme d’application » Le groupe ne cherche qu’à s’assurer que les préférences sont comprises. Il régit l’expression des droits, pas l’intégrité du contenu.
La portée réelle du fichier est toutefois remise en question, à l’heure actuelle. John Mueller de Google a comparé llms.txt à la balise méta des mots-clés, désormais mortes depuis longtemps. M. Muller a écrit en juin 2025 que « le système FWIW sans IA n’utilise actuellement pas llms.txt ». L’analyse des journaux a d’ailleurs révélé que les robots d’indexation par IA demandaient à peine le fichier. Et ce, alors que Google ne le prend pas en charge dans la recherche.
Aucune lecture ne signifie pas aucun risque
Si personne ne lit le fichier, on pourrait croire qu’on s’en fiche de ce qu’il contient. Et bien, on peut proposer trois réponses à cette question. Tout d’abord, le cas d’utilisation prévu de la spécification n’est pas les crawls de formation en masse. Il sert plutôt à l’inférence à la demande. Un agent peut donc demander à une entreprise de récupérer sa propre description au moment de la réponse, précisément au moment où une ligne empoisonnée cause le plus de dégâts. Cela exploite alors le fait que les récupérations à la demande sont conçues pour laisser une signature de journal plus faible que les balayages classiques.
Deuxièmement, l’adoption va dans une direction claires. 110 éditeurs au sein de l’échantillon sectoriel de l’étude, contre 8 un niveau inférieur dans les références robots.txté GoDaddy publie d’ailleurs ses prix sous le format, alors qu’Anthropic publie celui de sa propre documentation.
Troisièmement, l’attaque n’a pas besoin que chaque système d’IA consomme le fichier. Il suffit d’un seul agent, agissant pour un client, afin de lui faire confiance une fois.
Classe d’attaque 1 : altération du fichier que personne ne lit
Défigurez la page d’accueil d’un hébergeur et les dégâts se mesure en minutes. Les clients la voient, le monitoring la voit, les captures d’écran atteignent rapidement le personnel de l’entreprise pour qu’il adresse le problème. Modifiez le fichier /llms.txt de la même entreprise et rien ne se passe du tout, car les humains ne parcourent pas le fichier.
Les moniteurs de disponibilité ne le vérifient pas et la pile de sécurité ne le couvre pas. Le marketing ne le relit généralement pas non plus après la publication. Un fichier llms.txt falsifié est une altération sans témoin, à l’exception des machines pour lesquelles il a été écrit.
Servir une vérité aux humains et une autre aux machines n’est pas une idée nouvelle. C’est même l’un des plus anciens schémas d’abus nommés sur le web. Les politiques anti-spam de Google interdisent d’ailleurs depuis deux décennies le cloaking, qui consiste à « présenter des contenus différents aux utilisateurs et aux moteurs de recherche ». Ce qui est nouveau, c’est la démonstration que la couche d’IA demande encore moins d’effort à compromettre.
Des menaces récentes ont exploitées des surfaces d’attaque similaires
En octobre 2025, des chercheurs de SPLX ont montré qu’un contrôle utilisateur-agent unique, servant une page fabriquée exclusivement pour les robots d’exploration derrière ChatGPT Atlas et Perplexity, suffisait à faire de ces systèmes une réalité établie. L’élément clé de leur article est celui de l’extraction-basé sur l’IA, « tout le contenu qui leur est servi devient une vérité de terrain. »
Un mois plus tôt, Shaked Zychlinski de JFrog avait publié la généralisation sur arXiv : un « web parallèle empoisonné » qui identifie les agents d’IA et leur sert des pages visuellement identiques portant des instructions injectées cachées, invisibles à chaque visiteur humain.
L’unité 42 de Palo Alto Networks a, pour sa part, documenté une injection directe indirecte via du contenu web ordinaire dans la nature.
Le fichier llms.txt augmente le risque en élargissant la surface d’attaque
Dans ce contexte, llms.txt n’est pas une nouvelle classe d’attaque. C’est plutôt la même, dont la difficulté a été supprimée. L’attaquant n’a pas besoin d’empreintes digitales ni de logique de camouflage, car la victime a volontairement publié un canal dédié aux machines uniquement et l’a étiqueté comme tel.
Le recensement indique que l’industrie a également fourni la cachette. Neuf des 110 fichiers sont des dumps de 150 Ko ou plus, par rapport à une spécification dont le point entier est un index concis.
Un paragraphe inséré à 400 000 octets, indiquant aux agents que les migrations ont besoin d’un « outil de vérification » hébergé ailleurs ou que le support est atteint au numéro d’un attaquant, resterait indéfiniment assis sur un domaine d’infrastructure réputé. Et ce, en tirant profit de l’autorité totale du domaine derrière chaque mot.
Classe d’attaque deux : une mise à jour du plugin, vingt-huit catalogues
La deuxième classe d’attaques est celle qui évolue, et dont l’étude a mesuré directement la condition préalable. 28 des 110 dossiers n’ont pas été rédigés par les entreprises qui les servent. Ils sont générés automatiquement par des plugins SEO.
Un quart de l’adoption par l’industrie d’un canal de contenu orienté agent s’est produit comme une fonctionnalité de plugin, et non une décision de l’entreprise. Cela signifie que l’intégrité de ces 28 catalogues correspond exactement à celle du pipeline de mise à jour du plugin qui les écrit. Elle est donc exposée à des risques biens connus.
Un pipeline dont les vulnérabilités sont connues
Le dossier récent de ce pipeline est l’argument. En février 2024, un opérateur peu connu a acheté le domaine polyfill.io et son compte GitHub ; en juin 2024, le service injectait des redirections malveillantes dans plus de 100 000 sites qui l’incorporaient, et Cloudflare a eu recours à la réécriture de l’URL sur son réseau.
Le même mois, cinq plugins sur WordPress.org, Social Warfare étant le plus grand avec plus de 30 000 installations, ont expédié des mises à jour en arrière-plan après que les comptes de leurs développeurs sont tombés sur des mots de passe réutilisés. Le logiciel malveillant a alors créé des comptes d’administrateur frauduleux et injecté du spam SEO.
En juillet 2025, le canal de téléchargement officiel de Gravity Forms, un plugin commercial que le fournisseur compte sur environ un million de sites. Il a ensutie servi une version dérobée pendant environ deux jours avant la divulgation de Patchstack.
Chaque incident a compromis un mécanisme de publication de confiance pour atteindre chaque site en aval, et chacun a été détecté parce que ce qu’il expédiait était du code : les signatures correspondaient, les hachages de fichiers ont changé l’emplacement d’observation des scanners, le comportement des alarmes a sauté.
Un autre “angle mort” de la sécurité des sites web
Maintenant, exécutez le même jeu dans le générateur llms.txt. Une version compromise de l’un des trois plugins qui écrivent ces fichiers n’aurait pas du tout besoin d’envoyer de malware. Il faudrait y ajouter du contenu : un « assistant à la migration » recommandé, un numéro de téléphone d’assistance, un lien associé à une étiquette de balisage fiable.
La sortie atterrit dans un fichier que les scanners ne lisent pas, que les humains n’ouvrent pas. Celui-ci est censé changer lorsque le plugin se met à jour, donc même un contrôle basé sur diff verrait une régénération de routine. Une recommandation empoisonnée n’est pas un indicateur de compromis, mais plutôt une phrase.
Les bases d’installation définissent l’exposition. Yoast SEO se trouve sur plus de 10 millions d’installations actives, Rank Math sur 4 millions et All in One SEO sur 3 millions. Sleon W3Techs, la génération llms.txt serait activée par défaut sur 41,5 % de tous ces sites web.
La modification « Protect The Shire » de WordPress ajoute un délai par défaut de 24 heures sur les mises à jour automatiques des plugins. Il réduit ainsi véritablement cette fenêtre pour le chemin du code.
Il ne fait toutefois rien pour le chemin du contenu. Une fois qu’un générateur empoisonné a dépassé le délai, chaque catalogue régénéré qu’il écrit est passe tous les contrôles qui existent aujourd’hui.
La couche au-dessus du fichier repose donc sur trois plugins avec plus de 17M combinés installent des catalogues en écriture destinés aux agents.
Classe d’attaque trois : diriger les agents qui achètent
Les deux premières classes décrivent comment le contenu empoisonné entre dans la chaîne. La troisième explique pourquoi cela paie. 2026 est l’année où l’industrie a connecté les agents pour qu’ils agissent sur ce qu’ils lisent. WooCommerce 10.9 a ainsi fourni aux agents des capacités qui permettent aux assistants IA de naviguer, d’expédier et de valider.
Une récente étude a d’ailleurs révélé que 13 % des sites de commerce électronique échantillonnés avaient déjà exécuté des intégrations de chatbots vulnérables à l’injection indirecte de prompts.
Un agent qui lit le fichier llms.txt d’une société d’hébergement est, de plus en plus, un agent au milieu d’une transaction. Il compare les plans, propose des prix de renouvellement, guide un client à travers une migration, choisit où pointer un domaine.
L’exmple de GoDaddy démontre la version légitime de son utilastion. Son fichier llms.txt indexe la documentation markdown des prix et des produits. Lorsqu’on demande à un assistant ce que GoDaddy facture, GoDaddy a fourni la réponse sous le format natif de l’assistant. L’attaque utilise le même mécanisme avec des intentions différentes.
Des données falsifiées dans un fichier llms.txt impliquent un risque important
Un catalogue falsifié sur un domaine d’hébergement peut orienter la réponse de l’agent sur tout ce pour quoi le domaine fait autorité : quel téléchargement du panneau de contrôle est à jour, quels serveurs de noms définir, quel « partenaire officiel » gère les migrations, quel numéro est pris en charge.
La preuve de concept de SPLX est instructive précisément parce qu’elle était banale : un CV fabriqué n’a servi qu’à des robots d’indexation (crawlers) qui ont modifié les décisions d’embauche assistées par l’IA.
Échangez le CV contre une liste de prix ou un lien d’assistance sur un domaine classé digne de confiance par chaque système de réputation, et le pilotage hérite de l’autorité de l’hôte. L’agent ne présente pas la ligne empoisonnée comme une réclamation à partir d’un fichier texte. Il la présente plutôt comme ce que dit l’entreprise.
Qui est responsable de gérer le risque lié au fichier llms.txt?
Pour un RSSI hébergeur, la propriété inconfortable de cette surface est que chaque contrôle qui attraperait l’altération existe, est bon marché et est orienté ailleurs. Nous avons vérifié la documentation du fournisseur le 12 juin.
L’analyse de Wordfence couvre l’intégrité des fichiers du noyau, plugin et thème ainsi que les signatures de logiciels malveillants connues. Rien dans sa documentation ne lit le contenu llms.txt. La seule sortie llms.txt-adjacent est constituée d’avis de vulnérabilité sur les plugins générateurs de llms.txt eux-mêmes, tels que le XSS réfléchi dans le Plugin « Website LLMs.txt » (CVE-2026-27068).
L’interaction documentée entre Wordfence et le fichier pointe dans l’autre sens : sa limitation de débit a été signalée comme bloquant la lecture du fichier llms.txt par les robots d’indexation de l’IA. Patchstack assure l’atténuation des vulnérabilités et indique clairement qu’il n’analyse pas les fichiers.
L’industrie se montre trop lente à s’adapter
SiteCheck de Harris cherche les logiciels malveillants, les dégradations et le spam SEO connus dans les pages rendues. Sa documentation ne mentionne toutefois pas du tout llms.txt. L’absence du moindre mot ne signifie pas que ce soit de la négligence. C’est plutôt du lag.
La catégorie de produits « à laquelle les ordinateurs de fichiers font confiance » existe depuis des décennies pour le code. Pour le contenu destiné aux agents, il n’existe toutefois pas encore. D’après le plus récent recensement, aucun des 110 éditeurs ne l’a improvisé lui-même.
La question de la propriété se divise en trois parties, et les contrats n’ont rattrapé aucune d’entre elles. L’hébergeur est propriétaire du domaine et de la réputation. Un llms.txt falsifié est la voix de l’hébergeur, peu importe qui l’a écrit.
La responsabilité partagée décourage la surveillance
Le fournisseur du plugin est propriétaire du pipeline. Trois entreprises rédigent désormais des déclarations destinées aux agents pour le compte de plus de 17 millions de sites. Et ce, sans signature, sans attestation de contenu et dans un cas, la génération par défaut, un choix de posture qui mérite plus d’attention qu’il n’en a eu. C’est toutefois l’opérateur agent qui est responsable de la consommation.
OWASP a classé l’injection rapide comme le principal risque de LLM depuis 2023. Et ce, précisément parce que le contenu récupéré n’est pas une entrée de confiance. Un format de fichier dont l’objectif déclaré est « destiné à la consommation par les LLM » invite pourtant exactement la confiance verbatim contre laquelle le classement met en garde.
Les régulateurs européens finiront par remarquer qu’un fichier empoisonné publié par un fournisseur et dirigé vers des agents d’IA en contact avec la clientèle constitue en substance un incident de sécurité, quel que soit le nom que lui donne la taxonomie de reporting. Le délai de signalement prévu par la loi sur la cyber-résilience commence d’ailleurs en septembre. Il serait préférable pour l’industrie d’avoir une réponse avant que le premier rapport d’incident les oblige à en inventer une.
Ce que doit faire un hébergeur responsable pour minimiser le risque lié au fichier llms.txt
Il n’y a pas de norme de signature à adopter. En l’absence d’une telle norme, le contrôle disponible est donc l’attention, et elle est presque gratuite. Six coups, par ordre d’effort :
- Faites l’inventaire du fichier. Déterminez si vos domaines servent /llms.txt, et qui écrit chacun d’eux : le marketing, un plugin, ou personne dont tout le monde se souvient.
- Mettez sous surveillance l’intégrité du fichiers. Le fichier change rarement à dessein. Être alerté en cas de modification de quelques kilo-octets du texte est le moyen le moins cher d’attirer l’attention sur une menace potentielle.
- Traitez les plugins de générateur comme des éditeurs en production. Pour les versions épinglées, conservez le délai de mise à jour de 24 heures. Relisez la sortie générée après les mises à jour du plugin, car la régénération se produit exactement au moment où le contenu injecté arriverait.
- Gardez-le petit et bien indiqué. Un index concis et organisé, référencé dans le fichier robots.txt, correspond à l’objectif de la spécification, ainsi qu’à sa forme vérifiable. En réalité, un réviseur peut lire 2 Ko, mais personne ne lit 727 Ko.
- Vérifiez les liens chaque trimestre. La corruption dans un catalogue destiné aux machines est à la fois une source d’embarras et une opportunité pour quiconque veux profiter de ce que vous avez abandonné.
- Mettez-le dans la portée. Les directives de réponse aux incidents, les portées de test du stylo et la prochaine conversation avec le fournisseur de votre scanner doivent tous nommer explicitement llms.txt. Le premier fournisseur à proposer une couverture contre la falsification de contenu pour les fichiers destinés aux agents bénéficie d’un facteur de différenciation dont l’industrie a besoin.
L’industrie dans son ensemble doit agir pour minimiser le risque
Le modèle que cette industrie devrait reconnaître est un résumé de sa propre histoire. Robots.txt a été livré en 1994 sans modèle de sécurité et n’en a presque jamais eu besoin, car il indiquait seulement où ne pas aller. Llms.txt est toutefois très différent. Il donne des informations qui sont vraies, aux lecteurs qui agissent en conséquence et aux clients qui ne voient jamais le transfert.
Des canaux comme celui-là ont tous été attaqués dans notre mémoire récente. À chaque fois la leçon était la même : le chemin de confiance ne reçoit un modèle de sécurité qu’après que quelqu’un en ait abusé.
Celui-ci a déjà vingt et un mois. Il continue de croitre et est encore propre pour autant que l’on sache. L’industrie obtient rarement une surface d’attaque documentée, avec des bases de référence mesurées, avant le premier incident. Elle a donc une rare opportunité de corriger la vulnérabilité avant qu’elle ne soit exploitée.
Pour conclure sur le risque de sécurité que représente le fichier llms.txt
Nous abordons régulièrement pour vous des questions concernant divers enjeux de sécurité. Il est toutefois rare que l’ont ait l’occasion d’aborder un nouveau type de vulnérabilité avant que des pirates ou des bots malveillants les aient exploitées.
Le fichier llms.txt représente actuellement une vulnérabilité pour la plupart des sites et des hébergeurs web. Les grands acteurs de l’industrie ont toutefois encore le temps de prendre note de l’avertissement et de d’agir immédiatement pour colmater la faille.
Nous espérons que cet article vous a plus et vous a éclairé sur le risque potentiel que représente le fichier llms.txt d’un site web. Si c’est le cas, nous vous invitons à consulter nos autres articles et comparatifs de notre blog. Vous y trouverez les informations les plus récentes sur l’industrie l’hébergement et sur la création de sites web.
