SCA Deep Dive #1 — Axios (CVE-2025-27152) - Peticiones vulnerables a posible SSRF y filtración de credenciales mediante URL absoluta
Axios puede ignorar baseURL cuando la ruta ya es una URL absoluta. La petición va a otro sitio y las cabeceras por defecto pueden ir con ella.
El 7 de marzo de 2025 se publicó la CVE-2025-27152, titulada axios Requests Vulnerable To Possible SSRF and Credential Leakage via Absolute URL. Se trata de una vulnerabilidad de alta gravedad en la biblioteca Axios, una de las más descargadas del mundo, que permitía a un atacante manipular una petición HTTP para inducir a la aplicación a enviar peticiones a una dirección arbitraria. En determinadas configuraciones, esto podía resultar en Server-Side Request Forgery (SSRF), posibilitando el acceso a recursos internos que normalmente no estarían expuestos externamente, además de la posible filtración de credenciales presentes en las cabeceras de las peticiones.
Cómo funcionaba la vulnerabilidad
El problema estaba relacionado con la forma en que Axios trataba las URLs proporcionadas por el usuario al construir las peticiones. En determinadas condiciones, una URL absoluta proporcionada como entrada podía sustituir la URL base definida por la aplicación.
Esto es particularmente relevante en aplicaciones que utilizan Axios para acceder a APIs externas e incorporan datos controlados por el usuario en la URL de destino. Si esos datos no se validaban correctamente, un atacante podía proporcionar una URL especialmente creada y hacer que el servidor realizara una petición a un destino distinto del que la aplicación esperaba originalmente.
Cabeceras y credenciales
Además de la redirección de la petición, había un segundo factor de riesgo: determinadas cabeceras, incluidas las credenciales utilizadas por la aplicación, podían enviarse en la petición al destino controlado por el atacante. De ese modo, el problema podía dejar de ser solo una petición indebida y resultar también en la exposición de información sensible.
¿Por qué esto puede resultar en SSRF?
En un escenario de SSRF, el atacante no realiza directamente la petición contra el objetivo interno. En su lugar, utiliza el servidor vulnerable como intermediario.
Por ejemplo, una aplicación puede esperar recibir una URL para obtener información de una API:
https://api.ejemplo.com/users/123
Si la aplicación acepta una URL absoluta controlada por el usuario sin las validaciones necesarias, el comportamiento esperado puede alterarse. En lugar de acceder solo al dominio permitido, el servidor puede acabar realizando una petición a otro destino.
Esto es especialmente peligroso en entornos en los que el servidor tiene acceso a servicios internos, endpoints administrativos u otros recursos que no deberían ser accesibles directamente desde Internet.
Explorando el comportamiento
Para entender mejor el problema, imagine una aplicación que utiliza Axios para obtener el contenido de una URL proporcionada por el usuario. La aplicación puede definir una URL base para garantizar que las peticiones se dirijan a un servicio específico:
const api = axios.create({
baseURL: "https://api.ejemplo.com"
});
En condiciones normales, la aplicación espera trabajar con rutas relativas:
api.get("/users/123");
En ese caso, la petición se dirige a:
https://api.ejemplo.com/users/123
El problema aparece cuando una entrada controlada por el usuario se interpreta como una URL absoluta. En lugar de permanecer limitada a la URL base configurada por la aplicación, la petición puede dirigirse a un dominio distinto.
En una aplicación vulnerable, por ejemplo, una entrada como:
https://servidor-controlado-por-el-atacante.example/
podría hacer que Axios realizara la petición a esa dirección en lugar de utilizar el dominio definido originalmente en baseURL.
Esto se vuelve aún más relevante cuando la aplicación añade automáticamente cabeceras de autenticación a las peticiones. En ese escenario, una petición que debería enviarse exclusivamente a la API de confianza podría acabar dirigiéndose a un servidor externo.
El impacto
El impacto de la vulnerabilidad depende de cómo la aplicación utiliza Axios. El problema no significa que cualquier aplicación que use Axios esté automáticamente vulnerable a SSRF.
El riesgo surge principalmente cuando una aplicación combina el comportamiento afectado con entradas controladas por el usuario e información sensible añadida automáticamente a las peticiones.
Un escenario particularmente preocupante ocurre cuando la aplicación utiliza un token de autenticación en una cabecera:
Authorization: Bearer <token>
Si una petición puede redirigirse a un destino controlado por un atacante y esa cabecera se incluye en la petición, el token puede quedar expuesto.
Además de la posible filtración de credenciales, la capacidad de hacer que el servidor realice peticiones a destinos arbitrarios puede permitir acceso indirecto a servicios que no están disponibles externamente. El impacto real dependerá de los permisos y de la conectividad disponibles para el servidor vulnerable.
Versiones afectadas de Axios
La CVE-2025-27152 afecta a las dos líneas principales de Axios: la serie 0.x y la serie 1.x.
En la serie 0.x, las versiones hasta 0.29.0 están afectadas. La corrección en esa línea llegó en la 0.30.0.
En la serie 1.x, las versiones anteriores a 1.8.2 están afectadas, incluido el intervalo de 1.0.0 hasta 1.7.9. La primera versión publicada como corrección fue la 1.8.2, pero solo cubrió el adaptador HTTP usado en Node.js. Los adaptadores xhr y fetch, usados principalmente en el navegador, solo empezaron a respetar la restricción en la 1.8.3.
Quien todavía está en la línea 0.x necesita pasar a 0.30.0 o posterior. Quien está en la línea 1.x debe pasar a 1.8.3 o posterior, y no detenerse en la 1.8.2 si la aplicación también dispara peticiones a través de xhr o fetch.
La corrección
La corrección de este tipo de problema implica impedir que una URL absoluta proporcionada como entrada pueda sustituir en silencio el origen definido por la aplicación.
Además de actualizar Axios a una versión corregida, las aplicaciones que reciben URLs o rutas controladas por el usuario deben aplicar validaciones propias. Es importante definir qué destinos están permitidos y no confiar solo en la existencia de un baseURL para restringir el destino final de una petición.
Un enfoque de defensa en profundidad también puede incluir restricciones de red en el entorno donde se ejecuta la aplicación. De ese modo, incluso si una aplicación presenta un fallo de SSRF, el servidor tendrá un acceso limitado a recursos internos y servicios que no deberían ser alcanzables.
Encuentra dependencias vulnerables en tus proyectos con runtz
Escanea las dependencias de tus proyectos ahora. Empieza en runtz.dev.
