¿Alarma falsa? CVE Axios no es explotable

El CVE-2026-40175 de Axios obtuvo una puntuación CVSS de 9.9, pero acá viene lo interesante: el riesgo real en Node.js es mucho menor de lo que suena. La vulnerabilidad requiere condiciones específicas que casi no se dan en el mundo real, aunque el ataque de cadena de suministro del 31 de marzo comprometió versiones 1.14.1 y 0.30.4 con un RAT. Actualizar a 1.15.0+ elimina el riesgo.

Axios y su importancia en desarrollo JavaScript

Axios es un cliente HTTP basado en promesas, y si trabajaste alguna vez en JavaScript moderno (frontend o Node.js), casi seguro lo usaste. Son 80 millones de descargas semanales. Lo que lo hizo popular es que es simple, confiable, y funciona igual en el navegador que en el servidor.

Ponele que necesitás hacer un fetch a una API. Con Axios escribís tres líneas y listo. Sin él, tenés que pelear con XMLHttpRequest o entender los detalles de fetch nativo. Eso, multiplicado por millones de proyectos, es por qué está en todas partes.

El punto es que si Axios tiene un problema, el problema es tuyo también.

CVE-2026-40175: La vulnerabilidad explicada paso a paso

A principios de abril, el CVE-2026-40175 fue publicado con un CVSS de 9.9, lo que significa “crítico” en cualquier escala de severidad. Suena del culo, pero espera.

La vulnerabilidad funciona así: si alguien consigue inyectar un objeto malicioso que contamina el prototype de Object en tu código, y luego Axios usa ese objeto para construir headers, la inyección de CRLF (salto de línea de carriage return y line feed) en los headers podría escapar y ejecutar código en contextos donde se interpretan esos headers como comandos.

El caso clásico es AWS IMDS (Instance Metadata Service): si logras meter un salto de línea en un header, podés saltar a una línea nueva de la request HTTP y leer las credenciales de la instancia. Eso es un golazo para un atacante.

Pero acá viene el “pero”.

El mito del CVSS 9.9: Por qué no es realistically explotable

Fijate que la vulnerabilidad requiere tres cosas alineadas:

Uno: prototype pollution en otra librería que vos incluyas en tu proyecto. Axios no produce prototype pollution solo; necesita contaminación preexistente. Dos: que esa contaminación le llegue a Axios sin ser filtrada en el camino. Tres: que vos estés corriendo un código que interprete headers salteados como comandos. En Node.js vanilla, eso no ocurre. El servidor HTTP de Node rechaza headers malformados automáticamente. Para más detalles técnicos, mirá construir APIs seguras en JavaScript.

Es como tener una cadena de cuatro cerraduras. Cada eslabón tiene que abrirse. Si uno solo no se abre, nada pasa.

Según el análisis de Aikido, casi ningún proyecto real incumple las tres condiciones simultáneamente. Por eso el equipo de seguridad dice “critical score, non-critical impact”.

¿Eso quiere decir que podés ignorarlo? No. Pero tampoco es “tu servidor va a ser hackeado mañana”.

La cadena de ataque: Cómo funciona la explotación (teoría)

Digamos que estás usando una librería vieja de parsing JSON que tiene un bug de prototype pollution. Un atacante la usa para contaminar el prototype. Luego, Axios agarra ese objeto contaminado para construir los headers de una request. Los headers terminan con CRLF inyectados. Ahora, si tu servidor hace algo raro como parsear headers manualmente o los pasa a un comando de shell (spoiler: no deberías hacerlo nunca), el atacante podría ejecutar código. Eso sí, solo en escenarios muy obscuros.

En producción real: raramente tenés esa librería vieja, raramente termina contaminando el prototype de Axios sin filtros intermedios, y raramente tu servidor interpreta headers como comandos. La probabilidad de que las tres cosas ocurran juntas es casi cero.

Ataque de cadena de suministro (31 de marzo 2026): Versiones comprometidas

Pero ahí es donde entra lo real. El 31 de marzo de 2026, el mantenedor principal de Axios fue comprometido, y versiones 1.14.1 y 0.30.4 fueron publicadas con un RAT (Remote Access Trojan) incrustado. No es un bug, es malware inyectado directamente.

