- ¿Qué ocurrió en el ataque a Axios a través de npm?
- Cómo una sola línea en el archivo package.json se convirtió en el vector de ataque
- Por qué la revisión de código tradicional no detectó el ataque a Axios
- ¿Por qué el radio de la explosión abarca todo lo que toca el paquete?
- ¿Qué medidas de seguridad habrían cambiado el resultado?
- Más información sobreSupply Chain Software
- Preguntas frecuentes
El secuestro de paquetes npm es un ataque a la cadena de suministro de software que convierte la confianza depositada en un paquete en la vía de ataque. Los atacantes no necesitan modificar el código del repositorio si pueden controlar la cuenta que publica el paquete.
Eso es lo que convierte a los paquetes de npm de confianza en una superficie de ataque tan vulnerable. Cuando se compromete la cuenta de un mantenedor, todos los proyectos que instalan el paquete afectado pueden quedar expuestos mediante una simple actualización de dependencias. El incidente de Axios de marzo de 2026 demostró cómo una sola cuenta de npm comprometida podía poner en riesgo más de 100 millones de descargas semanales sin que se produjeran cambios visibles en el código fuente de Axios.
Comprender cómo funciona el secuestro de paquetes de npm ayuda a los equipos de seguridad a implementar controles que aborden la ruta real del ataque, en lugar de limitarse únicamente a los archivos fuente que revisan la mayoría de los equipos.
¿Qué ocurrió en el ataque a Axios a través de npm?
El ataque a Axios en npm consistió en la apropiación de la cuenta de un mantenedor, lo que convirtió un paquete de confianza en un mecanismo de distribución de malware. El atacante comprometió la cuenta de npm del mantenedor principal de Axios, cambió el correo electrónico registrado por una dirección controlada por él y bloqueó el acceso al mantenedor legítimo.
La operación fue planificada y deliberada. Se publicó un paquete señuelo unas 18 horas antes de que se activara la carga maliciosa, creando un historial de publicaciones que no despertó sospechas inmediatas. A continuación, en unos 39 minutos, el atacante publicó dos versiones maliciosas: axios 1.14.1 para la rama de versiones modernas y axios 0.30.4 para la rama heredada.
Ambas líneas de lanzamiento se programaron para salir al mismo tiempo con el fin de maximizar la difusión. Esa decisión aumentó la probabilidad de que tanto los entornos actuales como los antiguos descargaran un paquete malicioso a través del proceso de actualización estándar.
Cómo una sola línea en el archivo package.json se convirtió en el vector de ataque
Un simple cambio en las dependencias de package.json puede convertirse en la vía de ataque completa en un ataque a la cadena de suministro de npm. En el incidente de Axios, no fue necesario modificar ningún archivo fuente de Axios, ya que el comportamiento malicioso se introdujo a través de una nueva dependencia.
Esa dependencia se ejecutaba a través de un gancho «postinstall» de npm. Tan pronto como una estación de trabajo de un desarrollador, un proceso de CI/CD o un sistema de compilación ejecutaba «npm install», el paquete malicioso podía conectarse a un servidor controlado por el atacante, recuperar una carga útil específica para el sistema operativo y comenzar su ejecución.
Las cargas útiles se prepararon para macOS, Windows y Linux. El ataque fue multiplataforma por diseño. Tras ejecutarse, el dropper borró todo rastro de sí mismo y sustituyó el archivo package.json original por una versión falsificada, lo que dificultó enormemente el análisis forense posterior.
Por qué la revisión de código tradicional no detectó el ataque a Axios
La revisión de código tradicional está diseñada para inspeccionar los cambios en el código fuente dentro de un repositorio, pero esta vía de ataque no se encontraba en el código fuente de Axios. El ataque a Axios no se basaba en cambios visibles en el repositorio, ya que la lógica maliciosa se encontraba en una dependencia independiente y no en el código fuente de Axios.
Esa diferencia es importante. Un revisor que examinara la actualización del paquete apenas vería algo más que una nueva línea de dependencia en el archivo package.json. El comportamiento malicioso real solo se manifestaba una vez que se resolvía e instalaba la dependencia.
Por eso es difícil detectar los ataques a paquetes de confianza solo mediante revisiones basadas en comparaciones. La vía de ataque se encuentra fuera de los archivos fuente que revisan la mayoría de los equipos, aunque el paquete siga pareciendo lo suficientemente legítimo como para pasar por los flujos de trabajo habituales de desarrollo.
¿Por qué el radio de la explosión abarca todo lo que toca el paquete?
El alcance de los efectos de un paquete npm comprometido no es el paquete en sí mismo. El alcance de los efectos es todo aquello con lo que el paquete entra en contacto.
Para la mayoría de las organizaciones, esto incluye procesos de CI/CD con permisos elevados, puntos de acceso de desarrolladores con claves SSH y tokens de nube, servidores de compilación con acceso de escritura a repositorios de artefactos, y herramientas de implementación conectadas a los sistemas de producción. Un paquete malicioso no necesita permanecer dentro del árbol de dependencias para causar daños. Solo necesita un punto de ejecución de confianza.
Por eso el incidente de Axios tiene importancia más allá de la gestión de paquetes de JavaScript. Una vulnerabilidad tras la instalación puede convertir una instalación normal en un robo de credenciales, un movimiento lateral o un acceso a la infraestructura posterior.
Las deficiencias estructurales que puso de manifiesto el ataque a Axios
El incidente de Axios puso de manifiesto unas deficiencias estructurales que son habituales en los entornos modernos de desarrollo de software. No se trata de casos aislados y poco frecuentes, sino de supuestos que se dan por sentados en muchas organizaciones.
Confianza en las identidades de los responsables de paquetes
La confianza en un paquete de npm suele basarse en la cuenta del mantenedor que publica el paquete. Si esa cuenta es objeto de un robo o de un ataque de phishing, el atacante adquiere la misma autoridad de publicación que el mantenedor legítimo.
Versiones variables de las dependencias
Las versiones flotantes o fijadas de forma no permanente aumentan la exposición a versiones maliciosas. Una versión comprometida recién publicada puede introducirse en un entorno de forma automática sin que se requiera un paso de aprobación deliberado.
Scripts de posinstalación no supervisados
Los scripts de postinstalación de npm pueden ejecutar código arbitrario con los permisos del proceso de instalación. Muchas organizaciones no revisan ni restringen los scripts del ciclo de vida antes de su ejecución.
Pipelines de CI/CD con visibilidad limitada del tiempo de ejecución
Los procesos de CI/CD suelen tener un amplio acceso a los sistemas internos, a la infraestructura de compilación y a los entornos en la nube. A menudo se confía en ellos por defecto y rara vez se supervisan para detectar comportamientos maliciosos de los paquetes en el momento de la instalación.
Puntos de acceso de desarrolladores fuera del ámbito de la cobertura de seguridad completa
Los equipos de los desarrolladores almacenan activos de gran valor, como claves SSH, credenciales de la nube y tokens corporativos. Los terminales de los desarrolladores también son objetivos habituales de los ataques, ya que suelen tener menos visibilidad y menos controles de tiempo de ejecución que los sistemas de producción.
Almacenes de credenciales sin desencadenantes de rotación rápida
Un ataque a la cadena de suministro de software suele derivar en una filtración de credenciales. Muchos equipos aún no cuentan con flujos de trabajo fiables que identifiquen los datos confidenciales que podrían verse expuestos y los cambien de inmediato.
¿Qué medidas de seguridad habrían cambiado el resultado?
Tres categorías de controles de seguridad habrían reducido considerablemente el impacto del ataque a Axios. Cada control aborda un punto diferente de la cadena de ataque: la ejecución de paquetes, la exposición de credenciales y la visibilidad de las dependencias.
1. Análisis de malware a nivel de paquete antes de la instalación
El análisis de malware a nivel de paquete ayuda a detener las dependencias maliciosas antes de que se ejecuten. Esto es importante en los ataques a npm, ya que los hooks de postinstalación se ejecutan durante la instalación, lo que deja poco tiempo para una revisión manual una vez que se ha descargado el paquete.
El análisis de paquetes, dependencias y scripts de ciclo de vida antes de la instalación permite detectar malware conocido, comportamientos sospechosos, vulnerabilidades y secretos codificados de forma estática antes de que el paquete llegue al terminal de un desarrollador o a un entorno de CI/CD.
MetaDefender Software Supply Chain es la solución de seguridad de la cadena de suministro de software OPSWATpara validar componentes de software, proveedores y procesos de compilación. Utiliza la detección de amenazas con múltiples motores, incluido el escaneo múltiple Metascan a través de más de 30 motores antivirus, para inspeccionar los paquetes en busca de malware, vulnerabilidades y secretos codificados de forma rígida antes de que entren en el ciclo de vida del desarrollo.
2. Gestión proactiva de secretos con desencadenantes de rotación
Una gestión proactiva de los secretos reduce el valor de un ataque que haya tenido éxito. Cuando se identifica un paquete sospechoso, los equipos necesitan un procedimiento de respuesta que considere que las credenciales locales, las claves SSH, los tokens y los secretos de los procesos de automatización están potencialmente expuestos, y que los renueve rápidamente.
La detección de secretos codificados de forma estática contribuye al mismo objetivo. Un paquete malicioso puede sustraer secretos de la memoria o del disco, pero los secretos expuestos que ya están presentes en el código o en las dependencias añaden otra capa de riesgo que se puede prevenir.
3. Supply Chain y supervisión de las dependencias
La visibilidad de la cadena de suministro ayuda a los equipos a detectar cambios inesperados en los paquetes antes de que se conviertan en incidencias en fases posteriores del proceso. Los equipos de seguridad necesitan saber qué paquetes están instalados, qué versiones están fijadas, qué nuevas dependencias han aparecido y dónde se están ejecutando esos componentes.
Sin visibilidad ni supervisión de las dependencias, el primer indicio de una intrusión podría ser el uso indebido de credenciales o el uso indebido de la infraestructura, mucho después de que la instalación inicial haya quedado en el olvido.
Más información sobreSupply Chain Software
La seguridad de la cadena Software depende de la inspección de los paquetes antes de su ejecución, la supervisión de las nuevas dependencias y la reducción de la exposición de las credenciales que se produce tras el compromiso de un paquete.
Vea el seminario web bajo demanda:Supply Chain Software : los puntos débiles que aprovechan los atacantes»
Preguntas frecuentes
¿Qué es un ataque a la cadena de suministro de npm?
Un ataque a la cadena de suministro de npm consiste en la distribución de código malicioso a través del ecosistema de npm durante las actividades habituales de desarrollo de software. Los atacantes suelen lograrlo comprometiendo la cuenta de un mantenedor, publicando un paquete engañoso o insertando código malicioso en las dependencias que los desarrolladores y los sistemas de CI/CD instalan automáticamente.
¿Cómo lograron los atacantes comprometer el paquete npm de Axios?
Los atacantes comprometieron la cuenta de npm del mantenedor principal de Axios y utilizaron ese acceso de publicación para lanzar versiones maliciosas en las ramas de versiones 1.x y 0.x. Los atacantes también cambiaron el correo electrónico de la cuenta por una dirección controlada por ellos, lo que les permitió mantener el control del paquete.
¿Qué hizo el malware en el ataque a Axios?
El malware utilizado en el ataque a Axios empleó un gancho de postinstalación que se ejecutaba durante el proceso «npm install». El gancho se conectaba a un servidor controlado por el atacante, descargaba un troyano de acceso remoto para macOS, Windows o Linux, lo ejecutaba y, a continuación, intentaba borrar cualquier rastro sustituyendo los metadatos del paquete por contenido falsificado.
¿Por qué la revisión del código no detectó el ataque a la cadena de suministro de Axios?
La revisión del código no detectó el ataque de Axios porque la lógica maliciosa no se introdujo en el código fuente de Axios. El único cambio visible a nivel del repositorio fue una entrada de dependencia en el archivo `package.json`, mientras que el malware propiamente dicho se introdujo a través de un paquete externo, fuera del ámbito habitual de la revisión del código fuente.
¿Cómo pueden las organizaciones detectar paquetes npm maliciosos antes de su instalación?
Las organizaciones pueden detectar paquetes npm maliciosos antes de su instalación mediante el análisis del contenido de los paquetes, los árboles de dependencias y los scripts de ciclo de vida antes de su ejecución. Los controles eficaces combinan el análisis de malware, el análisis de dependencias, la aplicación de políticas y la integración con CI/CD, de modo que los paquetes sospechosos puedan bloquearse antes de llegar a los entornos de desarrollo o de compilación.
¿El bloqueo de versiones previene los ataques a la cadena de suministro de npm?
La fijación de versiones reduce la exposición a versiones maliciosas recién publicadas, ya que limita las actualizaciones automáticas. La fijación de versiones no elimina el riesgo de la cadena de suministro, ya que una versión fijada puede estar ya comprometida o pueden seguir existiendo otros fallos de confianza. La fijación de versiones funciona mejor cuando se combina con la verificación de la integridad, la inspección de paquetes y los controles en tiempo de ejecución.
