Axios se volvió loco durante tres horas, y los 100 millones de descargas semanales ni se dieron cuenta

Principales conclusiones

• Las versiones maliciosas de Axios estuvieron activas solo unas tres horas, por lo que las instalaciones realizadas antes de que se detectaran no se beneficiaron de las defensas basadas en los avisos de seguridad.
• El número de descargas mide la adopción, no las revisiones, y Axios puede llegar a través de paquetes que un equipo nunca haya seleccionado.
• Habría varios controles que podrían haber roto esta cadena, desde instalaciones bloqueadas y scripts de instalación bloqueados hasta ventanas de cuarentena, comprobaciones de procedencia y análisis del registro.
• Las medidas preventivas más eficaces se aplican en el momento de la instalación o antes, que es precisamente donde muchos equipos han invertido menos.

El 31 de marzo de 2026 se publicaron dos versiones maliciosas de axios, que permanecieron activas durante unas tres horas antes de que alguien las retirara. En ese lapso de tiempo, se colaron discretamente en los árboles de dependencias de una gran parte del ecosistema de JavaScript, y casi nadie que las instalara tuvo forma de darse cuenta.

Nadie del proyecto las publicó. Las versiones se publicaron desde una cuenta de mantenedor que había sido secuestrada, de forma manual con un token de larga duración robado que eludió el propio proceso de integración continua (CI) del proyecto, por lo que en el registro parecían versiones normales de axios. Los números de versión parecían normales. npm audit no dio ningún resultado durante el primer tramo del periodo, ya que aún no se había redactado el aviso que finalmente describiría el incidente.

Tres horas en el interior de un ataque a la cadena de suministro de npm

Tres horas no es mucho tiempo. No es tiempo suficiente para que la mayoría de los equipos se den cuenta de que se ha publicado una nueva versión, y mucho menos para evaluarla.

El esquema general de una vulnerabilidad en el lado de la publicación está bien documentado, y Axios siguió ese esquema añadiendo una capa adicional que no incluye la versión genérica. Ambas versiones incorporaron una dependencia totalmente nueva llamada plain-crypto-js, que no existía más que para ejecutar una carga útil desde un gancho de postinstalación. Unas 18 horas antes se había publicado una versión señuelo limpia de ese paquete, lo que hacía que la versión maliciosa posterior no pareciera algo totalmente nuevo, y los propios archivos fuente de axios nunca fueron modificados. La ingeniería social permitió al atacante acceder primero al equipo del mantenedor, lo que le otorgó los derechos de publicación.

La fase interesante es la propagación. Entre la publicación y el descubrimiento, la ruta predeterminada de «npm install» nunca exige a un paquete que demuestre que el artefacto que se descarga se ha compilado a partir del código fuente y el flujo de trabajo que afirma tener. Esa brecha constituye toda la ventana de ataque.

Wiz observó que el malware se ejecutaba realmente en alrededor del 3 % de los entornos afectados que aparecieron en sus datos de telemetría, y los investigadores estimaron por separado ventana de exposición en unas 600 000 descargas. Ambas cifras proceden de poblaciones diferentes, por lo que multiplicarlas entre sí no arroja una cifra real. Sin embargo, si se analizan conjuntamente, describen una ejecución confirmada de la carga útil dentro de un periodo de exposición muy breve, y no se trata simplemente de archivos almacenados en el disco.

Análisis de la situación: Retirar una versión maliciosa impide futuras instalaciones. No tiene ningún efecto sobre los equipos que ya la hayan ejecutado, los tokens que ya hayan sido sustraídos ni las imágenes de contenedor ya compiladas y distribuidas con el código malicioso incorporado.

Por qué 100 millones de descargas semanales no son un indicador de seguridad

La suposición tácita que subyace a la elección de dependencias populares es que la popularidad implica un mayor escrutinio. Cuantos más ojos, menos errores graves; esa línea de razonamiento.

Es un argumento razonable en lo que respecta al código fuente. Sin embargo, no se sostiene en lo que se refiere a la integridad de la publicación, ya que la atención se centra en el repositorio, mientras que el ataque se produce en el registro. Se trata de dos elementos distintos, y npm no exige que coincidan. Esa noche había muchos escáneres vigilando y varios de ellos detectaron el problema en cuestión de minutos. No hay nada en la ruta de instalación predeterminada que les haga esperar.