La dependencia maliciosa se llamaba “plain-crypto-js” y se agregó como una nueva dependencia en el package.json. El RAT abrió acceso remoto a la máquina del usuario, permitiendo descarga de archivos, ejecución de comandos, y exfiltración de datos. Relacionado: automatizar tus workflows de seguridad.

80 millones de usuarios potencialmente descargaron una de esas versiones ese día. No todos fueron comprometidos (hay filtros de versión, algunos repositorios usan lockfiles), pero fue masivo.

Microsoft publicó un análisis detallado del incidente e inmediatamente los mantenedores de Axios sacaron la versión 1.15.0 con parches de seguridad.

Cómo actualizar a Axios 1.15.0 de forma segura

Primero, verificá qué versión tenés:

npm list axios

Si ves 1.14.1, 1.14.0, o 0.30.4: estás en zona roja. Actualiza ya.

En tu package.json, cambiá:

"axios": "^1.14.1" → "axios": "^1.15.0"

O directamente:

npm install axios@latest

PERO: Axios 1.15.0 ahora rechaza headers que contengan CR o LF. Si tenés código que deliberadamente pone esos caracteres en headers, te va a fallar con un error. Probablemente no tengas ese código (si lo tuvieras, estarías haciendo algo raro), pero testea en staging primero.

Después de actualizar, corré npm audit para asegurarte de que no hay otras dependencias comprometidas:

npm audit

Y si instalaste 1.14.1 o 0.30.4 en tu máquina entre el 31 de marzo y ahora, roté todas tus credenciales almacenadas (API keys, tokens, contraseñas). El RAT pudo haber extraído eso.

Parches de seguridad en Axios 1.15.0

La nueva versión no solo elimina el RAT. Trae tres cambios de seguridad importantes: Complementá con pruebas para verificar vulnerabilidades.

• Rechazo de CRLF en headers: cualquier intento de meter CR (carriage return \r) o LF (line feed \n) en un header ahora lanza un error inmediatamente. Punto. No hay bypass posible con prototype pollution.
• Bypass de normalización SSRF corregido: había una forma de escapar filtros SSRF usando normalizaciones Unicode. Ese agujero se cerró.
• Hardening de CI/CD: el repositorio ahora usa OIDC para deployments, eliminando la necesidad de almacenar credenciales npm en texto plano. Si un mantenedor es comprometido de nuevo, al menos el atacante no puede publicar versiones a npm automáticamente.

Checklist de seguridad para developers

Acá están los pasos concretos que tenés que hacer ahora:

• Audita con npm audit: npm audit en tu proyecto. Cualquier CVE conocido te lo va a mostrar.
• Verificá tu versión de Axios: npm list axios. Si es 1.14.1, 1.14.0, o 0.30.4, estás comprometido.
• Actualiza en staging primero: npm install [email protected] en un branch. Testea tu suite de tests. Si pasa, merge.
• Revisa tu lockfile: si tenés un package-lock.json o yarn.lock, verificá que la versión que se instala es > 1.15.0. A veces npm install intenta mantener versiones viejas si tenés constraints ajustados.
• Rota credenciales: si descargaste 1.14.1 o 0.30.4 entre el 31 de marzo y hoy, regenerá todas tus API keys, tokens de GitHub, credenciales de AWS. El RAT los pudo haber leído.
• Monitorea package.json en producción: setup una alerta en tu CI si alguien agrega una dependencia llamada “plain-crypto-js” o similar. Podría ser otro ataque disfrazado.

Errores comunes que ves en empresas

Error 1: Ignorar “CVSS alto pero no explotable”

El equipo de seguridad ve CVSS 9.9 y entra en pánico. El de frontend dice “bueno, pero en el análisis dice que no es realistically exploitable”. Entonces: nadie actualiza. Y pasas meses con una vulnerabilidad abierta porque ambos asumen que el otro está en onda. Resultado: cuando el atacante te llama, salió caro.

Regla: CVSS alto o bajo, si hay un parche disponible hace menos de una semana, actualizá. Eso es lo que importa.

Error 2: No rotar credenciales después de un compromiso

“Bueno, el RAT no llegó a ejecutarse en mi máquina porque actualizé rápido”. Pero si instalaste la versión comprometida aunque sea un minuto, el RAT estuvo ahí. Aunque no haya hecho nada visible, pudo haber leído tus variables de entorno, tokens de GitHub, API keys. Algunos RATs actúan semanas después.

