Des fichiers de documentation publics suffisent à faire exécuter du code par des agents IA d’entreprises. Une expérience a montré qu’un paquet hostile a été installé sur une machine d’une grande entreprise en moins de quatre minutes.
La donnée devient du code: un simple llms. txt, contenant des instructions pip ou npm, transforme une documentation en vecteur d’attaque.
Comment un llms. txt transforme un guide en exécutable
Les fichiers llms. txt sont pensés pour décrire produits, APIs et procédures. Dans la pratique, ils contiennent souvent des commandes pip install ou npm install destinées aux agents de codage.
Les agents, automatisés pour accélérer le développement, parsèment la documentation à la recherche d’instructions et exécutent les commandes sans vérifier l’origine des paquets. Les chercheurs ont identifié plus de 237 artefacts non revendiqués cités comme instructions d’installation dans leur corpus.
Le risque tient à la confiance implicite entre documentation et environnement d’exécution: un package nommé comme un composant interne est traité comme légitime par l’agent, même s’il n’appartient pas à l’éditeur.
Analyse de l’étude: taille du sondage et résultats concrets
L’équipe a parcouru 15 000 grandes entreprises et trouvé 8 565 fichiers llms. txt répartis sur 6 214 domaines actifs. Les chiffres révèlent l’étendue du problème.
Parmi ces fichiers, les chercheurs ont extrait des noms de paquets mentionnés comme instructions d’installation et ont enregistré des paquets portant ces noms sur des registres publics.
En injectant un code minimal signalant son installation, ils ont constaté qu’une machine d’une entreprise pesant plusieurs centaines de milliards de dollars a installé le paquet en moins de quatre minutes, preuve d’une exploitation rapide possible.
Mécanique d’une attaque de chaîne d’approvisionnement via documentation
Une attaque de chaîne d’approvisionnement exploite la confiance portée aux fournisseurs ou composants intégrés. Ici, la chaîne commence dans une documentation publique, non dans un dépôt privé.
L’attaquant crée ou surveille des noms mentionnés dans des llms. txt, publie un paquet correspondant et attend qu’un agent d’entreprise le réclame automatiquement.
Le processus contourne les protections traditionnelles, car la commande provient d’une source interne perçue comme fiable – le fichier de documentation – et l’exécution est déclenchée sans validation de l’éditeur du paquet.
Preuves d’exploitation et implications opérationnelles
Les chercheurs n’ont pas seulement démontré la vulnérabilité, ils l’ont exploitée en conditions réelles: en moins de quatre minutes, une machine d’une grande entreprise a installé le paquet test. Cet exemple fournit une preuve de concept concrète.
Les conséquences opérationnelles incluent la compromission potentielle d’environnements de compilation, la fuite de secrets et l’introduction de portes dérobées via des dépendances logicielles. La portée dépend du privilège de l’agent et du contexte d’exécution.
Des acteurs malveillants pourraient industrialiser cette méthode, ciblant en priorité les entreprises disposant d’agents automatisés non restreints, ou recherchant des llms. txt exposés sur des sous-domaines oubliés.
Mesures concrètes pour limiter le risque immédiatement
Les entreprises doivent d’abord inventorier leurs llms. txt publics et y supprimer les commandes d’installation non signées ou non vérifiées. La vérification des paquets et la signature d’artefacts doivent devenir systématiques.
Il est aussi recommandé de confiner les agents IA: limiter les droits d’exécution, interdire l’installation automatique de paquets et exiger une validation humaine pour toute dépendance externe.
Enfin, les registries publics et plateformes de packages peuvent appliquer des contrôles de typo-squatting et des règles de propriété renforcées pour limiter l’enregistrement abusif de noms de paquets identifiés dans des documentations.