Hay un segundo problema, y es el que hace que sea tan molesto tener que hacer frente a este tipo de incidentes. Algunos equipos nunca instalaron Axios directamente. Instalaron algo que, a su vez, instaló otra cosa que, a su vez, instaló Axios.

Una investigaciónde Endor Labs citada en el «Top 10» de OWASP para software de código abierto sitúa la proporción de vulnerabilidades que se encuentran en dependencias indirectas en aproximadamente el 95 % en lugar de en los paquetes que un equipo elige deliberadamente. Esa cifra tiene en cuenta las vulnerabilidades conocidas, no el malware, pero muestra qué parte del grafo de dependencias se encuentra fuera de los paquetes que los desarrolladores eligen a propósito, y esos grafos no se han simplificado en absoluto. Cuando el paquete comprometido se encuentra cuatro capas más abajo en un grafo que nadie ha leído realmente, la pregunta «¿Acaso utilizamos axios?» se convierte en algo sorprendentemente difícil de responder rápidamente.

npm ls axios –all

npm ls plain-crypto-js –all

Ejecútalos en todos los repositorios, no solo en aquellos a los que recuerdes haber añadido un cliente HTTP. Si alguno de ellos devuelve axios 1.14.1 o 0.30.4, o plain-crypto-js 4.2.1, considera que el servidor está comprometido y vuelve a utilizar axios 1.14.0 o 0.30.3, y renueva todas las credenciales a las que ese servidor pudiera acceder.

¿Qué quería un agente estatal con un cliente HTTP?

El Grupo de Inteligencia sobre Amenazas de Google atribuyó el ataque a Axios a UNC1069, un actor vinculado a Corea del Norte con motivaciones económicas y un historial de robos en plataformas de intercambio de criptomonedas. Microsoft rastrea la actividad solapada bajo el nombre de «Sapphire Sleet», mientras que otros investigadores asocian la actividad relacionada con nombres como «BlueNoroff» y «Stardust Chollima». Un cliente HTTP parece un objetivo extraño para un grupo dedicado a ese tipo de actividades, hasta que te paras a pensar en lo que se puede obtener al comprometerlo.

Equipos de desarrolladores y agentes de compilación, a gran escala; y esos equipos contienen credenciales de roles en la nube, tokens de registro, claves de firma y código fuente de productos que aún no se han lanzado al mercado. Centrarse en las herramientas de los desarrolladores en lugar de directamente en la producción es un patrón que también se repite en campañas anteriores de npm, y funciona porque las estaciones de trabajo de los desarrolladores y los agentes de compilación contienen credenciales con un acceso a niveles posteriores inusualmente amplio.

El Informe sobre investigaciones de filtraciones de datos de Verizon de 2026 reveló que el aprovechamiento de vulnerabilidades ha superado al robo de credenciales como principal vector de acceso inicial, representando el 31 % de las filtraciones, frente al 13 % correspondiente al uso indebido de credenciales. Sin embargo, las credenciales no han dejado de ser importantes. Siguen siendo uno de los elementos más comunes una vez que la intrusión está en marcha, y un ataque que extrae tokens de miles de entornos de compilación es precisamente el tipo de acción que mantiene ese suministro al máximo.

Shai-Hulud y la evolución hacia el malware autopropagable

Axios fue un caso aislado. Las campañas de gusanos son algo totalmente distinto.

Shai-Hulud sentó las bases en septiembre de 2025 con un código malicioso que, una vez que se ejecuta en un entorno de desarrollo o de integración continua (CI), busca información confidencial, localiza tokens de publicación de npm y los utiliza para introducirse en más paquetes. Una campaña relacionada conocida como Mini Shai-Hulud , comenzó el 29 de abril de 2026 y continuó con dos oleadas más en mayo. A mitad de camino, TeamPCP publicó el código fuente del gusano en GitHub, y eso es algo que, una vez hecho, ya no tiene vuelta atrás.

La mecánica es más importante que la marca. Una campaña que se propaga por sí sola convierte a cada víctima con derechos de publicación válidos en otro punto de distribución, por lo que el número de paquetes afectados sigue aumentando sin que el atacante tenga que mover un dedo más.

