La cadena de suministro de npm y PyPI, bajo asedio: cómo la IA está acelerando la inyección de paquetes maliciosos

En 2026 se han contabilizado más campañas de compromiso de paquetes de código abierto que en todo 2025. La novedad no es solo el volumen, sino que la IA se ha convertido a la vez en objetivo y en herramienta de ataque: desde nombres de librerías inexistentes que los propios modelos recomiendan, hasta configuraciones envenenadas que los asistentes de codificación ejecutan como si fueran instrucciones legítimas.

El ecosistema de paquetes de código abierto —npm y PyPI a la cabeza— vive en 2026 su año más agresivo en cuanto a compromisos de la cadena de suministro. Solo en mayo se contabilizaron catorce campañas distintas y 346 paquetes maliciosos indexados, más que en los cuatro meses anteriores combinados, según el seguimiento de Phoenix Security. Los investigadores atribuyen ese salto a la automatización: un único evento tipo gusano puede superar en volumen a una cuarta parte de todas las campañas manuales del periodo. npm concentra la gran mayoría del volumen —cerca de cuatro de cada cinco paquetes maliciosos indexados, presente en el 63% de las campañas—, mientras que PyPI actúa como frente secundario más estable, con cargas útiles de mayor precisión (troyanos bancarios, RAT, robo de criptomonedas) en lugar de typosquatting masivo.

Los gusanos que marcaron el semestre

La campaña más disruptiva del año, conocida como Mini Shai-Hulud, se destapó el 12 de mayo tras comprometer el pipeline de GitHub Actions de TanStack. En cuestión de minutos se publicaron decenas de versiones maliciosas de paquetes @tanstack, y el ataque se propagó por sí mismo: robaba credenciales de npm y las usaba para identificar qué otros paquetes podía publicar la víctima, inyectaba la misma dependencia maliciosa y republicaba versiones alteradas bajo la identidad legítima del desarrollador. El radio de impacto alcanzó a proyectos de TanStack, Mistral AI, UiPath y OpenSearch, además de un paquete que suplantaba al CLI de Bitwarden, y en algunos casos incluyó un componente destructivo capaz de borrar directorios de usuario. Semanas después, una segunda ola —Miasma— repitió el patrón contra paquetes de Red Hat y decenas más, y en junio IronWorm, detectado por JFrog, sumó un infostealer escrito en Rust escondido tras un rootkit a nivel de kernel (eBPF) en 36 paquetes de npm.

Cuando la IA se convierte en objetivo: la puerta de los asistentes de código

El componente más novedoso de este ciclo de ataques es una campaña bautizada TrapDoor, la primera detectada que ataca simultáneamente npm, PyPI y Crates.io con rutas de ejecución específicas para cada ecosistema. Su innovación no está en el payload, sino en el vector: los paquetes maliciosos incluyen archivos de configuración como .cursorrules o CLAUDE.md con instrucciones ocultas mediante caracteres Unicode de ancho cero. Cuando un desarrollador abre el proyecto en Cursor o Claude Code, el asistente de IA lee esas instrucciones como si fueran parte legítima del proyecto y ejecuta lo que aparenta ser un "análisis de seguridad" que en realidad exfiltra secretos del entorno. TrapDoor llegó incluso a abrir pull requests contra repositorios muy utilizados —como browser-use, langchain y langflow— para propagar esas configuraciones envenenadas aguas arriba.

Cuando la IA se convierte en arma: el "slopsquatting"

El segundo vector, más silencioso pero potencialmente más masivo, aprovecha una debilidad estructural de los modelos de lenguaje: la alucinación de nombres de paquetes. Un estudio académico presentado en USENIX Security 2025 evaluó dieciséis modelos de generación de código —incluidos Claude, GPT-4 y otros— sobre 756.000 muestras y encontró que cerca del 20% de las recomendaciones apuntaban a paquetes que no existen. Lo relevante para un atacante es que esas alucinaciones son repetibles: un 43% de los nombres inventados reaparecía en cada repetición del mismo prompt, y un 58% volvía a aparecer en al menos dos de cada diez ejecuciones. Eso convierte una alucinación aleatoria en una lista predecible de nombres que un atacante puede registrar de antemano, cargados con código malicioso, a la espera de que el siguiente desarrollador —o el siguiente agente autónomo trabajando sin supervisión— acepte la sugerencia sin verificarla. El término, acuñado por Seth Larson (Python Software Foundation), es slopsquatting.

No es solo teoría: en 2024 un investigador de Lasso Security registró como prueba de concepto un paquete vacío llamado huggingface-cli —un nombre que los modelos alucinaban de forma recurrente— y acumuló más de 30.000 descargas reales en tres meses, sin ninguna promoción, incluyendo una referencia copiada directamente en un repositorio público de Alibaba. En enero de 2026, el investigador Charlie Eriksen documentó un caso equivalente en npm: react-codeshift, un nombre alucinado por fusión de dos paquetes reales, se propagó a través de decenas de repositorios mediante archivos de "skills" generados por IA, sin que nadie lo hubiera plantado deliberadamente. Hasta ahora no se ha confirmado ningún ataque masivo explotando este vector con fines maliciosos, pero la infraestructura para hacerlo —nombres predecibles, registros públicos y gratuitos, y desarrolladores que copian y pegan sugerencias sin comprobarlas— ya está en su sitio.

Una lectura con matices

No todo el panorama apunta en la misma dirección: datos de ReversingLabs citados por Phoenix Security muestran que el volumen de malware detectado en PyPI y NuGet ha caído un 43% y un 60% respectivamente, incluso mientras npm registra su año más activo. Esto sugiere que el problema no es una explosión homogénea de amenazas en todo el ecosistema de código abierto, sino una concentración cada vez mayor de esfuerzo ofensivo en el registro con más superficie de ataque —npm— y en las nuevas vías que abre la adopción masiva de asistentes de codificación con IA.

Para equipos de seguridad corporativa, la recomendación práctica que se repite en los distintos informes es la misma que antes de la irrupción de la IA generativa, solo que ahora más urgente: verificar cada dependencia contra el registro correspondiente antes de instalarla, auditar los archivos de configuración de asistentes de IA (.cursorrules,

CLAUDE.md, .vscode) que llegan junto al código como si fueran documentación inofensiva, y no tratar la sugerencia de un modelo —ni la de un agente autónomo— como una fuente de confianza por defecto.