Qué ocurrió en el incidente de compromiso de seguridad del paquete npm de Axios
El caso de la vulnerabilidad del paquete npm de Axios nos recuerda que los riesgos del software moderno no siempre se presentan en forma de un CVE tradicional o de un fallo revelado en el código fuente. En ocasiones, el verdadero problema radica en una versión de paquete comprometida, una cadena de dependencias contaminada y una ruta de ejecución durante la instalación que convierte una actualización rutinaria en un incidente de seguridad.
Para los equipos de seguridad y de TI, la cuestión urgente no es solo «¿Se ha visto afectado Axios?», sino «¿Dónde tenemos realmente las versiones afectadas, qué se ha ejecutado y qué hay que volver a compilar o investigar ahora?».
Según informaciones recientes del sector , se indica que unos atacantes publicaron versiones maliciosas del paquete Axios en npm tras haber comprometido la cuenta de un responsable del mantenimiento. Según se ha informado, las versiones maliciosas afectaron a tanto a la rama principal como a la heredada , así como a la versión , e introdujeron una dependencia que existía principalmente para desencadenar la ejecución durante la instalación.
El punto importante es el siguiente: Axios en sí no fue «vulnerado» en el sentido clásico de un fallo de software que pudiera activarse de forma remota. En cambio, el riesgo procedía de la cadena de suministro de software de .
Por qué es importante este incidente
Axios es uno de los clientes HTTP de JavaScript más utilizados en un ecosistema en el que se identificaron más de 454,600 nuevos paquetes maliciosos en los principales registros de código abierto en 2025. , según Sonatype.
Axios se utiliza en:
- Estaciones de trabajo para desarrolladores
- Ejecutores de CI/CD
- Servidores de compilación
- Cargas de trabajo efímeras en la nube
- Sistemas de producción que instalan las dependencias de forma dinámica
Cuando se produce una vulnerabilidad en un paquete de amplia difusión, el alcance del impacto no depende tanto de la popularidad del paquete en sí, sino más bien del número de entornos que realmente hayan resuelto e instalado las versiones afectadas durante el periodo de exposición.
Las descargas semanales convirtieron a Axios en una de las bibliotecas de clientes HTTP de JavaScript más utilizadas en el ecosistema de npm, lo que significa que incluso un breve periodo de exposición durante el ataque a la cadena de suministro « March 2026 » conllevaba un impacto potencial enorme.
Versiones maliciosas detectadas
Según los datos públicos disponibles, las versiones identificadas con mayor frecuencia como maliciosas fueron:
| Paquete | Versión |
|---|---|
| axios | 1.14.1 |
| axios | 0.30.4 |
Los análisis públicos también relacionaron el problema con una dependencia inesperada que se utilizaba para activar un comportamiento tras la instalación.
| Dependencia sospechosa | Versión |
|---|---|
| plain-crypto-js | 4.2.1 |
Si su entorno contiene esas versiones de paquetes o la dependencia inesperada mencionada anteriormente, eso podría ser una señal clara de que conviene investigar más a fondo.
Un análisis independiente de ingeniería inversa y de amenazas, disponible en , revela que los paquetes dependientes del ecosistema npm utilizaban Axios en el momento en que se produjo la vulnerabilidMarch 2026 e en la cadena de suministro, lo que pone de manifiesto el alcance potencial de la publicación del paquete malicioso.
Por qué la filtración del paquete npm de Axios es diferente de una vulnerabilidad habitual
La mayoría de los programas de gestión de vulnerabilidades se diseñan en función de los fallos conocidos, los rangos de versiones afectadas y las recomendaciones sobre parches. Este evento rompe con ese modelo en varios aspectos importantes.
Se trataba de un problema de confianza en los paquetes, no solo de un defecto en el código
El riesgo se debió a un evento de publicación malintencionado. Esto significa que:
- Es posible que no exista ningún CVE al que basar la respuesta
- Los metadatos de los paquetes son tan importantes como el código fuente
- El comportamiento de la resolución de dependencias pasa a formar parte de la superficie de ataque
- Los scripts de instalación y los ganchos de postinstalación se convierten en pruebas fundamentales
Se centró en la ruta de dependencia
Muchos equipos siguen centrándose en las dependencias directas en package.json. Sin embargo, dado que muchos ataques a la cadena de suministro tienen su origen en dependencias comprometidas, incidentes como este ponen de manifiesto la importancia de las dependencias transitivas y fantasma.
Por ello, la revisión tradicional de las aplicaciones resulta insuficiente por sí sola.
Era compatible con distintos sistemas operativos
Las investigaciones públicas indican que la cadena de instalación dio lugar a un comportamiento específico de cada plataforma en Windows, macOS y Linux. Esto es importante porque la respuesta no puede limitarse al «riesgo del ordenador portátil del desarrollador» o al «riesgo del agente de compilación de Linux». Los equipos necesitan una visibilidad multiplataforma.
Lo primero que deben hacer los equipos de seguridad
En los incidentes relacionados con la cadena de suministro, los equipos suelen lanzarse a hacer conjeturas antes de confirmar lo que realmente ocurre. Antes de centrarse en los indicadores, comience por la pregunta más sencilla:
¿Disponemos de las versiones de los paquetes afectados en algún lugar del entorno?
El orden en que se presentan las cosas es importante.
Empiece por la presencia, luego pase al comportamiento y, a continuación, evalúe el impacto
Un modelo de respuesta práctico podría tener el siguiente aspecto:
| Paso | Pregunta | Por qué es importante |
|---|---|---|
| Presencia | ¿Disponemos de las versiones afectadas de Axios o de los artefactos de dependencias relacionados? | Confirma si la exposición es real o hipotética |
| Comportamiento | ¿Se han producido scripts de instalación, procesos secundarios o conexiones salientes? | Distingue entre una exposición latente y una ejecución probable |
| Impacto | ¿Se introdujeron secretos, credenciales o puntos de acceso persistentes? | Determina el alcance de la contención y la reconstrucción |
Este enfoque reduce el ruido y ayuda a los equipos a evitar reaccionar de forma exagerada ante los titulares, al tiempo que les permite actuar con rapidez ante una exposición real.
Qué debe tener en cuenta en su entorno
Si está evaluando la posible exposición derivada de la vulnerabilidad del paquete npm «Axios», revise los terminales, los servidores y los sistemas de CI/CD en busca de una combinación de indicios relacionados con el paquete, el comportamiento de los procesos, los artefactos de archivos y la actividad de red.
Datos a nivel de envase
Compruebe lo siguiente:
- axios, versión 1.14.1
- axios, versión 0.30.4
- plain-crypto-js, versión 4.2.1
- Los cambios en el archivo de bloqueo que provocaron una resolución de dependencias inesperada
- Instalación del paquete durante el periodo de exposición conocido
Datos sobre terminales y cargas de trabajo
En función de la plataforma, los investigadores deben buscar indicios que apunten a la ejecución de scripts durante la instalación, a descargas de cargas útiles por etapas o a procesos secundarios sospechosos generados desde Node.js o npm.
Entre las categorías útiles se incluyen:
- Ejecución de un script o de un comando de shell iniciada por npm o Node.js
- Actividad inesperada de PowerShell, Python, curl o el shell tras la instalación de un paquete
- El archivo escribe en directorios temporales
- Archivos binarios renombrados o camuflados
- Procesos en segundo plano independientes
- Tráfico saliente inusual procedente de los sistemas de desarrollo o de compilación
Datos sobre CI/CD
Los procesos de compilación merecen una atención especial, ya que suelen presentar:
- Amplio acceso a la red
- Secretos inyectados
- Credenciales en la nube
- Fichas de despliegue
- Resolución automática de paquetes
Si un ejecutor de CI ha instalado versiones maliciosas de los paquetes, considere este incidente como algo más que un simple susto relacionado con las dependencias de desarrollo. Reseña:
- Registros de flujo de trabajo
- Momento de la resolución de dependencias
- Conexiones de red salientes
- Secretos relacionados con el puesto de trabajo
- Integridad de los artefactos de las compilaciones realizadas durante el periodo
Medidas correctoras inmediatas
Si confirma la presencia de las versiones afectadas, actúe con rapidez, pero de forma metódica.
Las medidas que se indican a continuación reflejan las medidas de contención habituales que se aplican durante incidentes en la cadena de suministro, como el caso del paquete npm de Axios que se vio comprometido. No está previsto que se apliquen en un orden fijo, y las organizaciones deben aplicarlas en función de la importancia crítica del sistema, los requisitos de aprobación y la tolerancia al riesgo.
Lista de comprobación de contención
| Acción | Por qué es importante |
|---|---|
| Fijar las versiones de Axios que se sabe que son seguras | Evita que otros sistemas resuelvan o instalen las versiones afectadas durante la investigación |
| Elimine los artefactos de dependencias sospechosos | Garantiza que las dependencias corruptas no se reintroduzcan a través de instalaciones almacenadas en caché o de desviaciones en el archivo de bloqueo |
| Revise los sistemas en los que se ejecutó «npm install» durante el periodo de exposición | Centra la investigación en los endpoints, los ejecutores de CI y los sistemas de compilación que tienen más probabilidades de haber ejecutado scripts durante la instalación |
| Rote las credenciales expuestas a los contextos de compilación o de ejecución afectados | Limita el radio de impacto si se ha podido acceder a los secretos durante la ejecución en fase de instalación |
| Bloquee los dominios o direcciones IP maliciosos conocidos en las capas de DNS y de red | Actúa como control compensatorio en los casos en que la ejecución pueda haberse producido, pero la reconstrucción completa se haya retrasado |
| Reconstruya los sistemas afectados en los que se haya confirmado la ejecución | Restablece la confianza en los sistemas que puedan haber ejecutado cargas útiles de autolimpieza o difíciles de detectar |
| Auditar los artefactos de software generados durante el período de exposición | Protege los entornos posteriores mediante la validación de la integridad de los artefactos antes de su promoción o lanzamiento |
Cambios en las medidas de higiene de los envases para garantizar la seguridad
Incluso una vez resuelto el incidente en sí, los equipos deben reforzar los controles sobre los paquetes:
- Se recomienda fijar la versión exacta para las dependencias críticas
- Validar los archivos de bloqueo en la revisión de código
- Limite el uso de scripts de instalación en la integración continua (CI) siempre que sea posible
- Separe los secretos de compilación de la resolución rutinaria de dependencias
- Aplicar controles de procedencia para la publicación y el uso de paquetes
- Supervisar los paquetes que figuran en los manifiestos pero que no se utilizan realmente en la aplicación
Cómo puede ayudar Tanium a resolver el incidente ocurrido en la cadena de suministro de Axios
El panel de control « » de Tanium Guardian sobre la vulnerabilidad de la cadena de suministro de Axios ayuda a los equipos de seguridad y de TI a determinar rápidamente si hay paquetes de Axios comprometidos en su entorno y, en su caso, a investigar el posible impacto.
El panel de control se centra, en primer lugar, en la evaluación del alcance de la exposición, lo que permite a los equipos realizar un seguimiento de las versiones de Axios comprometidas (v1.14.1 y v0.30.4 heredadas) utilizando datos de y de la SBOM de Tanium para determinar si los paquetes afectados se han introducido en algún punto de su entorno. Esto permite a los equipos de seguridad y de TI ir más allá de las conjeturas y responder a la pregunta más urgente que surge ante un incidente en la cadena de suministro: si el software afectado está realmente presente.
Para aquellas organizaciones que dispongan de capacidades de investigación más avanzadas, el panel de control admite investigaciones multiplataforma de Stage 2 en macOS, Windows y Linux, con el fin de ayudar a identificar artefactos RAT y posibles actividades de comando y control asociadas a la dependencia maliciosa.
Cuando esté disponible Tanium Threat Response , los equipos también podrán llevar a cabo medidas de respuesta, como poner en cuarentena los terminales afectados.
El pleno funcionamiento del panel de control depende de que se disponga de Tanium SBOM y Tanium Threat Response, con los roles adecuados de generación de informes y visualización, lo que refleja el enfoque modular de Tanium en materia de validación de vulnerabilidades, investigación y respuesta.
Por qué los datos de la SBOM transforman el diálogo sobre las respuestas
La lista de componentes de software « » ( ) se considera en ocasiones un mero elemento de cumplimiento normativo, a pesar de que la CISA, la NSA y 19 socios internacionales hayan declarado que su adopción constituye un hito indispensable en materia de seguridad. Incidentes como este ponen de manifiesto por qué esa visión resulta demasiado limitada.
Cuando se produce una vulnerabilidad en un paquete, los datos de la SBOM pueden ayudar a determinar qué artefactos compilados incluían el paquete afectado, qué versiones se incluyeron y si se declararon dependencias sospechosas relacionadas. Para determinar dónde se implementaron esos artefactos o qué sistemas instalaron los paquetes, se necesita telemetría adicional de los terminales, los contenedores y los procesos de integración.
Sin esa visibilidad, los equipos tienden a basarse en indicadores aproximados:
- Búsquedas en el repositorio
- Información facilitada por los propios desarrolladores
- Pistas incompletas del EDR
- Revisión manual del archivo de bloqueo
- Supuestos sobre lo que «debería» instalarse
Se trata de datos útiles, pero no sustituyen a las pruebas a escala ambiental.
SBOM frente a la clasificación basada en suposiciones
La clasificación de prioridades basada en la SBOM se fundamenta en lo que realmente está presente en los dispositivos finales, y no en deducciones basadas únicamente en repositorios o alertas.
| Enfoque | Lo que se aprende rápidamente | Limitaciones |
|---|---|---|
| Revisión de la exposición respaldada por la SBOM | Presencia de paquetes o componentes en artefactos de compilación conocidos, a menudo con detalles sobre la versión | Sigue siendo necesario disponer de SBOM actualizadas y de una correspondencia fiable entre los artefactos y los activos desplegados |
| Revisión exclusiva de «Repo» | Intención de dependencia declarada | Desviaciones, resolución transitiva y realidad en tiempo de ejecución |
| Caza exclusiva de especies incluidas en la Lista de Especies Protegidas (IOC) | Indicios de comportamiento malintencionado | Puede pasar por alto una exposición inactiva o que aún no se haya ejecutado |
| Comprobaciones manuales por parte del desarrollador | Contexto local | Lento, irregular y difícil de ampliar |
El análisis de StepSecurity, disponible en , muestra que la vulnerabilid se debió a la inyección de una dependencia inesperada (plain-crypto-js), y no a una modificación del código fuente de Axios, lo que ilustra por qué la visibilidad a nivel de componentes, como la que ofrece la SBOM, resulta fundamental en los incidentes relacionados con la cadena de suministro.
Errores habituales que debe evitar
Los equipos que se ocupen de la vulnerabilidad del paquete npm de Axios deben tener en cuenta algunas trampas previsibles. Los ejemplos que figuran a continuación reflejan patrones habituales observados en incidentes relacionados con la cadena de suministro como este, pero las decisiones reales de respuesta deben basarse en la arquitectura, la tolerancia al riesgo y el entorno operativo de cada organización.
Considerar esto como «simplemente un problema de los desarrolladores»
Si un paquete comprometido se ejecutara en la integración continua (CI), el riesgo podría extenderse más allá de las estaciones de trabajo individuales de los desarrolladores, afectando a las credenciales, los artefactos de compilación y los entornos posteriores. En muchas organizaciones, los sistemas de CI cuentan con un acceso más amplio y mayores privilegios que los terminales de los desarrolladores.
Se busca únicamente el uso directo de Axios
Es posible que la exposición no se limite a aquellas aplicaciones que declaren explícitamente a Axios como una dependencia directa. El paquete puede aparecer en rutas de dependencia transitivas, contextos de compilación efímeros o entornos de corta duración que pueden pasarse por alto fácilmente durante la evaluación inicial.
Si no hay ningún CVE, se considera que la urgencia es baja
Las brechas en la cadena de suministro pueden suponer un riesgo operativo real sin encajar claramente en los flujos de trabajo tradicionales de gestión de vulnerabilidades de . Los equipos acostumbrados a establecer prioridades basadas en el CVE pueden subestimar los incidentes relacionados con la fiabilidad de los paquetes que no se corresponden con un identificador de vulnerabilidad conocido.
Limpieza in situ tras la ejecución confirmada
Si se confirma la existencia de un comportamiento malicioso, especialmente en entornos con privilegios o que contienen mucha información confidencial, suele ser más seguro restaurar el sistema a partir de un estado en el que se sabe que todo funciona correctamente que intentar una limpieza in situ. La respuesta adecuada dependerá de la función en el sistema, del nivel de privilegios y de la exposición a credenciales confidenciales.
Ejemplo de flujo de trabajo de investigación
La secuencia que figura a continuación ilustra una de las posibles formas en que los equipos de seguridad y de TI podrían estructurar una investigación sobre un incidente como el de la vulneración del paquete npm de Axios. Se ofrece a modo de ejemplo, no como una lista de verificación vinculante, y debe adaptarse en función de las herramientas, el entorno y el perfil de riesgo de la organización.
Fase 1: Confirmar la exposición
- Sistemas de inventario con versiones de Axios afectadas
- Detecte la presencia de dependencias relacionadas sospechosas o inesperadas
- Indique dónde se llevó a cabo la instalación del paquete durante el periodo de exposición
Fase 2: Analizar la ejecución
- Revise los procesos secundarios de npm y Node.js
- Compruebe la creación de archivos temporales y la ejecución de comandos de shell
- Busque intérpretes de scripts sospechosos y procesos aislados
- Relacionar las conexiones de red salientes de los hosts afectados
Fase 3: Evaluar el impacto en las fases posteriores
- Determine si se ha podido acceder a credenciales o datos confidenciales
- Revise los cambios introducidos en los artefactos de compilación generados durante el período de exposición
- Evaluar los indicadores de persistencia o de entrega de carga útil secundaria
- Decida entre la limpieza y la reconstrucción en función del grado de confianza y del riesgo
Fase 4: Fortalecimiento
- Fijar las dependencias a versiones de fiabilidad contrastada
- Reduzca la exposición de los scripts de instalación siempre que sea posible
- Mejorar la cobertura de las dependencias y de la SBOM
- Reforzar la gestión de los secretos de CI
- Revise los controles de fiabilidad y procedencia de los editores
Para las organizaciones que pongan en marcha este tipo de respuesta, unas prácticas más amplias de cumplimiento normativo — , gestión de la exposición a vulnerabilidades y , así como — pueden ayudar a coordinar la detección, la priorización y la corrección en todos los activos afectados, al tiempo que permiten mantener la flexibilidad en función de los riesgos específicos de cada entorno.
Preguntas frecuentes sobre el incidente de Axios
¿Era Axios en sí mismo vulnerable?
No en el sentido habitual de un fallo de software con una vía de explotación y un parche. El problema consistió en una vulneración de la cadena de suministro relacionada con la publicación de paquetes maliciosos.
¿Qué versiones de Axios se han señalado como afectadas?
Los informes públicos han señalado sistemáticamente a «axios 1.14.1 » y «axios 0.30.4 » como las versiones maliciosas de npm relacionadas con este incidente.
¿Por qué es importante la vulnerabilidad del paquete npm de Axios si tuvo una duración tan breve?
Dado que las vulnerabilidades de corta duración en los paquetes pueden seguir afectando a sistemas de gran valor si se resuelven e instalan la versión defectuosa durante el periodo de exposición. La eliminación rápida no anula las instalaciones que ya se hayan realizado.
¿Deberían las organizaciones rotar las credenciales?
Si los paquetes afectados se instalaron en sistemas con acceso a secretos, tokens, credenciales en la nube o claves de implementación, la revisión y rotación de las credenciales deben formar parte de la respuesta.
¿Es suficiente con comprobar los repositorios de código fuente?
No. La revisión de Repo resulta útil, pero no demuestra qué es lo que se ha instalado realmente en los terminales, los agentes de compilación y las cargas de trabajo. La visibilidad a nivel de entorno es esencial, y herramientas como Tanium pueden aportar datos de telemetría sobre los archivos y procesos de los terminales; sin embargo, la presencia de paquetes a menudo debe confirmarse con datos adicionales sobre artefactos, repositorios y flujos de trabajo.
La principal lección que se extrae del incidente de seguridad relacionado con el paquete npm de Axios
Una respuesta a incidentes bien desarrollada no depende únicamente de las fuentes de información sobre vulnerabilidades. Requiere la capacidad de responder rápidamente a tres preguntas bien fundamentadas:
- ¿Dónde se encuentra realmente el paquete afectado?
- ¿Qué problemas se produjeron tras la instalación?
- ¿Qué repercusiones operativas se produjeron a raíz de ello?
Para los equipos de seguridad, esa es la diferencia entre reaccionar ante los titulares y responder a los hechos. En incidentes recientes relacionados con la cadena de suministro se han puesto de manifiesto lecciones similares , como XZ Utils y 3CX, , en los que se hizo un uso indebido del acceso de desarrolladores de confianza o de la infraestructura de compilación para introducir puertas traseras, lo que refuerza la necesidad de que los equipos eviten evaluar el riesgo del software de forma demasiado limitada, basándose únicamente en los CVE.
Recursos adicionales
- Panel de control de Tanium Guardian Axios sobre vulnerabilidades en la cadena de suministro
- Página web de Axios
- Análisis de la filtración de Axios en la base de datos de amenazas de la comunidad OpenSourceMalware
- Análisis técnico de Elastic Security
Si su equipo está replanteándose cómo validar la exposición a las dependencias en los terminales, los servidores y los entornos de compilación donde el software se instala y se ejecuta realmente, Tanium ayuda a los equipos a partir de una presencia en el mundo real, a investigar el comportamiento con rigor y a responder utilizando información verificada y en tiempo real sobre los terminales. Solicite una demostración gratuita de adaptada a su entorno.
