Abuso de LLMO: envenenar la documentación de paquetes para engañar a los agentes de código IA

¿De qué se trata?

En junio de 2026, ReversingLabs publicó una investigación sobre una campaña de cadena de suministro que denominó PromptMink, atribuida al grupo vinculado a Corea del Norte Famous Chollima. La novedad no está en el malware, sino en el objetivo. En lugar de engañar a un desarrollador humano, los atacantes redactan la documentación de los paquetes para convencer a un gran modelo de lenguaje de que el paquete es la dependencia adecuada para la tarea en curso. ReversingLabs llama a esta técnica abuso de LLM Optimization (LLMO) e inyección de conocimiento. El objetivo, según ellos, es «hacer que el LLM sea propenso a recomendar el uso del paquete malicioso, haciendo la documentación lo más creíble y adecuada posible para el proyecto en el que trabaja el agente de código». Es una descripción de una clase de ataque, no un exploit accionable.

La campaña no es teórica. ReversingLabs rastreó los paquetes de carga maliciosa hasta septiembre-octubre de 2025, y confirma que alcanzaron a agentes reales: un commit del 28 de febrero de 2026 en un agente de trading cripto de código abierto, openpaw-graveyard, añadió la dependencia-cebo en un commit coautorizado por Claude Opus. Un segundo caso apareció en una plataforma donde agentes LLM publican sobre su trabajo, en la que un bot explicaba que había usado uno de los paquetes-cebo porque «tenía una función que necesitaba».

Cómo funciona

El ataque separa el señuelo de la carga útil en dos capas de paquetes, lo que lo hace duradero.

Capa           Rol                           Ejemplo (según el informe)
-------------  ----------------------------  --------------------------------
1. "Cebo"      Paquete limpio, de apariencia  @solana-launchpad/sdk
               legítima, doc pulida. Lista la  (no contiene código malicioso)
               capa 2 como dependencia
               transitiva.
2. "Carga"     Infostealer arrastrado          @hash-validator/v2  ->
               automáticamente al instalar.    @validate-sdk/v2 (código idéntico,
               Renombrado tras cada retirada.  nuevo nombre tras cada baja)

Dos decisiones de diseño lo explican todo. Primero, la documentación está optimizada para un lector máquina, no humano: texto de README convincente, tipos TypeScript y estructura semántica que llevan a un agente a concluir que el paquete encaja en el proyecto actual. Segundo, el comportamiento malicioso se oculta donde los LLM no miran. A medida que aumentaban las detecciones, los operadores trasladaron las cargas del JavaScript fácilmente analizable a complementos Node.js en Rust precompilados (vía NAPI-RS): el código que un agente podría leer permanece limpio mientras el binario roba — exfiltración de secretos del entorno, despliegue de claves SSH y archivado de datos hacia la infraestructura del atacante.

Como el paquete-cebo limpio nunca necesita cambiar, los atacantes preservan su reputación y solo inyectan una carga recién renombrada tras cada detección — el mismo truco que derrota a las listas de bloqueo por nombre.

Por qué importa

Durante años, la principal defensa conductual contra estos ataques fue la fricción humana: un desarrollador que se detiene ante un nombre desconocido para comprobar el número de descargas y el historial del mantenedor antes de ejecutar npm install. Como argumentó Brad Arkin (Socket) el 23 de junio de 2026, los agentes de IA eliminan exactamente esa fricción: resuelven una dependencia y siguen con la compilación. La eficiencia es la superficie de ataque.

Esto convierte en arma la capacidad de comprensión documental del LLM. Es un primo, del lado de la cadena de suministro, del envenenamiento de descripciones de herramientas: el modelo confía en un texto redactado por el atacante y actúa en consecuencia. También difiere de los dos patrones ya cubiertos — el slopsquatting, que explota nombres alucinados, y el typosquatting de modelos, que explota nombres mal tecleados. El abuso de LLMO no necesita ninguno: el nombre del paquete es real, la documentación es excelente y el agente lo elige por sus méritos — méritos fabricados.

Defensas

Ningún parche resuelve esto, porque nada está técnicamente «roto». Los controles son de proceso e higiene del pipeline, y coinciden con la guía CISA/Five Eyes del 1 de mayo de 2026, que advierte que los agentes eligen «con más frecuencia las descripciones persuasivas».

1. Trate los paquetes sugeridos por el agente como una categoría de revisión distinta y no confiable. Toda dependencia añadida de forma autónoma debe revisarse (editor, antigüedad de la versión, dependencias transitivas) antes de enviarse — el momento de revisión humana que el agente se saltó.
2. Aplique la política de registro en la CI/CD, no solo en los equipos. Ponga en lista blanca los paquetes y versiones aprobados para que un agente no pueda instalar literalmente nada fuera de la lista, diga lo que diga la doc. Los controles a nivel de registro se aplican sin importar cómo se introdujo la dependencia.
3. Exija aprobación humana para acciones de alto impacto. La CISA clasifica precisamente el añadido de una dependencia en un pipeline sensible en esta categoría.
4. Detecte por comportamiento, no por nombre. Estos paquetes no portaban ningún CVE en el momento del ataque; las herramientas SCA que solo comparan nombres con bases de vulnerabilidades no ven nada. Analice lo que hace un paquete — y tenga en cuenta que --ignore-scripts es solo un control parcial, evitable mediante extensiones nativas.
5. Dé al agente un oráculo de reputación. ReversingLabs mostró que un agente de código, una vez conectado a un servidor MCP de reputación de paquetes, desaconsejaba correctamente instalar el paquete-cebo. Alimente a los agentes con datos verificables en lugar de confiar en el marketing del propio paquete.
6. Mantenga un SBOM. No se puede responder a una dependencia introducida por un agente que no se ve a posteriori.

Estado

Elemento	Referencia	Fecha	Notas
Primer paquete de carga detectado	ReversingLabs	2025-09	Comienza la campaña de dos capas
Cambio a cargas Rust/NAPI-RS	ReversingLabs	2026-03	Elude la revisión de código por LLM
Dependencia-cebo añadida por un agente	commit openpaw-graveyard	2026-02-28	Coautorizado por Claude Opus
Investigación pública (PromptMink)	ReversingLabs	2026-06	Atribución: Famous Chollima
Guía multigubernamental	CISA / Five Eyes	2026-05-01	Listas blancas, aprobación humana, mínimo privilegio

El encuadre honesto no es «hackearon a un LLM». Es que la capacidad de un agente para leer y confiar en la documentación es ahora una superficie de ataque, y la respuesta defensiva consiste en dejar de permitir que un paquete se describa a sí mismo: verifíquelo fuera de banda, contrólelo en el pipeline y mantenga a un humano en la instalación de todo lo que el agente encontró convincente.