Anatomía del compromise de Axios npm (mar 2026): lecciones de un supply chain attack que afectó a miles
El 31 de marzo Microsoft confirmó lo que el equipo de seguridad de npm venía investigando desde la noche anterior: las versiones 1.14.1 y 0.30.4 de Axios, una de las librerías HTTP más usadas del ecosistema JavaScript, fueron publicadas comprometidas con código malicioso. La atribución fue rápida y poco ambigua: Sapphire Sleet, un actor estatal asociado a la República Popular Democrática de Corea (Corea del Norte), responsable de varias campañas previas contra cadenas de suministro de software.
El incidente no es un caso aislado. Apenas dos semanas antes, en marzo, había caído TeamPCP con la CVE-2026-33634 (CVSS 9.4), un ataque a la cadena de suministro que terminó comprometiendo herramientas tan populares como Trivy, KICS, LiteLLM y Telnyx. Para las empresas mexicanas que están corriendo cualquier stack moderno, el patrón es claro: 2026 está siendo un año de ataques sostenidos al primer eslabón de la cadena.
Cronología del ataque a Axios
Reconstruimos lo que se sabe, con base en el postmortem público de npm y los reportes de Microsoft Threat Intelligence:
Día -7. Una cuenta de mantenedor con permisos de publicación recibe un correo de phishing dirigido, con un señuelo profesional (oferta laboral en una empresa de cripto, modus operandi típico de Sapphire Sleet).
Día -3. El mantenedor instala lo que cree que es un cliente para una "entrevista técnica". El instalador es un troyano que busca y exfiltra credenciales locales, incluyendo el token npm guardado en .npmrc.
Día 0 (madrugada del 31 mar). Los atacantes publican versiones nuevas de Axios usando el token comprometido. Las versiones contienen el código original más un postinstall script que descarga un loader de segunda etapa.
Día 0 (mañana). Pipelines de CI/CD alrededor del mundo, configurados para tomar la última versión, descargan la versión comprometida. El loader busca tokens AWS, GCP, GitHub, npm, variables de entorno con secretos y los exfiltra a un C2.
Día 0 (tarde). Sistemas automatizados de análisis (Socket, Snyk, npm audit) detectan comportamiento anómalo. Microsoft confirma. npm despublica las versiones afectadas.
El intervalo entre publicación y mitigación pública fue de aproximadamente 9 horas. Para una empresa con CI corriendo cada commit, eso fue tiempo suficiente para que pipelines descargaran el paquete y filtraran credenciales.
Qué hace exactamente el payload
El postmortem público describe tres comportamientos:
- Exfiltración de variables de entorno que coincidan con patrones comunes de credenciales (
AWS_*,GITHUB_*,NPM_TOKEN,*_API_KEY). - Lectura de archivos de credenciales locales (
~/.aws/credentials,~/.npmrc,~/.docker/config.json). - Persistencia ligera en máquinas de desarrollo: agregar una entrada al perfil del shell que reactivaba la exfiltración periódica.
Lo que no hizo: alterar el comportamiento HTTP visible de Axios. La librería seguía funcionando normalmente. Esto es típico: los atacantes no quieren que falle, quieren que pase desapercibido el mayor tiempo posible.
Por qué el ecosistema npm sigue siendo el blanco favorito
Tres razones estructurales:
- Volumen. Cualquier app moderna en JS arrastra centenares de dependencias transitivas. La superficie de ataque es enorme.
- Velocidad de adopción. Una nueva versión publicada a las 3 AM puede estar en miles de pipelines a las 9 AM, antes de que cualquier humano la haya revisado.
- Mantenedores aislados. Muchos paquetes críticos los mantienen una o dos personas, sin equipo de seguridad detrás. Comprometer una cuenta es suficiente.
PyPI, RubyGems y Cargo enfrentan dinámicas similares. npm es el más visible por tamaño.
Mitigaciones que sí hubieran bloqueado el ataque
No es realista pensar que una empresa mediana puede prevenir todo ataque a la cadena de suministro. Pero hay un conjunto de controles que, combinados, reducen drásticamente el impacto. Lo que recomendamos en ALCA después de cada incidente como este:
1. Lock files versionados y respetados
package-lock.json (o yarn.lock, pnpm-lock.yaml) versionado en git, con CI que falla si el lock file no está actualizado. Esto evita que npm install agarre versiones nuevas sin revisión humana. Suena básico; muchas pipelines aún corren npm install sin lock o con --no-package-lock.
2. Audit automático en cada PR y cada deploy
npm audit (o equivalente) corriendo en cada pull request, con bloqueo automático si aparecen vulnerabilidades críticas. Herramientas comerciales (Snyk, Socket, Mend) añaden detección de comportamiento anómalo, no solo CVEs publicadas. En el caso Axios, varias de estas herramientas detectaron el comportamiento dentro de las primeras horas.
3. Allowlist explícita de dependencias
Mantener una lista de dependencias aprobadas y bloquear la incorporación de nuevas sin revisión. Esto frena el reflejo de "le pongo este paquetito que vi en Stack Overflow". Para proyectos críticos vale la pena el overhead.
4. SBOM generado en cada build
Software Bill of Materials por release. Cuando algo cae, en lugar de pasar tres días averiguando qué proyectos usan la versión comprometida, se ejecuta una consulta sobre los SBOM y se sabe en minutos.
5. Segregación de credenciales en CI
Las credenciales de producción no viven como variables de entorno globales en el runner. Se inyectan justo en el paso que las necesita, con scope mínimo, y se rotan automáticamente después. Si un payload malicioso corre en un step previo, no encuentra nada útil.
6. Cuentas npm protegidas
Si tu empresa publica paquetes propios, el equivalente del lado mantenedor: 2FA obligatorio (con hardware key, no SMS), tokens granulares por proyecto, rotación trimestral, alertas de publicación a un canal compartido.
7. Mirroring interno con cuarentena
Para empresas con apetito de inversión, montar un proxy interno (Verdaccio, Nexus, Artifactory) que no expone una versión nueva sino hasta que pasaron N horas sin reporte de problemas. Ese delay corta la ventana de los ataques rápidos como Axios.
Plan de respuesta para una empresa mediana
Si descubres ahora que tu pipeline jaló una versión comprometida (de Axios o de cualquier paquete), el orden:
Hora 0. Bloquear despliegues automáticos. Aislar máquinas que corrieron npm install con la versión sospechosa.
Hora 0-2. Inventario rápido: qué entornos, qué credenciales estaban expuestas. Empezar la rotación de las que pudieron filtrarse (AWS, GitHub, npm, secretos en variables de entorno).
Hora 2-6. Revisar logs de los servicios cuyas credenciales se rotaron, buscando uso anómalo entre el momento del compromiso y la rotación.
Hora 6-24. Reconstruir builds con la versión limpia (downgrade a una anterior conocida buena, o upgrade a una posterior parcheada). Despliegue controlado.
Días 1-7. Postmortem interno. Qué controles fallaron, qué controles faltaban, qué se cambia en el pipeline. Si hubo evidencia de uso de credenciales filtradas, escalar a respuesta a incidentes formal.
La lectura larga
Los ataques de cadena de suministro no van a parar. Lo que cambia año con año es la sofisticación de los actores y la velocidad con que se ejecutan. Sapphire Sleet es un grupo financiado por un estado, con tiempo y paciencia para campañas de meses. La defensa no se gana con una sola herramienta sino con capas: process, lock files, audit automático, SBOM, segregación de credenciales, mirroring interno.
Las empresas mexicanas que llegan al segundo semestre con un pipeline endurecido van a vivir los próximos incidentes (y vendrán) como noticias, no como crisis internas.
En ALCA acompañamos a empresas mexicanas con este tipo de decisiones. ¿Tu pipeline de CI tiene controles para supply chain attacks? Hagamos un assessment. Agenda 30 minutos sin costo.
