La campaña, vinculada con Mini Shai-Hulud, no fue una caída de npm, sino un ataque contra la cadena de publicación de software: paquetes aparentemente legítimos habrían distribuido código para robar credenciales de desarrolladores.
Una nueva campaña de ataque a la cadena de suministro de software encendió alertas entre desarrolladores y equipos de seguridad, luego de que advisories públicos, mantenedores de proyectos y organismos institucionales reportaran paquetes comprometidos en los ecosistemas de npm y PyPI, dos de los registros más usados para instalar dependencias en proyectos de JavaScript y Python.
El incidente ha sido vinculado con Mini Shai-Hulud, una variante de ataques dirigidos contra paquetes de código abierto. A diferencia de una caída de servicio, el problema no implica necesariamente que npm o PyPI hayan dejado de funcionar. De hecho, el tablero de estado de npm puede aparecer sin incidentes de disponibilidad mientras versiones maliciosas de paquetes circulan dentro del registro. El punto crítico es otro: la confianza en la cadena mediante la cual el software se publica, firma, instala y ejecuta.
Entre los casos más documentados aparece TanStack, una familia de herramientas ampliamente usada en aplicaciones web. La base de datos de advisories de GitHub registró una vulnerabilidad crítica asociada con paquetes @tanstack/*, en la que versiones maliciosas podían exfiltrar credenciales de nube, tokens de GitHub y llaves SSH. Según el advisory, las publicaciones fueron autenticadas mediante el flujo legítimo de GitHub Actions OIDC/trusted publishing, pero el atacante habría abusado de configuraciones de CI/CD y del entorno de ejecución para publicar malware bajo una identidad confiable.
La propia comunidad de TanStack también abrió un issue público el 11 de mayo para investigar reportes de versiones comprometidas en npm. Esto refuerza que el caso no se limita a reportes comerciales de firmas de seguridad, sino que alcanzó a los mantenedores del proyecto afectado.
«Alguien abrió una solicitud de extracción desde una bifurcación desechable. Si bien nunca tuvimos la oportunidad de ver la solicitud de extracción, ya que se cerró de inmediato, aun así activó un flujo de trabajo que extrajo el código del colaborador y lo ejecutó en un trabajo que tenía acceso de escritura a nuestra caché de CI compartida.
«El código del atacante envenenó la caché y, posteriormente, cuando una fusión totalmente legítima a la rama principal, procedente de otra solicitud de extracción, ejecutó nuestro flujo de trabajo de lanzamiento, restauró esa caché envenenada, extrajo nuestro token de publicación de corta duración de la memoria del ejecutor y lo utilizó para distribuir versiones maliciosas a través de nuestros paquetes de la familia de enrutadores», explicóTansStacck en su blog.
En Python, uno de los focos más delicados es Mistral AI. La empresa publicó un advisory oficial en el que reconoce que la versión mistralai==2.4.6 en PyPI fue comprometida y que el proyecto fue puesto en cuarentena en PyPI. El aviso ubica la carga de esa versión alrededor del 12 de mayo de 2026 a las 00:05 UTC.
La alerta también fue recogida por NHS England Digital, que publicó un aviso sobre un ataque de cadena de suministro que afectó numerosos paquetes de npm y PyPI. Entre los proyectos mencionados aparecen TanStack, Mistral AI, OpenSearch, UiPath y otros paquetes usados en entornos de desarrollo y automatización.
El alcance exacto todavía varía según la fuente. Algunos reportes hablan de más de 100 paquetes; otros elevan la cifra a alrededor de 170 o 172 paquetes y cientos de versiones comprometidas. Por eso, la cifra debe tratarse como una estimación en evolución, no como un dato cerrado. Lo que sí está mejor documentado es la existencia de versiones específicas comprometidas, como las asociadas con TanStack y la versión mistralai==2.4.6 en PyPI.
La gravedad del caso está en que el ataque no dependía únicamente de engañar a usuarios con paquetes falsos o nombres parecidos. La preocupación central es que algunas versiones maliciosas pudieron aparecer como publicaciones legítimas, al provenir de procesos automatizados o identidades confiables dentro de los flujos modernos de desarrollo.
En términos prácticos, esto significa que empresas, medios, startups y equipos de desarrollo que instalaron o actualizaron dependencias entre el 11 y el 12 de mayo de 2026 deberían revisar si usaron versiones afectadas. Las recomendaciones técnicas incluyen inspeccionar archivos package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt o pyproject.toml; buscar dependencias como @tanstack/* o mistralai==2.4.6; limpiar entornos de instalación; y rotar credenciales si esos paquetes se ejecutaron en máquinas o pipelines con acceso a tokens, llaves SSH, credenciales de nube o secretos de CI/CD.
El episodio vuelve a exhibir una fragilidad cada vez más importante del software contemporáneo: gran parte de internet se construye sobre dependencias abiertas que se instalan de forma automática, muchas veces sin revisión humana directa. La amenaza ya no está solo en vulnerar una aplicación terminada, sino en comprometer la fábrica invisible que produce y actualiza el código que millones de sistemas ejecutan todos los días.
Qué pueden hacer los desarrolladores
Para quienes usan npm o PyPI, la recomendación principal no es dejar de usar estos registros, sino revisar si sus proyectos instalaron versiones afectadas durante la ventana del incidente.
Los equipos técnicos deberían verificar sus archivos de dependencias, como package.json, package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt o pyproject.toml, y buscar paquetes vinculados con la campaña, entre ellos @tanstack/*, @mistralai/*, @opensearch-project/*, @uipath/* o versiones específicas como mistralai==2.4.6.
También se recomienda revisar si hubo ejecuciones de npm install, npm update, npm ci, pip install o despliegues automáticos en CI/CD entre el 11 y el 13 de mayo de 2026, especialmente en entornos con acceso a tokens, llaves SSH, credenciales de nube o secretos de desarrollo.
Si un proyecto instaló una versión comprometida, los especialistas recomiendan limpiar el entorno de instalación, actualizar a versiones corregidas, regenerar archivos de bloqueo cuando sea necesario y, sobre todo, rotar credenciales. Esto incluye tokens de GitHub, npm o PyPI, claves de acceso a servicios cloud, llaves SSH, secretos de GitHub Actions y cualquier variable sensible expuesta en entornos de desarrollo o despliegue.
El caso también deja una lección más amplia: los equipos no solo deben revisar el código que escriben, sino la cadena automatizada que lo instala, publica y actualiza. En ataques de cadena de suministro, el punto vulnerable puede no estar en la aplicación final, sino en una dependencia aparentemente confiable o en el pipeline que la incorpora al proyecto.
