Han sido unas semanas caóticas para Axios.
Primero, un importante ataque a la cadena de suministro puso el paquete bajo escrutinio. Luego, solo unos días después, comenzaron a aparecer titulares sobre una “vulnerabilidad crítica 10/10” que podría llevar a un compromiso total de la nube.
Si ha leído la cobertura, probablemente habrá visto afirmaciones como:
- “los atacantes pueden robar credenciales de AWS”
- “bypass de IMDSv2”
- “cadena de ejecución remota de código”
Eso suena grave.
Pero si se observa de cerca cómo se comporta realmente esta vulnerabilidad en entornos reales, la situación cambia.
Tras analizar la cadena de explotación y validar el comportamiento con Raúl Vega Del Valle, el investigador que informó del problema, una cosa queda clara:
En entornos estándar de Node.js, esta vulnerabilidad no es explotable de forma realista.
La razón es sencilla: el ataque depende de la inyección de cabeceras malformadas, algo que Node.js ya ha bloqueado a nivel de runtime durante años.
Eso no significa que el CVE sea incorrecto. El problema subyacente en Axios es real, y parchearlo fue la decisión correcta. Pero la idea de que esto conduce a un compromiso fácil de la nube en producción no se sostiene bajo escrutinio. En la práctica, la explotación requeriría condiciones muy oscuras, como un adaptador personalizado que eluda la validación de cabeceras de Node.
Lo que el CVE Afirma
CVE-2026-40175 se describe como una vulnerabilidad de “cadena de gadgets”:
- Contaminación de prototipos en una dependencia
- Axios recoge valores contaminados
- Inyección de cabecera CRLF
- Request smuggling / SSRF
- Bypass de AWS IMDSv2
- Robo de credenciales → compromiso de la nube
En teoría, se ve así:
// Contaminación de prototipos en otro lugar
Object.prototype['x-amz-target'] =
"dummy\r\n\r\nPUT /latest/api/token HTTP/1.1\r\n" +
"Host: 169.254.169.254\r\n" +
"X-aws-ec2-metadata-token-ttl-seconds: 21600\r\n\r\nGET /ignore";
// Código de aplicación normal
axios.get("https://internal.service");Axios fusiona la configuración → recoge cabeceras contaminadas → envía una solicitud maliciosa.
Esa es la teoría.
Lo que realmente sucede en Node.js
El problema es: esta cadena se rompe en entornos reales.
Axios utiliza el cliente HTTP integrado de Node internamente:
http.request(...)
Y Node.js ha rechazado los caracteres CRLF en las cabeceras durante años.
Si intentas:
http.request({
headers: {
"x-test": "hello\r\nInjected: yes"
}
});Obtendrás:
TypeError [ERR_INVALID_CHAR]: Carácter no válido en el contenido de la cabecera
Esto ocurre antes de que se envíe cualquier solicitud.
Así que la primitiva central de la que depende el exploit —la inyección de cabecera CRLF— ya está bloqueada a nivel de runtime.
Lo verificamos con el investigador
Para validar esto, hablamos directamente con el investigador que informó de la vulnerabilidad, Raul Vega Del Valle.
Su conclusión coincide con lo que observamos:
- Node.js bloquea la inyección de cabecera CRLF
- El mismo comportamiento ocurre en Bun y Deno
- Como resultado, la cadena de ataque no es realmente alcanzable en entornos estándar
En palabras de Raul:
“En una aplicación del mundo real... no debería ocurrir... Node, Bun o Deno simplemente bloquean el CRLF.”
También confirmó que:
“No debería ser posible en aplicaciones de producción reales.”
Esa es una matiz crítica que falta en la mayoría de las coberturas.
Por qué el CVE sigue existiendo
Entonces, si no es explotable en la práctica, ¿por qué es esto un CVE?
Porque el problema es real a nivel de librería.
Axios anteriormente permitía valores de cabecera inseguros. Aunque el runtime los bloquee, la propia librería no aplicaba esa restricción.
Como explicó el investigador:
“Es real a nivel de librería, aunque no lo es a nivel de intérprete,” dice Raul Vega Del Valle
También hay un caso límite que merece la pena mencionar para mayor exhaustividad. Axios permite a los desarrolladores anular cómo se envían las solicitudes utilizando un adaptador personalizado. En lugar de depender de http.request integrado de Node, un adaptador personalizado podría construir y enviar manualmente solicitudes HTTP.
En teoría, si una aplicación:
- utiliza un adaptador Axios personalizado
- omite por completo el cliente HTTP de Node
- y escribe solicitudes en bruto directamente en los sockets
entonces la validación de encabezados también podría ser omitida. En ese escenario, la inyección CRLF podría volver a ser posible.
Dicho esto, esto requiere un uso no estándar y la desactivación deliberada de las protecciones integradas. No se aplica a las aplicaciones Node.js típicas que utilizan Axios de forma predeterminada.
¿Qué hay del bypass de IMDSv2?
Esta es la parte más publicitada de la historia y la menos fundamentada en la realidad.
Sí, el aviso muestra una solicitud como:
PUT /latest/api/token
Host: 169.254.169.254
X-aws-ec2-metadata-token-ttl-seconds: 21600Pero para lograrlo, un atacante necesita:
- contaminación de prototipos
- inyección CRLF
- contrabando de solicitudes
- sin validación en tiempo de ejecución
En Node.js, esa cadena se interrumpe prematuramente.
Incluso el investigador señaló que el bypass de IMDSv2 no es realmente factible en esta configuración, aunque mencionó que IMDSv1 podría merecer una investigación más profunda.
Por qué esto fue calificado como crítico
La calificación de “10/10” proviene del potencial de encadenamiento en el peor de los casos, no de la explotabilidad típica.
Si se asume:
- la contaminación de prototipos es posible
- se pueden inyectar encabezados
- los servicios internos son accesibles
- los endpoints de metadatos están expuestos
Entonces sí, el impacto podría ser grave.
Pero son muchas suposiciones superpuestas.
Lo que los desarrolladores deben hacer realmente
No es una situación para «dejarlo todo», pero tampoco es algo que deba ignorarse.
Debe:
- Actualice a Axios ≥ 1.15.0
- Audite sus dependencias en busca de riesgos de contaminación de prototipos
- Revise la exposición a SSRF y el acceso a la red
- Evite depender únicamente de la protección en tiempo de ejecución.
Céntrese en la superficie de ataque real, no solo en el titular del CVE.
