Dos atacantes envenenan herramientas de código abierto

En marzo de 2026, dos grupos de atacantes comprometieron casi simultáneamente dos de las herramientas más populares del ecosistema de desarrolladores: Trivy (escáner de vulnerabilidades con 100.000+ usuarios) y Axios (librería JavaScript con 100 millones de descargas semanales, presente en el 80% de servicios cloud). El malware robó credenciales de desarrolladores y se propagó a 47+ paquetes npm. Según Mandiant, el daño será visible durante meses mientras los datos robados se leveragean para ataques personalizados.

Qué es un ataque de cadena de suministro

Un ataque de cadena de suministro (supply chain attack) es el compromiso de una herramienta, librería o servicio ampliamente usado por desarrolladores, con el objetivo de distribuir malware a decenas de miles de empresas de una sola vez. La idea es simple pero devastadora: en vez de atacar 10.000 empresas individuales, vos atacás una herramienta que las 10.000 usan.

Ponele que sos un atacante con recursos limitados. ¿Qué hacés? Gastás meses infectando servidores de una empresa para conseguir 50 millones de dólares en datos. O atacás npm, robás las credenciales de un package que usan 100 millones de desarrolladores semanales, y en 3 horas tenés acceso a potencialmente 50.000 empresas. El segundo escenario es más atractivo (spoiler: lo es).

Esto no es nuevo. SolarWinds en 2020 fue el hito que todos recordamos: atacantes comprometieron el repositorio de actualizaciones de una herramienta de monitoreo, distribuyeron un backdoor disfrazado de parche legítimo, y durante meses robaron datos del Tesoro de EE.UU., del Departamento de Defensa, y de cientos de empresas Fortune 500. Pero en 2026, los atacantes aprendieron que atacar una herramienta es más eficiente y deja menos pistas que atacar 100 empresas individualmente.

Marzo 2026: cinco ataques en doce días

No fueron dos ataques. Fueron una campaña coordinada de cinco ataques que empezó a principios de marzo y mostró un nivel de sofisticación nunca visto en supply chain.

El cronograma: Trivy fue comprometido el 19 de marzo. KICS (escáner de infraestructura) fue atacado el 21 de marzo. LiteLLM (wrapper de LLMs) el 24 de marzo. Axios (la bomba atómica) el 31 de marzo. Y en paralelo, decenas de paquetes npm menores fueron comprometidos mediante propagación automática. El tema es que los atacantes no se apuraron a desactivar los backdoors. Qué atacantes que creen que pueden estar semanas o meses antes de que alguien note algo raro.

¿Cómo coordinan cinco ataques simultáneamente diferentes grupos? O hay comunicación entre ellos, o hay un actor principal orquestando. Los reportes de seguridad sugieren lo segundo: UNC1069, la amenaza atribuida a Corea del Norte, usó técnicas de ingeniería social para obtener acceso a Trivy, KICS y otros. Una vez dentro, el malware se propagó automáticamente.

Trivy comprometido: el escáner de vulnerabilidades como arma

Trivy es una herramienta que vos instalas en tu pipeline de CI/CD. Tiene acceso a todo: a los tokens de tu repositorio, a tus credenciales de cloud, a tus secretos en Kubernetes. Si Trivy está comprometido, el atacante tiene acceso a todo lo que Trivy ve. Ya lo cubrimos antes en evaluar opciones seguras de plataformas.

Esto es lo que pasó: los atacantes obtuvieron acceso a un token de GitHub del equipo de Aqua Security (la empresa que mantiene Trivy). Con ese token, publicaron versiones maliciosas de trivy-action en 75 tags diferentes. La trivy-action es una GitHub Action — eso significa que cientos de pipelines de CI/CD ejecutan automáticamente la versión maliciosa cada vez que hacen un commit.

Al mismo tiempo, los atacantes pusharon versiones comprometidas de Trivy (versión 0.69.4 y “latest”) en Docker Hub. El malware se ejecuta en postinstall hooks. Suena normal, ¿no? Pero ahí es donde está el veneno: el script de postinstall roba credenciales (tokens de GitHub, API keys de AWS, GCP, Azure, configuraciones de SSH, archivos .docker/config.json, ~/.kube/config de Kubernetes).

Una vez que el atacante tiene esos archivos, el siguiente paso es casi automático: usar las credenciales para acceder a repositorios privados, publicar más paquetes maliciosos, y propagarse a través de la red de desarrolladores.

Axios: 100 millones de descargas maliciosas

