Un llms.txt puede instalar el paquete equivocado: 120 archivos lo permitían
La Cloud Security Alliance (CSA) publicó el 7 de septiembre de 2026 una nota sobre el modelo de confianza de llms.txt: en una revisión de 6.214 dominios, 120 archivos llms.txt o llms-full.txt contenían comandos o referencias a paquetes, dominios o subdominios que no estaban registrados. Si un tercero reclamaba uno de esos destinos, un agente con permiso para ejecutar comandos podía instalar su artefacto siguiendo documentación publicada por una organización legítima.
El riesgo no reside en que el archivo ejecute código por sí solo, sino en la cadena que activa: documentación auténtica, un agente autorizado, un gestor de paquetes legítimo y un nombre cuyo propietario no se comprobó. Los 120 archivos no eran necesariamente maliciosos ni consta que todos fueran explotados; el hallazgo identifica referencias disponibles que podían transformarse en una vía de ataque a la cadena de suministro.
La documentación legítima abrió la ruta de ejecución
llms.txt es una convención propuesta para presentar a los modelos una versión estructurada de la documentación de un sitio. Puede incluir enlaces, ejemplos de API y órdenes de instalación. Esa procedencia ayuda al agente a interpretar el producto, pero no demuestra que el paquete o dominio mencionado pertenezca todavía a quien publica el documento.
El ataque tampoco necesita alterar el sitio del proveedor. Un tercero puede localizar una orden como pip install o npx, comprobar que el nombre indicado está libre y registrarlo en el repositorio público correspondiente. Cuando el agente repite la instrucción, el gestor resuelve el nombre correctamente y descarga el artefacto del nuevo propietario: la sustitución ocurre fuera del dominio que alojaba la guía.
La diferencia frente al typosquatting es importante. Aquí no hace falta que una persona escriba mal una dependencia: el nombre aparece exactamente así en la documentación. También es más preciso hablar de una referencia sin propietario que atribuir todos los casos a una alucinación, porque el hueco puede proceder de un paquete nunca publicado, un cambio de nombre o documentación desactualizada.
Los recuentos describen unidades distintas y una diferencia pendiente
La cifra del título corresponde a 120 archivos, cada uno alojado en un sitio diferente, con al menos una referencia sin registrar. No equivale al total de instrucciones o destinos detectados: la nota de CSA distingue 227 órdenes de instalación y 237 artefactos reclamables cuando suma paquetes, dominios y subdominios.
También varía el inventario de documentos examinados. La cobertura de TechRadar contabiliza 8.265 archivos en los 6.214 dominios, mientras que el informe original de Alon Hertz declara 8.565 archivos resueltos y más de 237 artefactos reclamables. Las páginas públicas no aportan el corpus ni las reglas de deduplicación necesarios para explicar la diferencia de 300 archivos; por eso no debe confundirse con una discrepancia sobre los 120 sitios afectados.
Para probar el mecanismo, los investigadores registraron una muestra reducida de nombres disponibles en npm y PyPI y publicaron paquetes inertes que enviaban una señal al instalarse. El primer aviso llegó desde el entorno de una empresa Fortune 500 en menos de cuatro minutos y otros dos lo hicieron dentro de la primera hora. El informe atribuye ejecuciones observadas a Claude, Codex y Hermes, pero no presenta el hallazgo como una vulnerabilidad exclusiva de esos productos.
El gestor legítimo no valida la relación con el proveedor
Desde la red corporativa, la operación puede parecer normal: un agente aprobado invoca pip o npx, el gestor consulta un registro público conocido y el registro entrega el paquete asociado al nombre solicitado. El control ausente está antes de la descarga: comprobar que el editor del artefacto coincide con la organización cuya documentación lo recomienda.
npx puede agravar esa falta de contexto al descargar y ejecutar un paquete sin añadirlo previamente al manifiesto de dependencias. Si el comando usa un nombre desnudo que no existe localmente, puede resolverse contra el registro público antes de que un archivo de bloqueo, un inventario de dependencias o una revisión del repositorio hagan visible el cambio de propietario.
El alcance final depende de los permisos del agente. Un entorno aislado, sin secretos y con la red restringida reduce las consecuencias; una sesión conectada al puesto de desarrollo o a un ejecutor de integración continua puede heredar acceso al código, credenciales y servicios internos. El problema combina, por tanto, una referencia no validada con autoridad automática para ejecutar.
Una auditoría reproducible antes de permitir instalaciones
Los propietarios de documentación y los equipos de AppSec pueden tratar llms.txt como una entrada de la cadena de suministro. La revisión debe aplicarse a los archivos realmente publicados, incluidas sus variantes llms-full.txt, porque una plantilla interna correcta no garantiza que una copia antigua o una ruta generada contengan las mismas referencias.
- Inventariar los destinos: extraer todos los comandos de instalación, paquetes, dominios, subdominios y URL ejecutables, anotando el ecosistema que resolverá cada nombre.
- Validar la propiedad: consultar el registro de paquetes o DNS y comparar editor, organización, espacio de nombres e historial de publicación con los activos conocidos del proveedor. Si el destino no existe o la identidad no coincide, se bloquea.
- Eliminar referencias ambiguas: corregir nombres desnudos que confundan un binario con su paquete, retirar instrucciones obsoletas y asignar responsable y fecha de revisión a cualquier excepción.
- Fijar el artefacto: usar versiones aprobadas, archivos de bloqueo, hashes y pruebas de procedencia cuando el ecosistema lo permita, en vez de aceptar automáticamente lo que ocupe el nombre al ejecutar la orden.
- Separar lectura y ejecución: impedir que la documentación externa se convierta directamente en una orden de shell. Una dependencia nueva o recién registrada debe requerir lista permitida, aprobación humana o ejecución en un entorno aislado sin secretos.
- Conservar trazabilidad: registrar qué documento originó la orden, qué agente la propuso, quién la autorizó y qué artefacto terminó descargándose.
La divulgación mantiene en reserva los nombres de las organizaciones alcanzadas mientras continúa la remediación y no incluye el corpus completo. La evidencia disponible acota el problema: 120 archivos ofrecían destinos reclamables y una pequeña muestra produjo ejecuciones reales. Sigue sin conocerse cuántos editores han corregido sus documentos ni qué agentes incorporarán verificaciones de propiedad antes de instalar.
Lee también:
Suscríbete a nuestro boletín
Reciba las últimas noticias sobre Web3, IA y criptomonedas directamente en su bandeja de entrada.