Nuevo ataque a npm y PyPI afecta a LatAm

Un nuevo ataque a la cadena de suministro volvió a poner a npm y PyPI bajo la lupa. Esta vez, la campaña no se quedó en un paquete aislado: se movió entre ecosistemas, contaminó cientos de versiones y terminó tocando librerías usadas por equipos de producto, data y automatización. Entre los nombres afectados aparecieron TanStack, Mistral AI y UiPath, tres marcas que muchas veces están presentes en stacks modernos de empresas en Latinoamérica aunque el equipo no las vea todos los días.

El punto incómodo es este: no necesitas usar una librería “rara” para quedar expuesto. Basta con depender de un paquete popular, de una subdependencia o de una versión publicada con credenciales robadas. Cuando el ataque entra por el registro, el problema ya no es solo del equipo de seguridad. También afecta a frontend, backend, data engineering, QA y a cualquiera que despliegue código con pipelines automáticos.

Qué pasó en esta campaña

La alerta publicada por SecurityWeek describe una campaña fresca de supply chain que afectó tanto a npm como a PyPI. En términos prácticos, eso significa que los atacantes no buscaron un solo ecosistema: intentaron maximizar alcance donde hoy vive buena parte del software moderno. Si tu organización mezcla JavaScript, Python y automatización, el radio de exposición sube rápido.

El dato que más importa no es solo que hubo paquetes comprometidos, sino que el impacto se propagó a través de múltiples versiones. Eso complica la limpieza porque no basta con bloquear una publicación puntual. Tienes que revisar qué versión exacta consumiste, si quedó fijada en lockfiles antiguos y si tu pipeline reconstruye imágenes o artefactos con caches que arrastran dependencias viejas.

Por qué importa que haya golpeado npm y PyPI al mismo tiempo

npm suele estar en el centro de frontends, tooling y servicios Node. PyPI, por su parte, aparece en notebooks, APIs, jobs de data y scripts de automatización. Atacar ambos ecosistemas en una sola campaña amplía la posibilidad de encontrar un blanco en cualquier empresa que combine desarrollo de producto con analítica o procesos internos.

En Latinoamérica eso se vuelve especialmente sensible porque muchas compañías crecieron con stacks híbridos: frontend en React o Next.js, backend en Python, automatizaciones en scripts sueltos y despliegues en contenedores. Un solo paquete comprometido puede entrar por una app web, pero también por un flujo de ETL o por una tarea programada que nadie revisa con la misma atención que la app principal.

Qué significa que se hayan afectado cientos de versiones

Cuando una campaña contamina cientos de versiones, el riesgo no se limita al día del incidente. Las versiones malas pueden quedarse en cachés, mirrors internos, lockfiles de repos antiguos o imágenes Docker construidas antes de la detección. Si tu equipo trabaja con release trains largos, el problema puede reaparecer semanas después.

Además, los atacantes suelen aprovechar la confianza que generan los paquetes con historial. Si una dependencia ya estaba instalada en varios proyectos, nadie sospecha de inmediato. Por eso este tipo de ataque duele más que un phishing aislado: entra por una pieza que tu proceso de desarrollo considera normal.

Qué librerías quedaron en la mira

Entre los nombres mencionados por la cobertura están TanStack, Mistral AI y UiPath. No significa que sus productos principales hayan sido comprometidos de la misma forma ni que toda su oferta esté afectada. Lo que sí muestra el caso es que los atacantes apuntan a marcas y paquetes con tracción real, porque saben que una dependencia conocida se distribuye más rápido y genera menos fricción al momento de instalar.

TanStack es un buen ejemplo de cómo una librería de infraestructura de frontend puede tener mucho alcance sin ser visible para negocio. Si tu equipo usa TanStack Query, Table o Router, cualquier alteración en el suministro del paquete puede impactar apps internas y externas. Mistral AI y UiPath, por otro lado, muestran que el problema no se limita al frontend: también golpea herramientas ligadas a IA, automatización y orquestación empresarial.

TanStack: más cerca del producto de lo que parece