Axios es más crítica todavía. Es una librería JavaScript que se descarga 100 millones de veces semanalmente. Si vos escribís código JavaScript moderno, es probable que usés Axios sin siquiera saberlo (porque alguna dependencia tuya la requiere).

Los actores norcoreanos (UNC1069, según Google) usaron ingeniería social para obtener credenciales del mantenedor de Axios. ¿Cuánto tiempo tuvo acceso el atacante? Tres horas. En tres horas, publicó dos versiones maliciosas (1.14.1 y 0.30.4) en npm con un Remote Access Trojan (RAT) que abre un backdoor en la máquina del desarrollador. Luego, antes de que npm o los mantenedores lo notaran, el atacante usó CanisterWorm (un script de propagación automática) para replicarse a otros 47 paquetes npm.

Eso sí, el atacante fue lo suficientemente inteligente para no hacerlo obvio. Las versiones maliciosas se publicaron como actualizaciones legítimas. El RAT no hace mucho ruido en background. Y la cadena de suministro npm es lo suficientemente caótica que nadie notó hasta que fue tarde.

Lo interesante es que Axios llegó a 50.000 empresas en cuestión de horas. No todas instalaron la versión maliciosa, pero sí suficientes. Y como dijo Charles Carmakal de Mandiant, los datos robados (credenciales, archivos de proyecto, secretos) se usarán para targeted attacks posteriores durante semanas o meses. El atacante no necesita exfiltrar datos esa misma noche. Puede esperar.

Los atacantes: TeamPCP y la amenaza norcoreana

TeamPCP es un grupo loosely knit. No son una operación estatal tipo Lazarus. Son cibercriminales independientes, probablemente de Europa del Este o Rusia, que venden acceso y malware al mejor postor. El informe de Palo Alto Networks sobre TeamPCP muestra que han estado activos desde 2024, pero en 2026 escalaron sus operaciones de forma exponencial.

UNC1069, en cambio, es atribuido a Corea del Norte. Los analistas de Google notaron patrones de ataque, horarios de operación, y técnicas de ingeniería social consistentes con operaciones norcoreanas previas. El objetivo es claro: robar IP, obtener acceso a redes de empresas de defensa y tecnología, y monetizar los datos o usarlos para espionaje.

¿Cómo consiguieron acceso? Eso es lo preocupante. No fue un hack sofisticado a una infraestructura. Fue ingeniería social. Según los reportes, los atacantes pasaron semanas (potencialmente meses) estudiando a los mantenedores de Axios y Trivy. Enviaron mensajes personalizados, ganaron confianza, y cuando llegó el momento, pidieron que instalaran un “script de auditoría” o que hicieran un “debug” juntos en una herramienta. El mantenedor ejecutó el comando. El atacante obtuvo credenciales. Fin de la historia. Cubrimos ese tema en detalle en ejecutar herramientas de forma aislada.

Cómo el malware se propagó: CanisterWorm

Una vez que el atacante comprometió Axios, no necesitó acceso manual a otros 47 paquetes. Usó CanisterWorm, un gusano de auto-propagación. Así funciona:

• El script postinstall de Axios maliciosa extrae credenciales npm del desarrollador (token en ~/.npmrc).
• Usa esas credenciales para acceder a otros paquetes que el desarrollador mantiene o para los que tiene permisos.
• Inyecta el mismo postinstall hook en esos paquetes.
• Publica versiones nuevas con el malware.
• Repite el proceso con cada nueva máquina que instala npm.

La elegancia del ataque es que no necesita ser sofisticado. Cada desarrollador comprometido se convierte en un vector de propagación. Y como npm tiene un modelo de confianza basado en “si lo publicaste vos, es tuyo”, no hay verificación adicional. El gusano se propaga exponencialmente. Subís el modelo, lo probás en local, funciona bárbaro, lo mandás a producción y de repente el atacante tiene acceso a las credenciales de Amazon de tu empresa.

En 47 casos, el proceso funcionó. En potencialmente miles más, falló porque el desarrollador no tenía permisos o porque npm detectó algo raro. Pero no lo sabemos porque npm no publica reportes de intentos bloqueados.

Datos robados y alcance real del impacto

¿Qué se robó exactamente? Credenciales. Tons de credenciales. Tokens de GitHub con acceso a repositorios privados. Credenciales de AWS, GCP, Azure. Certificados SSH. Archivos .docker/config.json. Configuraciones de Kubernetes. Algunos atacantes incluso robaron archivos de proyectos completos (.git history, código fuente no publicado, comentarios internos con más credenciales).

