Han sido unas semanas bastante agitadas para Axios.
En primer lugar, un grave ataque a la cadena de suministro puso el paquete en el punto de mira. A continuación, apenas unos días después, empezaron a aparecer titulares sobre una «v ulner abilidad crítica de 10/10» que podría provocar el compromiso total de la nube.
Si has leído las noticias, probablemente hayas visto afirmaciones como:
- «Los atacantes pueden robar credenciales de AWS»
- «Omisión de IMDSv2»
- «cadena de ejecución remota de código»
Eso suena mal.
Pero cuando se analiza detenidamente cómo se comporta realmente esta vulnerabilidad en entornos reales, la cosa cambia.
Tras analizar la cadena de exploits y verificar su comportamiento con Raúl Vega Del Valle, el investigador que informó del problema, hay algo que queda claro:
En entornos estándar de Node.js, esta vulnerabilidad no es, en la práctica, explotable.
La razón es sencilla: el ataque se basa en la inyección de encabezados malformados, algo que Node.js lleva años bloqueando a nivel de tiempo de ejecución.
Eso no significa que la vulnerabilidad CVE sea errónea. El problema subyacente en Axios es real, y corregirlo fue la decisión acertada. Pero la idea de que esto facilite el compromiso de la nube en entornos de producción no se sostiene ante un análisis riguroso. En la práctica, su explotación requeriría condiciones muy específicas, como un adaptador personalizado que eluda la validación de encabezados de Node.js.
Lo que afirma el CVE
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 encabezados CRLF
- Contrabando de solicitudes / SSRF
- Omisión de AWS IMDSv2
- Robo de credenciales → vulneración de la seguridad en la nube
En teoría, queda así:
// Contaminación de prototipos en otro lugar
Objeto.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 normal de la aplicación
axios.get("https://internal.service");Axios fusiona la configuración → recoge los encabezados contaminados → envía una solicitud maliciosa.
Eso es lo que se supone.
¿Qué ocurre realmente en Node.js?
El problema es que esta cadena se rompe en entornos reales.
Axios utiliza el cliente HTTP integrado de Node en segundo plano:
http.request(...)
Además, Node.js lleva años rechazando los caracteres CRLF en los encabezados.
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 del encabezado
Eso ocurre antes de que se envíe cualquier solicitud.
Por lo tanto, la primitiva fundamental en la que se basa el exploit —la inyección de encabezados CRLF— ya está bloqueada a nivel de tiempo de ejecución.
Lo hemos comprobado con el investigador
Para verificarlo, hablamos directamente con el investigador que informó de la vulnerabilidad, Raúl Vega Del Valle.
Su conclusión coincide con lo que observamos:
- Node.js bloquea la inyección de encabezados CRLF
- Lo mismo ocurre en Bun y Deno
- Por lo tanto, la cadena de ataque no es viable en entornos estándar
En palabras de Raúl:
«En una aplicación real… eso no debería ocurrir… Node, Bun o Deno simplemente bloquean el CRLF».
También confirmó que:
«Esto no debería ser posible en aplicaciones de producción reales».
Ese es un matiz fundamental que se echa en falta en la mayoría de los reportajes.
¿Por qué sigue existiendo el CVE?
Entonces, si en la práctica no se puede explotar, ¿por qué se trata de un CVE?
Porque el problema es real a nivel de las bibliotecas.
Anteriormente, Axios permitía valores de encabezado no seguros. Aunque el tiempo de ejecución los bloqueara, la propia biblioteca no imponía esa restricción.
Según explicó el investigador:
«Es real a nivel de la biblioteca, aunque no lo sea a nivel del intérprete», afirma Raúl Vega Del Valle
Por completar, también hay un caso especial que merece la pena mencionar. Axios permite a los desarrolladores anular la forma en que se envían las solicitudes mediante un adaptador personalizado. En lugar de recurrir al método `http.request` integrado en Node, un adaptador personalizado podría crear y enviar solicitudes HTTP de forma manual.
En teoría, si una aplicación:
- utiliza un adaptador personalizado de Axios
- evita por completo el uso del cliente HTTP de Node
- y escribe solicitudes sin procesar directamente en los sockets
entonces también se podría eludir la validación de los encabezados. En ese caso, la inyección de 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 típicas de Node.js que utilizan Axios tal y como viene de fábrica.
¿Qué hay del bypass de IMDSv2?
Esta es la parte de la historia que más expectación ha suscitado y la menos basada en la realidad.
Sí, el aviso muestra una solicitud como esta:
PUT /latest/api/token
Host: 169.254.169.254
X-aws-ec2-metadata-token-ttl-seconds: 21600
Pero para lograrlo, un atacante necesita:
- contaminación por prototipos
- Inyección de CRLF
- contrabando de solicitudes
- sin validación en tiempo de ejecución
En Node.js, esa cadena se rompe antes de tiempo.
El propio investigador señaló que, en esta configuración, no es realista pensar en eludir el IMDSv2, aunque mencionó que podría merecer la pena seguir investigando el IMDSv1.
¿Por qué se consideró crítico?
La calificación de «10/10» se basa en el potencial de encadenamiento en el peor de los casos, no en la facilidad de explotación habitual.
Si se parte de la base de que:
- Es posible que se produzca contaminación por prototipos
- Se pueden insertar encabezados
- se puede acceder a los servicios internos
- se exponen los puntos de conexión de metadatos
Entonces sí, las consecuencias podrían ser graves.
Pero eso son muchas suposiciones acumuladas.
Lo que los desarrolladores deberían hacer realmente
No es una situación que requiera dejar todo lo que estés haciendo, pero tampoco es algo que se pueda ignorar.
Deberías:
- Actualiza a Axios ≥ 1.15.0
- Comprueba tus dependencias para detectar posibles riesgos de contaminación de prototipos
- Revisar la exposición a SSRF y el acceso a la red
- No confíes únicamente en las protecciones en tiempo de ejecución
Céntrate en la superficie de ataque real, no solo en el titular sobre el CVE.