TanStack suele entrar por decisiones de arquitectura de frontend. Si tu equipo usa React, probablemente lo vea como una dependencia más. Pero en realidad toca componentes críticos de UX, consultas a API y manejo de estado. Si un paquete de ese entorno se contamina, el impacto puede aparecer en funciones de login, dashboards o flujos de compra.

Para equipos regionales, esto es relevante porque muchas startups y scaleups en México, Colombia, Chile, Perú y Ecuador usan stacks muy similares. Cuando una librería popular cae bajo ataque, el efecto se siente en varias empresas a la vez, no solo en una.

Mistral AI y UiPath: el lado menos visible del stack

Mistral AI aparece cada vez más en integraciones de IA generativa, asistentes internos y servicios que exponen APIs a otros equipos. Si un paquete relacionado se compromete, el problema puede escalar hacia automatizaciones que tocan datos sensibles o credenciales de terceros.

UiPath, por su parte, conecta procesos de negocio con automatización. En ese terreno, una dependencia comprometida puede terminar en flujos de facturación, validación de documentos o carga de datos. No siempre se ve como “código de producto”, pero sí mueve operaciones reales. Ahí está el riesgo: el atacante no necesita entrar por tu app principal si puede hacerlo por una pieza que alimenta el negocio.

Cómo funciona un ataque de supply chain así

Un ataque de supply chain en registries como npm o PyPI suele explotar una combinación de confianza, automatización y velocidad. Publicar paquetes es fácil. Instalar dependencias también. El problema aparece cuando el proceso de publicación o actualización de un paquete queda comprometido y la distribución se hace sola a través de pipelines, lockfiles y CI.

La campaña descrita por SecurityWeek encaja en ese patrón: múltiples versiones afectadas, alcance entre ecosistemas y foco en paquetes con distribución real. Eso sugiere una operación pensada para maximizar alcance, no para dejar una firma muy visible. Mientras más normal parece la dependencia, más fácil es que pase el filtro.

Vector probable de abuso

Sin afirmar detalles que no estén confirmados, hay varios caminos típicos en este tipo de incidente:

1. Robo de credenciales de maintainers para publicar versiones maliciosas.
2. Compromiso de cuentas con permisos de publicación.
3. Inserción de código malicioso en paquetes legítimos.
4. Dependencias transitivas comprometidas que arrastran a proyectos aguas abajo.
5. Uso de versiones nuevas para empujar el payload antes de que se detecte.

Cada uno de esos caminos tiene un patrón común: el atacante busca parecer parte del flujo normal. No intenta romper la puerta a patadas; intenta entrar con credenciales válidas o con una actualización que nadie cuestiona.

Qué suele hacer el payload

En campañas de este tipo, el payload puede intentar robar tokens, credenciales de nube, variables de entorno o información del entorno de build. También puede descargar más código, alterar scripts de instalación o preparar persistencia en el pipeline. El detalle exacto depende de la muestra, pero el objetivo casi siempre es el mismo: convertir tu entorno de desarrollo o CI en una fuente de acceso.

Si tu organización usa secretos en variables de entorno, tokens de npm, llaves de PyPI o acceso a repos privados, el riesgo sube. Un paquete malicioso no necesita exfiltrar todo en el primer minuto. A veces basta con capturar un token de corta duración para abrir la puerta a más recursos.

Qué revisar si usas npm o PyPI

La primera reacción no debería ser pánico, sino inventario. Necesitas saber qué versiones consumiste, cuándo las instalaste y desde qué fuente. Si tienes observabilidad sobre builds, mejor. Si no la tienes, toca reconstruirla con lockfiles, manifests y logs de CI.

También conviene revisar si tu organización consume paquetes directamente o a través de mirrors internos. Muchas veces el equipo cree que está protegido porque usa un registry privado, pero ese mirror solo replica lo que llega desde afuera. Si la versión mala entró una vez, puede haberse quedado en el espejo interno.

Lista de verificación rápida

• Revisa package-lock.json, pnpm-lock.yaml, yarn.lock, requirements.txt, poetry.lock y Pipfile.lock.
• Busca versiones publicadas durante la ventana del incidente.
• Compara hashes si tu flujo los guarda.
• Revisa imágenes Docker antiguas y caches de CI.
• Audita tokens expuestos en variables de entorno y secretos de pipeline.
• Verifica si hubo cambios inesperados en scripts de instalación o postinstall.
• Si usas dependencias transitivas, inspecciona el árbol completo, no solo las directas.

