El 4 de agosto de 2026, JFrog documentó una nueva ola del gusano Shai-Hulud en npm. Empezó por dos librerías conocidas, keyv y cacheable, y en pocas horas alcanzó más de 400 paquetes en más de 1.700 versiones. El detalle que debería cambiarle la semana a cualquier equipo de tecnología: parte de las versiones maliciosas se publicaron con procedencia válida, firmadas a través de GitHub Actions.
Tres meses antes, en mayo, Socket había documentado otra campaña, TrapDoor, que no atacaba el código sino algo más nuevo: los archivos que le dicen a su asistente de IA cómo comportarse.
Las dos apuntan al mismo lugar. Las herramientas con las que su equipo construye software —paquetes, extensiones, servidores MCP, asistentes de código— entraron a la organización más rápido que el procedimiento para revisarlas. Este artículo explica qué pasó, por qué el cuestionario de proveedores no lo detecta, y qué revisar esta semana.
Qué pasó: dos campañas, un mismo hueco
Shai-Hulud, agosto de 2026: el malware con firma válida
Shai-Hulud es un gusano de npm que lleva desde 2025 reapareciendo en olas. Roba credenciales de la máquina donde se instala y las usa para publicar versiones envenenadas de otros paquetes del mismo mantenedor, que a su vez infectan a quien los instale. Se propaga solo.
Lo que documentó JFrog Security Research el 4 de agosto de 2026 tiene dos partes. La primera es la escala: el compromiso empezó por keyv 6.0.0 y cacheable 2.5.1 y llegó a más de 400 paquetes en más de 1.700 versiones. La segunda es el mecanismo, y es la que importa para quien diseña controles.
En el caso de OpenSearch, el gusano abusó del trusted publishing: pidió un token OIDC a GitHub Actions, lo intercambió por un token de publicación de npm y publicó directamente. Y generó un paquete Sigstore completo a través de Fulcio y Rekor. Resultado: el tarball malicioso salió con procedencia válida.
La procedencia y la firma son los controles de cadena de suministro que la industria lleva años recomendando. Responden a una pregunta: ¿este artefacto vino del pipeline esperado? Cuando el pipeline es lo que está comprometido, la misma cadena de confianza da fe del malware.
Lo que roba también dice algo. Además de tokens de npm, configuración de nube (AWS, Azure, GCP), Kubernetes, llaves SSH y billeteras de criptomonedas, el gusano busca credenciales de herramientas de IA: OpenAI, Anthropic, Claude, Cursor. Los atacantes ya saben dónde está el valor.
TrapDoor, mayo de 2026: el archivo que su editor muestra vacío
Socket documentó TrapDoor a partir del 22 de mayo de 2026: más de 34 paquetes maliciosos y más de 384 versiones repartidas entre npm, PyPI y Crates.io. Hasta ahí, una campaña de robo de credenciales como tantas.
La novedad estaba en un archivo. El payload plantaba en el proyecto archivos .cursorrules y CLAUDE.md, que son los que los asistentes de código —Cursor, Claude Code— leen como contexto para saber cómo trabajar en ese repositorio. Adentro llevaban instrucciones escritas con caracteres Unicode de ancho cero. El editor muestra un archivo casi vacío. El asistente lo lee completo, y las instrucciones lo empujan a ejecutar un supuesto "escaneo de seguridad" que en realidad expone los secretos de la máquina.
La campaña intentó además colarse en repositorios abiertos de alto perfil por la puerta más inocente que existe: pull requests que solo agregaban un .cursorrules con "estándares de desarrollo". Según Socket, entre los objetivos estaban proyectos del ecosistema de agentes como browser-use, LangChain y OpenHands.
Yo uso Claude Code a diario y tengo archivos CLAUDE.md en todos mis repositorios. Son útiles justamente porque el asistente les hace caso. Esa es la cara buena. La otra es que quien pueda escribir en ese archivo puede dirigir a la herramienta, y casi ningún equipo lo revisa con el rigor con que revisa un script.
Por qué el cuestionario de proveedores no lo ve
Los cuestionarios de evaluación de proveedores de software preguntan casi siempre lo mismo: certificaciones, gestión de parches, tiempos de respuesta ante CVEs. Son preguntas razonables para vulnerabilidades. No sirven para esto.
Phoenix Security mantiene un corpus de campañas maliciosas en ecosistemas de paquetes. Entre junio de 2024 y junio de 2026 registró 59 campañas con 657 indicadores de paquetes maliciosos. CVEs asignados mientras esas campañas estuvieron activas: cero.
Cero no es un tecnicismo. Significa que el proceso con el que la industria cataloga vulnerabilidades ni siquiera roza esta clase de ataque. Un paquete envenenado no es una falla del software del proveedor: es contenido malicioso que entró por su cadena de construcción. Ningún SLA de parcheo lo cubre, porque no hay parche que aplicar. Hay una dependencia que nunca debió entrar.
El mismo corpus trae un dato sobre la capa nueva: de 3.267 skills de agentes de IA analizados en profundidad, 854 dispararon un hallazgo de riesgo crítico. Más de uno de cada cuatro. Las herramientas que se instalan con un clic para darle capacidades a un agente vienen con la misma proporción de problemas que cualquier otro software de terceros, y con bastante menos escrutinio.
Impacto para empresas en Panamá y LATAM
Lo que veo en la región es una combinación concreta. Los equipos de tecnología son pequeños, adoptaron asistentes de código y agentes de IA temprano porque multiplican a la gente que hay, y casi nadie inventarió qué instaló quién. En una organización de veinte personas puede haber treinta extensiones de IA, una docena de servidores MCP y archivos de reglas en cada repositorio, todo agregado en el último año y nada con dueño.
Desde la perspectiva regulatoria, el punto es de responsabilidad. La Ley 81 de 2019 y su Decreto 285 de 2021 distinguen entre quien decide sobre el tratamiento de los datos personales y quien los custodia o procesa. Quien decide sigue respondiendo frente al titular aunque la información pase por un proveedor, un paquete de código abierto o una herramienta de IA. Si un gusano que entró por una dependencia de npm termina exfiltrando credenciales que dan acceso a datos de clientes, la pregunta del regulador no va a ser quién mantenía keyv. Va a ser qué controles tenía la organización sobre lo que entraba a su entorno.
Y para las entidades bajo supervisión financiera, la exigencia de evidencia es mayor: no basta con decir que se revisan las dependencias, hay que poder mostrar cómo, cuándo y quién.
Ya escribí sobre los agentes de IA persistentes y por qué la seguridad es el factor decisivo. Este artículo es la continuación práctica: el agente es tan confiable como todo lo que le da capacidades, y eso incluye lo que le llega por su cadena de suministro.
Qué puede hacer su empresa hoy
Cinco acciones que un equipo pequeño puede ejecutar esta semana, sin comprar nada.
-
Haga el inventario de herramientas de IA, con dueño. Servidores MCP, extensiones de editor, skills de agentes, paquetes que agregó un asistente. Por cada uno: quién lo instaló, cuándo, qué alcanza y cuándo se revisa. La verificación que más se omite es esa última, y sin ella el inventario envejece en silencio.
-
Trate los archivos de reglas de agentes como código.
CLAUDE.md,.cursorrules,AGENTS.mdy equivalentes entran al repositorio por revisión, con diff visible. Y un pull request que solo agrega configuración de IA merece más escrutinio, no menos: TrapDoor intentó entrar exactamente así. -
Detecte caracteres invisibles en el pipeline. Un chequeo que rechace caracteres Unicode de ancho cero en archivos de texto cuesta minutos de implementar y habría detenido TrapDoor en el primer commit.
-
Dele a cada agente y a cada pipeline una credencial propia, acotada y con vencimiento. Nunca la credencial personal de un desarrollador. Shai-Hulud se propaga con tokens de publicación y confianza de workflows; el radio de daño lo define el alcance de lo que roba. Un pipeline de publicación es una identidad con permisos permanentes y hay que gobernarla como a una cuenta de administrador.
-
Trate la procedencia como una señal, no como un veredicto. Siga verificando firmas, pero fije versiones de las dependencias críticas, revise las actualizaciones antes de adoptarlas y configure una alerta cuando una dependencia que le importa se republique de forma inusual. Es la clase de control que un programa de seguridad de aplicaciones y de la cadena de suministro vuelve rutina en vez de heroísmo.
Mi perspectiva
La pregunta con filo para evaluar a un proveedor de herramientas dejó de ser cada cuánto parcha. Es cómo controla lo que entra a su build: fijado de versiones, verificación de origen, revisión de dependencias nuevas, y con qué evidencia lo demuestra. Y la misma pregunta aplica hacia adentro: si mañana alguien le pidiera la lista de servidores MCP y extensiones de IA instalados en su organización, con un responsable por cada uno, ¿saldría de un documento vivo o habría que ir máquina por máquina?
El asistente hace lo que su contexto le dice. La pregunta de fondo es quién puede escribir ese contexto.
Preguntas frecuentes
¿Un paquete envenenado es lo mismo que una vulnerabilidad?
No. Una vulnerabilidad es un defecto en software legítimo y se corrige con un parche. Un paquete envenenado es contenido malicioso que entró por la cadena de construcción: no hay parche que aplicar, hay una dependencia que nunca debió entrar. Por eso el corpus de Phoenix Security registra 59 campañas activas entre junio de 2024 y junio de 2026 sin un solo CVE asignado mientras estuvieron activas.
¿Por qué un archivo CLAUDE.md o .cursorrules es un riesgo de seguridad?
Porque el asistente de IA lo lee completo como contexto del proyecto y sigue lo que dice. En la campaña TrapDoor, documentada por Socket en mayo de 2026, esos archivos traían instrucciones ocultas en caracteres Unicode de ancho cero: el editor mostraba un archivo casi vacío y el asistente recibía órdenes que lo empujaban a exponer los secretos de la máquina. Hay que revisarlos como código.
¿Si firmamos un contrato con el proveedor, la responsabilidad pasa a él?
En Panamá no. La Ley 81 de 2019 y su Decreto 285 de 2021 distinguen entre quien decide sobre el tratamiento de los datos y quien los custodia; quien decide sigue respondiendo frente al titular aunque el código o el servicio vengan de un tercero. El contrato reparte obligaciones operativas, no traslada la responsabilidad.