¿Cuál es el alcance? Todavía no sabemos. Trivy tiene 100.000+ usuarios. Axios tiene 100 millones de descargas semanales. Pero no todos descargaron la versión maliciosa. No todos instalaron npm actualizaciones automáticas. No todos ejecutaban Trivy en máquinas con credenciales sensibles.

Las estimaciones varían. Google dice que potencialmente decenas de miles de empresas fueron impactadas. Mandiant dice que podría ser 50.000+ considerando Axios sola. Microsoft reporta que al menos 15.000 máquinas ejecutaron código malicioso de Trivy en las primeras 48 horas. Y eso que fue detectado rápido.

Lo que nadie está diciendo abiertamente pero todos temen: los atacantes pueden estar esperando. Pueden tener acceso a 100.000 máquinas y no exfiltrar datos hasta dentro de tres meses. O pueden vender el acceso a otro grupo criminal. O pueden usar las credenciales para atacar objetivos específicos (empresas de defensa, bancos, infraestructura crítica). La explosión de daño puede ocurrir cuando menos la esperes.

Cómo protegerse: mitigación inmediata y a largo plazo

Inmediato (hoy mismo):

Si instalaste cualquier versión de Trivy o Axios entre el 19 y el 31 de marzo, actualizá. Las versiones corregidas están disponibles. Rodá tus credenciales: cualquier token de GitHub, credencial de AWS, secret de Kubernetes que estuviese en la máquina donde corriste Trivy o Axios. Si no sabés qué máquinas fueron afectadas, asumir que todas fueron afectadas es lo prudente. Complementá con alternativas más seguras a repositorios.

Ejecutá un escaneo de seguridad de tus repositorios privados. Si hubo acceso no autorizado, debería haber logs. Checkea tus cloudtrails de AWS, activity logs de GCP, audit logs de Azure. Un atacante que roba credenciales generalmente las usa dentro de 24-48 horas para reconocimiento. Si ves acceso desde IPs inusuales, desde horarios raros, o hacia recursos que nunca accediste antes, probablemente fuiste afectado.

Largo plazo:

Implementá SBOMs (Software Bill of Materials) en todo tu stack. Un SBOM es una lista exhaustiva de cada dependencia, versión y hash de cada librería que usas. Si descubrís que una dependencia fue comprometida, podés buscar en tu SBOM en 10 segundos qué aplicaciones la usan. Ojo, no es una solución mágica, pero es un primer paso.

Requierí firma de código. No descargues npm packages a menos que el mantenedor haya firmado el tarball con su clave privada. npm Provenance (disponible en 2026) permite verificar que un package fue publicado desde un repositorio específico. Usalo.

Segregá credenciales por contexto. No almacenes tu token de GitHub global en .npmrc. Usá credenciales de corta duración (temporal credentials) para CI/CD. Usa IAM roles y OIDC en lugar de almacenar secrets. Así, si el atacante roba un token, expira en 15 minutos en lugar de tener acceso perpetuo.

Monitorea tu cadena de suministro. Herramientas como Snyk, Dependabot, o Software Composition Analysis (SCA) te avisan si instalaste una librería que tiene vulnerabilidades conocidas o ha sido removida de npm. No es perfecto, pero es mejor que nada.

Tabla comparativa: Trivy vs Axios

Errores comunes al responder a supply chain attacks

Creer que “actualizar la librería” es suficiente

No lo es. Si un atacante estuvo dentro de tu máquina, actualizando Axios no expulsa al atacante. El malware ya robó tus credenciales, ya puede haber establecido backdoors adicionales, ya puede estar durmiendo en background esperando órdenes. Actualizar detiene nuevas instalaciones del malware, pero no limpia lo que ya está adentro.

Asumir que “la mayoría de versiones no fueron afectadas”

Incorrecto. Con supply chain attacks, el costo de ser cauteloso es bajo y el costo de asumir es altísimo. Si no sabés exactamente cuáles máquinas ejecutaron versiones maliciosas, asumí que todas fueron afectadas. Rodá las credenciales de todas. Después podés investigar. La precaución es gratis; el compromiso es carísimo.

No checkear logs de acceso a recursos sensibles

Muchas empresas actualizan la librería y creen que están bien. Pero no mirar CloudTrail, EventLog, o audit logs es mirar para el otro lado. Si un atacante robó credenciales de AWS hace una semana, probablemente las usó para reconnaissance dentro de 24 horas. Si no checkeas si accedieron a tus datos, nunca vas a saber cuán profundo fue el compromiso. Los logs son tu única evidencia. Lo explicamos a fondo en validar integridad con pruebas automáticas.