Atención: El escaneo encubierto tiene dos caras. Varias campañas de gusanos incluían escáneres encubiertos disponibles en el mercado, como TruffleHog, para buscar credenciales en los equipos infectados; se trata de las mismas herramientas que utilizan los defensores, solo que orientadas en la dirección contraria.

Esa curva de crecimiento es el argumento a favor de los puntos de control que no dependen de saber de antemano qué paquetes son maliciosos. Analizar los paquetes antes de que se resuelvan y comparar los artefactos publicados con el código fuente verificado permite detectar clases enteras de vulnerabilidades sin tener que esperar a que se publique un aviso de seguridad. Ese es el razonamiento que subyace a SecureChain para npm.

Mastra y jscrambler mantuvieron la racha

Dos incidentes posteriores, ocurridos en 2026, dejaron claro que lo de marzo no había sido un caso aislado. La toma de control del paquete Mastra AI el 17 de junio y el ataque a jscrambler el 11 de julio se produjeron ambos a través de un acceso por el lado de la publicación, en lugar de una vulnerabilidad presente en el código de algún usuario.

Microsoft atribuyó el ataque a Mastra a «Sapphire Sleet», el nombre que le da a la actividad que Google identifica como UNC1069. Aproximadamente once semanas después del incidente de Axios, el mismo grupo volvió a la carga con un modus operandi muy similar. Se utilizó una antigua cuenta de colaborador que aún conservaba derechos de publicación en el ámbito de @mastra para volver a publicar más de 140 paquetes, y el único cambio en cada uno de ellos fue la adición de una única dependencia llamada easy-day-js, una biblioteca similar a dayjs que contenía un gancho malicioso de postinstalación. El código de la biblioteca no se modificó en absoluto, que es exactamente lo que ocurrió con axios.

Sonatype informó de más de 454 600 nuevos en npm, PyPI y otros registros solo en 2025, por lo que el volumen no es nada nuevo. Lo que pone de manifiesto esta oleada reciente es la rapidez con la que el acceso comprometido a los servidores de publicación convierte ese volumen en algo que llega a la fase de compilación.

¿Qué lo habría detenido realmente?

A continuación se presentan seis controles propuestos, que se han evaluado de forma imparcial en relación con un incidente de seguridad en el lado de la publicación que duró tres horas.

–ignore-scripts se ganó su lugar, y desde entonces el ecosistema se ha adaptado a ello. npm 12 se lanzó el 8 de julio de 2026 con los scripts de instalación de dependencias desactivados por defecto, incluido el implícito reconstrucción de node-gyp que se produce de forma implícita al utilizar un archivo binding.gyp solía activar, por lo que npm 12 bloquea esta carga sin que nadie tenga que acordarse de ningún indicador. Las dependencias que realmente necesitan scripts de instalación o de compilación nativa ahora deben aprobarse explícitamente, algo que merece la pena revisar detenidamente antes de que una actualización rompa silenciosamente un proceso de trabajo.

Sigue sin ser una solución general: el código malicioso que se encuentra en el cuerpo del módulo se ejecuta en el momento en que algo importa el paquete, independientemente de si el script está bloqueado o no. El ataque de jscrambler de julio es el ejemplo más claro de ello. Las primeras versiones maliciosas se ejecutaban desde un gancho de preinstalación y, a continuación, dentro de la misma ronda de publicación de tres horas, el atacante introdujo el mismo dropper en el propio código del paquete para que se activara al importar el paquete o al ejecutar su CLI. Bloquear los scripts de instalación es necesario. Pero no es suficiente.

La disciplina relacionada con los archivos de bloqueo requiere una advertencia más destacada, ya que es la medida de control que la mayoría de los equipos dan por sentado que ya tienen cubierta.

Atención: Un rango de carets como ^1.7.0 en package.json se resolverá sin problemas en una versión de parche maliciosa si no hay nada que la fije. Un archivo de bloqueo confirmado evita que eso ocurra, y npm ci es la forma más estricta de instalar a partir de uno, ya que se niega a ejecutarse cuando el archivo de bloqueo y package.json no coinciden, en lugar de cambiar la resolución sin avisar. La protección desaparece en el momento en que el archivo de bloqueo se regenera o se actualiza a una versión que incluye la vulnerabilidad. Muchos procesos de automatización pasan por alto al menos uno de estos pasos.