Criterio: si tu máquina corrió la versión maliciosa, considerá comprometida toda credencial almacenada ahí. Rotá todo.

Error 3: Testear solo en producción

Axios 1.15.0 rechaza headers con CR/LF. Si tenés código legacy que construye headers manualmente y mete esos caracteres (no sé por qué, pero lo vi), te va a volar en producción. Tenías que haberlo testeado en staging primero, visto el error, y arreglado. Te puede servir nuestra cobertura de frameworks con buena gestión de dependencias.

Siempre: dev → staging → producción. No saltes pasos porque “es solo una actualización minor”.

Preguntas Frecuentes

¿Qué es exactamente el CVE-2026-40175?

Es una vulnerabilidad en Axios que combina prototype pollution con CRLF injection en headers. CVSS de 9.9 porque en teoría podría habilitar bypass de SSRF o IMDS en AWS. En práctica, las condiciones para explotar son tan restrictivas que casi nunca ocurre en el mundo real. Lo más grave fue el ataque de cadena de suministro del 31 de marzo donde un RAT fue inyectado en las versiones 1.14.1 y 0.30.4.

¿Afecta este CVE a todas las aplicaciones que usan Axios?

No. La vulnerabilidad CVE-2026-40175 requiere prototype pollution preexistente en otra librería. Si no tenés eso, el CVE no te toca. El ataque del RAT sí: si instalaste 1.14.1 o 0.30.4 entre el 31 de marzo y hoy, el RAT estuvo en tu máquina y pudo haber extraído credenciales.

¿Debo actualizar Axios aunque no tenga prototype pollution?

Sí. Axios 1.15.0 endurecio contra futuros ataques: rechaza headers con CR/LF, parchea bypass de SSRF, y el repositorio usa OIDC para despliegues. Es +seguridad sin costo. Actualiza.

¿Tengo que pasar a otra librería HTTP como Got o Undici?

No es necesario. Axios 1.15.0+ es seguro. Got y Undici también son alternativas válidas si preferís, pero el cambio de librería es más disruptivo que actualizar Axios. Actualiza, testea, seguís con lo que tenías.

¿Cómo sé si la cadena de suministro me afectó?

Si instalaste Axios entre el 30 de marzo y el 1 de abril, verificá tu package-lock.json. Si la versión registrada es 1.14.1, 1.14.0, o 0.30.4, el RAT pudo haber estado en tu máquina. Rota credenciales inmediatamente.

Qué significa para equipos en Latinoamérica

En la región, muchos desarrolladores usan Axios porque es la opción por defecto en tutoriales y bootcamps. Si tenés un equipo chico y no auditás dependencias regularmente, es probable que tengas una versión comprometida en algún lado. El criterio es: si publicaste algo entre el 31 de marzo y ahora, auditá hoy mismo. No mañana.

Para empresas que ofrecen hosting web (como donweb.com), esto es relevante: si hospedan aplicaciones Node.js de clientes, informales sobre esta vulnerabilidad. Les estás dando valor agregado y evitás que terminen con un RAT en sus servidores.

Conclusión

El CVE-2026-40175 de Axios es confuso porque la vulnerabilidad técnica no es tan grave en práctica como suena, pero el ataque de cadena de suministro fue real y afectó millones de usuarios. El fix es simple: actualiza a 1.15.0, testea en staging, y si descargaste versiones comprometidas, rota credenciales.

Lo importante es que el ecosistema de Node.js está defendiendo: Axios incluyó protecciones contra CRLF, npm agregó más auditoría en publicaciones, y los mantenedores usaron OIDC para futuras despliegues. Si sos developer, mantente atento a tus dependencias. Una línea de npm audit cada semana te ahorra semanas de drama después.

Fuentes

• CVE-2026-40175 – NIST National Vulnerability Database
• Axios CVE-2026-40175: A Critical Bug That’s Not Exploitable – Aikido Security
• Axios v1.15.0 Release – GitHub
• Mitigating the Axios npm Supply Chain Compromise – Microsoft Security Blog
• Axios npm Compromised: Maintainer Account Hijacked, RAT Injected – Aikido Security