Tu AI coding assistant puede estar ejecutando comandos que no consigues ver. La campaña TrapDoor planta instrucciones invisibles en .cursorrules y CLAUDE.md usando caracteres Unicode de ancho cero. TanStack sufrió un segundo ataque que robó tokens OIDC para publicar bajo identidad confiable. 33 paquetes npm impersonan namespaces corporativos con flag de activación remota. Tres vectores, mismo resultado: código malicioso entra por el npm install o por la configuración del AI assistant.
TrapDoor: cuando el asistente de IA se vuelve vector de ejecución
34 paquetes maliciosos. 384+ versiones publicadas. npm, PyPI y Crates.io. Activo desde el 19 de mayo. El diferencial de TrapDoor no es el payload en sí, es el blanco. La campaña explora deliberadamente archivos de configuración de AI coding assistants.
El payload planta dos archivos en el proyecto: .cursorrules con instrucciones para el Cursor, y CLAUDE.md con instrucciones para el Claude Code. Las instrucciones maliciosas son escondidas con zero-width Unicode characters: U+200B, U+200C, U+200D y U+FEFF. Invisibles en cualquier editor. Totalmente parseadas y ejecutadas por el AI assistant.
El ciclo es silencioso: desarrollador abre el proyecto. El assistant lee la configuración. Ejecuta las instrucciones ocultas. El humano no ve nada. El segundo vector es aún más escalable, PRs maliciosos contra langchain, browser-use, llama_index, MetaGPT, OpenHands y langflow con commit messages como "docs: add .cursorrules". Si fueran mergeados, todo clone tendría el payload invisible. Todos fueron rechazados. Pero el vector está probado.
TanStack round 2: OIDC token theft bajo identidad confiable
TanStack sufrió el segundo ataque en semanas. 84 versiones maliciosas en 42 paquetes @tanstack/* publicadas en 6 minutos. CVE-2026-45321. CVSS 9.6. CISA KEV desde el 27 de mayo con plazo de remediación el 10 de junio.
La cadena de ataque: pull_request_target con Pwn Request + cache poisoning fork↔base + extracción del token OIDC del runner. El atacante usó el OIDC trusted-publisher binding de TanStack en GitHub Actions. Con el token, publicó bajo la identidad confiable de la organización. La misma cadena del primer ataque, frontera de confianza de GitHub Actions → OIDC token theft → publicación bajo identidad confiable, pero ahora con refinamiento. El primer round usó cache poisoning. El segundo robó la llave del castillo.
La lección es directa: OIDC trusted-publisher binding es un mecanismo de delegación, no de seguridad. El token atesta que la publicación vino del workflow autorizado. No atesta que el workflow no fue comprometido.
npm dependency confusion: namespace impersonation con activación remota
Microsoft descubrió 33 paquetes npm bajo scopes que imitan namespaces internos corporativos. Tres aliases de operador, mr.4nd3r50n, ce-rwb, t-in-one, todos con emails Yandex. Un mismo X-Secret hardcoded en los tres aliases: operador único.
La técnica es dependency confusion clásica: versión pública con número más alto que la interna. El npm resuelve por la versión más alta. Tu npm install descarga el paquete del atacante. Los package.json spoofean URLs de GitHub Enterprise, Jira y portales internos. Parece legítimo en la code review.
El postinstall hook ejecuta un stager obfuscado que fingerprinta el ambiente: hostname, env vars, paquetes instalados. El stager detecta CI: si la variable CI existe, aborta silenciosamente. Evita alertas en pipelines monitoreados. RECON_ONLY = 1 por ahora, flag toggleable server-side para full exploitation: exfiltración, credential theft, backdoor. C2 en oob.moika[.]tech. Los scopes impersonados incluyen @sber-ecom-core/sberpay-widget de Sberbank.
La convergencia: AI coding assistants son el nuevo blanco de supply chain
30+ CVEs contra agentic AI tooling en 60 días. La superficie de ataque fue instrumentada a machine speed. PraisonAI: scanners en 3h44min después del disclosure. LMDeploy: exploración en 12h31min después del advisory. La ventana de patch para AI infra colapsó para horas. Pipelines con approval gates de días son incompatibles con esa realidad.
TrapDoor prueba que AI coding assistants no son apenas herramientas, son vectores de ejecución. El desarrollador confía que el assistant va a sugerir código. El assistant confía que .cursorrules y CLAUDE.md contienen instrucciones legítimas. Esa cadena de confianza delegada es explorable de la misma forma que el npm resuelve por la versión más alta: el sistema hace lo que fue proyectado para hacer, pero el input fue forjado.
npm install no es operación de confianza implícita. Es confianza delegada. Tú confías en el registry, en el publisher, en el namespace. Cada uno puede ser forjado. Lo mismo vale para AI assistants: confías en el archivo de configuración, en el modelo, en el contexto. Cada uno puede ser envenenado.
Defensa práctica: hardening para la nueva superficie
En Tech86, implementamos supply chain security en tres capas: registry privado con scope-to-registry mapping para eliminar dependency confusion, CI hardening con --ignore-scripts y validación de integridad antes de cualquier ejecución, y AI security-by-design con auditoría de archivos de configuración y restricción de ejecución automática de MCP server.
Si tu team usa Cursor o Claude Code sin hardening, está expuesto. Si tu npm install resuelve paquetes que nadie de la empresa publicó, el pipeline está expuesto. Si tu CI no bloquea egress para dominios de C2 conocidos, la exfiltración ya puede estar ocurriendo. La convergencia entre supply chain attacks y AI coding assistants no es una tendencia futura, es la realidad de mayo de 2026.