La procedencia resulta útil en este caso y, frente a este modo de fallo concreto, demuestra su utilidad.

¿Sabías que...? npm admite la certificación de procedencia basada en Sigstore para los paquetes publicados desde CI, y puedes comprobar lo que ya tienes con un solo comando: npm audit signatures.

Vale la pena precisar qué es lo que eso demuestra. La procedencia verifica que un artefacto proviene de la fuente y del flujo de trabajo de compilación que afirma, lo cual es una cuestión diferente y mucho más fácil de responder que si el código que contiene es malicioso. En el caso de axios habría sido de ayuda, ya que la última versión limpia de la serie 1.x incluía la procedencia y la maliciosa no, al haber sido publicada manualmente con un token robado en lugar de a través del flujo de trabajo de CI del proyecto. Sin embargo, no se trata de un control contra el malware. Las oleadas de 2026 de Mini Shai-Hulud distribuyeron paquetes maliciosos con una procedencia válida, ya que el proceso de compilación que los generó había sido realmente comprometido.

¿Qué hay que cambiar antes de la próxima?

Nada de esto requiere una reconstrucción de la plataforma. Elige en función de la situación actual de tu proceso de trabajo.

Si tus archivos de bloqueo no se han confirmado de forma coherente, corrige eso primero y cambia la integración continua a npm ci. Es uno de los controles más sencillos de la lista y habría evitado este incidente concreto de raíz.

Si ya estás ejecutando npm ci en todos los entornos, añade un periodo de cuarentena para las nuevas versiones. npm ha incorporado una opción nativa min-release-age desde la versión 11.10.0, y pnpm 11 cambia minimumReleaseAge activado en un día por defecto, aunque no fallará la instalación a menos que se establezca el valor manualmente, y Unit 42 recomienda retrasar cualquier publicación realizada en las últimas 24 a 72 horas , ya que la mayoría de los paquetes maliciosos se identifican y eliminan dentro de ese plazo. No habría detectado todo, ya que el gusano Shai-Hulud original tardó días en eliminarse por completo, pero cubre los casos más habituales.

Si publicas paquetes por tu cuenta, activa la trazabilidad y pasa a la publicación de confianza con OIDC en lugar de utilizar tokens de publicación de larga duración. El atacante de Axios eludió el flujo de trabajo habitual de publicación con OIDC del proyecto utilizando un token clásico robado, lo que constituye un argumento de peso para retirar por completo esos tokens. Formas parte de la cadena de suministro de otra persona, lo pienses así o no.

Y si tus agentes de compilación disponen de credenciales de roles en la nube, reduce su periodo de validez de forma prioritaria. Esa es la diferencia real entre una instalación defectuosa y un informe de incidente.

Lo problemático es que muchos de los controles preventivos más eficaces se aplican antes de que surja el problema o en el momento de resolverlo, mientras que la mayor parte de lo que los equipos ya han invertido está destinado a detectar los problemas a posteriori. Esto no es una crítica al análisis de la composición del software, que cumple con la función para la que fue diseñado. Se trata de un problema de sincronización, y los problemas de sincronización no se solucionan añadiendo simplemente otro análisis.

Tu experiencia variará en función de la rapidez con la que la organización necesite realmente nuevas versiones de las dependencias. Los equipos que lanzan herramientas de IA basadas en paquetes de origen que evolucionan rápidamente pagan un coste real por los periodos de cuarentena. Los equipos que trabajan con plataformas internas de evolución más lenta pagan un coste mucho menor y, a menudo, descubren que ya llevaban tres semanas de retraso en las versiones menores y que nadie se había dado cuenta.

El siguiente ya está disponible en algún sitio

Tres horas no parecen mucho tiempo hasta que se cuentan las instalaciones que se han producido en ese lapso. Esa es la verdadera lección que hay que extraer de todo esto, no la atribución a Corea del Norte ni la denominación del gusano. Se trata del lapso de tiempo que transcurre entre la publicación y el descubrimiento, y de lo poco que ocurre en él por defecto.

Axios llamó la atención. Las vulnerabilidades de menor importancia suelen recibir mucha menos atención. Se retiran del registro sin apenas revuelo, y quien ya las haya instalado tiene que averiguar por su cuenta en qué medida está expuesto. La siguiente, situada a cuatro niveles de profundidad en el árbol de dependencias de alguien, tampoco va a dar señales de sí misma.