Preguntas Frecuentes

¿Mi proyecto está afectado si use Axios o Trivy en marzo?

Depende de la fecha exacta y de qué versión instalaste. Si instalaste Axios entre el 31 de marzo y el 1 de abril a la tarde, sí. Trivy entre 19-20 de marzo de forma más definitiva. Pero npm actualiza automáticamente salvo que especifiques una versión exacta. Si usás “latest” o “^X.Y.Z”, probablemente descargaste la versión maliciosa en ese período. Checkea tu package-lock.json o yarn.lock para ver exactamente qué versión instalaste y cuándo.

¿Qué debo hacer si sé que corrí código malicioso?

Primero, rotá todas las credenciales que estuviesen en esa máquina. Token de GitHub, credenciales de cloud, SSH keys, todo. Segundo, checkea los logs de acceso a esas credenciales (CloudTrail, activity logs, audit logs) para ver si el atacante las usó. Tercero, considerá que ese código también pudo haber exfiltrado datos no credencial-específicos: código fuente, historiales de git, variables de entorno, archivos temporales. Cuarto, notificá a tu equipo de seguridad. No es para asustarse, es para que tengan contexto si hay anomalías en las próximas semanas.

¿Cómo sé si alguien más robó mis credenciales?

Un atacante que roba credenciales generalmente las usa dentro de 24-48 horas para reconocimiento. Busca acceso a CloudTrail, activity logs de GCP, o audit logs de Azure desde IPs sospechosas o en horarios inusuales. Busca acceso a recursos que nunca consultaste (DescribeInstances en EC2, buckets S3 listados, cambios de IAM). Si ves patrones raros, probablemente fuiste afectado. En ese caso, no solo rodá las credenciales, notificá a tu proveedor de cloud para que investiguen.

¿Es seguro usar npm, Docker Hub, y GitHub después de esto?

Sí, con cuidado. Los ataques no significan que npm o GitHub sean inseguros per se. Significan que la confianza en software de terceros requiere verificación. Implementá SBOMs, require firma de código, usa credenciales de corta duración, monitoreá cambios en dependencias. La seguridad no es evitar todas las herramientas; es usar herramientas con procesos defensivos. Si dejás de usar npm, te quedás sin acceso a 2 millones de librerías. La alternativa es defensiveness, no abstinencia.

¿Qué está confirmado y qué todavía es especulación?

Confirmado: Trivy y Axios fueron comprometidos en las fechas reportadas. Las versiones específicas (Trivy 0.69.4, Axios 1.14.1/0.30.4) contenían malware verificado. Los atacantes robaron credenciales. La propagación a 47+ paquetes npm ocurrió. Google atribuyó Axios a Corea del Norte basándose en telemetría.

Especulación / Pendiente de confirmación: El alcance exacto del compromiso (¿5.000 máquinas afectadas o 500.000?). Si hay backdoors adicionales más allá del malware detectado. Cuántos datos fueron exfiltrados realmente. Si Corea del Norte usó los datos para ataques posteriores (probablemente, pero no confirmado públicamente aún).

Conclusión

Marzo de 2026 fue el mes donde la seguridad de supply chain dejó de ser una preocupación de enterprise para convertirse en una crisis que tocó a cualquiera que escribiese código moderno. No fue un ataque aislado. Fue una campaña orquestada por dos actores diferentes que demostraron un nivel de sofisticación asombroso: ingeniería social, coordinación, auto-propagación.

Lo peligroso no es solo lo que pasó, es lo que pasará después. Los atacantes tienen credenciales de decenas de miles de desarrolladores. Los datos robados se van a usar durante semanas o meses para ataques personalizados contra objetivos de mayor valor. Las empresas que piensan “actualizamos la librería y ya” van a sorprenderse cuando vean acceso no autorizado en sus redes dos meses desde ahora.

La buena noticia es que podés defenderte. Requiere disciplina (SBOMs, firma de código, segregación de credenciales), pero es factible. La pregunta es si tu organización está dispuesta a pagar ese costo hoy para evitar un compromiso mañana. Los números sugieren que muchas no lo están. Esperemos estar equivocados.

Fuentes

• The Register — Two different attackers poisoned popular open source tools
• Aqua Security — Trivy supply chain attack: what you need to know
• Google Cloud — North Korea threat actor targets Axios npm package
• Palo Alto Networks Unit 42 — TeamPCP supply chain attacks
• Microsoft Security Blog — Detecting and defending against Trivy supply chain compromise