Señales de alerta en tu pipeline

Hay pistas que suelen aparecer cuando una dependencia fue usada como vector. Por ejemplo, builds que empiezan a hacer requests a dominios extraños, cambios en tiempos de instalación, procesos que descargan binarios en pasos que antes eran limpios o archivos generados fuera de lo normal. No siempre verás una alarma clara, así que conviene mirar el comportamiento, no solo la firma.

Si tienes herramientas de SCA o dependency scanning, ejecuta un barrido con la base de datos más reciente. Y si tu equipo no usa una, esta es una buena excusa para empezar. No porque resuelva todo, sino porque te da una línea base para ver qué versiones pasan por tu software.

Qué pueden hacer equipos de producto y plataformas en LatAm

Este tipo de incidente no se resuelve solo desde seguridad. Necesitas que producto, ingeniería y plataforma trabajen juntos. En muchas empresas de la región, la realidad es que el equipo de plataforma mantiene la infraestructura, pero producto decide prioridades y urgencias. Si no alineas esos tres frentes, la remediación se vuelve lenta.

La ventaja de actuar rápido es concreta: reduces el tiempo entre la publicación maliciosa y el despliegue de una versión segura. En un ataque de supply chain, cada hora cuenta porque el daño se multiplica por automatización. No necesitas que todos los repos estén comprometidos para tener un incidente serio; basta con que uno de los servicios más usados quede expuesto.

Plan de acción en 48 horas

1. Identifica los proyectos que usan npm o PyPI en producción y en CI.
2. Congela actualizaciones automáticas de dependencias mientras revisas el alcance.
3. Reinstala desde fuentes confiables y regenera lockfiles si detectas versiones sospechosas.
4. Rota credenciales de publicación, tokens de CI y secretos que hayan estado disponibles en builds.
5. Revisa logs de instalación y salida de procesos por tráfico extraño.
6. Informa a producto sobre posibles degradaciones o ventanas de mantenimiento.
7. Documenta qué repos y servicios fueron revisados para no repetir el trabajo.

Cómo reducir el riesgo a futuro

No hay una sola medida mágica. Lo que sí funciona es sumar controles pequeños que se refuercen entre sí. Firma de paquetes cuando aplique, pinning de versiones, revisión de dependencias críticas, límites a credenciales de publicación y separación entre cuentas humanas y automáticas. Si un token de CI sirve para todo, ya tienes una superficie de ataque innecesaria.

También ayuda definir qué dependencias son críticas para negocio. No todas merecen el mismo tratamiento. Una librería de testing no pesa igual que un paquete que toca autenticación, pagos o automatización de documentos. Si priorizas por impacto, tu respuesta será más rápida y menos costosa.

Recursos útiles

Si quieres ir al detalle técnico, la documentación oficial de npm sobre seguridad de paquetes es un buen punto de partida: https://docs.npmjs.com/security

Para Python, la guía de seguridad de PyPI también vale la pena: https://pypi.org/security/

Y si tu equipo quiere revisar buenas prácticas generales de software supply chain, la guía de SLSA ayuda a ordenar controles por nivel de madurez: https://slsa.dev/

Lo que este ataque deja claro

La lección no es que npm o PyPI sean inseguros por definición. La lección es que la confianza en el ecosistema necesita controles más duros que hace cinco años. Hoy no basta con instalar paquetes populares y asumir que todo está bien. Si tu organización depende de software abierto, también depende de cómo se publican, firman, distribuyen y consumen esos paquetes.

Para equipos en Latinoamérica, el impacto es doble. Por un lado, hay menos margen para incidentes largos porque muchas empresas operan con equipos pequeños y presión alta de entrega. Por otro, abundan los stacks mixtos que mezclan JavaScript, Python y automatización, justo el terreno donde esta campaña puede hacer más daño.

Si trabajas en producto o plataforma, este es un buen momento para revisar tus dependencias críticas, tus credenciales de publicación y tu proceso de actualización. No hace falta esperar a que un paquete afectado llegue a producción para empezar.

Tabla resumen