El análisis basado en alertas funciona mejor cuando la amenaza ya es conocida. Detectar un ataque a la cadena de suministro de npm mientras aún se está produciendo implica realizar un filtrado en el momento de la instalación, en lugar de esperar a que los datos de las alertas identifiquen primero el paquete. Esa es la laguna SecureChain para npm está diseñado para subsanarla.

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 vulneración de un paquete en el registro antes de que llegue a tus manos, normalmente mediante el robo de credenciales de publicación, el secuestro de la cuenta de un responsable de mantenimiento o la suplantación de un espacio de nombres, y no por un fallo en tu propio código.

¿Qué pasó con la filtración de Axios?

El 31 de marzo de 2026 se publicaron dos versiones maliciosas de axios, la 1.14.1 y la 0.30.4, que fueron retiradas aproximadamente tres horas después. Ambas inyectaban una dependencia llamada plain-crypto-js que instalaba un troyano de acceso remoto multiplataforma desde un gancho de postinstalación. El Grupo de Inteligencia sobre Amenazas de Google atribuyó el ataque a UNC1069, y Microsoft rastrea la actividad relacionada con este grupo bajo el nombre de Sapphire Sleet. Las versiones limpias a las que se debe recurrir son la 1.14.0 y la 0.30.3.

¿Detecta npm audit los paquetes maliciosos?

Sus comprobaciones de vulnerabilidad dependen de los datos de los avisos del registro, por lo que no pueden avisarte de una versión recién comprometida hasta que dicha versión haya sido identificada y registrada. En el caso de axios, se publicó un aviso dentro del plazo de tres horas, pero no pudo revertir las instalaciones que ya se habían realizado. Las firmas de npm audit es una comprobación independiente y más útil en este caso, ya que verifica las firmas del registro y los certificados de procedencia.

¿Protege un archivo de bloqueo contra el secuestro de una versión de npm?

Un archivo de bloqueo comprometido impide que se resuelva una versión no esperada, y npm ci es la forma más estricta de realizar la instalación a partir de él, ya que se niega a continuar cuando el archivo de bloqueo y el package.json no coincidan. Esa protección desaparece cuando el archivo de bloqueo se vuelve a generar o se actualiza a una versión que incluye la solución de compromiso, y npm install es más flexible porque puede modificar la resolución y reescribir el archivo de bloqueo.

¿Qué es el gusano Shai-Hulud?

Una campaña de malware de npm que se propaga de forma autónoma, que recopila información confidencial de los entornos infectados, localiza los tokens de publicación de npm y los utiliza para introducirse en más paquetes, ampliando así el conjunto de sistemas afectados sin que el atacante tenga que hacer nada más. Su código fuente se publicó abiertamente en mayo de 2026, por lo que ahora también hay que tener en cuenta las oleadas de imitaciones.

¿Cómo puedo comprobar si un paquete ha sido compilado por sus verdaderos responsables?

Ejecuta npm audit signatures para verificar las firmas del registro y, cuando existan, los certificados de procedencia. La procedencia permite confirmar que un artefacto ha sido generado por la fuente y el flujo de trabajo de CI que afirma ser, lo cual es una cuestión distinta de si el código es seguro, ya que un flujo de trabajo comprometido puede generar una compilación debidamente certificada.

Detén las publicaciones no autorizadas antes de que se publiquen

Confiar únicamente en los avisos de seguridad puede suponer enterarse de una versión maliciosa solo después de que ya haya llegado a una compilación. SecureChain para npm analiza los paquetes en el momento de la resolución y los vuelve a compilar a partir de una fuente verificada para bloquear los artefactos comprometidos o que incumplan las políticas antes de que lleguen tan lejos. Echa un vistazo a SecureChain para npmy suscríbete al boletín de TuxCare para recibir actualizaciones semanales sobre la cadena de suministro del código abierto.

Resumen

Nombre del artículo

El ataque a la cadena de suministro de Axios en npm y lo que puso de manifiesto

Descripción

Dos versiones maliciosas de Axios permanecieron activas durante tres horas. Descubre qué ha puesto de manifiesto el ataque a la cadena de suministro de npm y qué medidas de control lo detienen realmente.

Autor

Tim Walker

Nombre del editor

TuxCare

Logotipo de la editorial