SCA Deep Dive #1 — Axios (CVE-2025-27152) - Requests Vulnerable To Possible SSRF and Credential Leakage via Absolute URL

On March 7, 2025, CVE-2025-27152 was published, titled axios Requests Vulnerable To Possible SSRF and Credential Leakage via Absolute URL. It is a high-severity vulnerability in the Axios library, one of the most downloaded libraries in the world, that allowed an attacker to manipulate an HTTP request so the application would send requests to an arbitrary address. Under certain configurations, this could result in Server-Side Request Forgery (SSRF), enabling access to internal resources that would not normally be exposed externally, as well as potential leakage of credentials present in the request headers.

How the vulnerability worked

The issue was related to how Axios handled user-supplied URLs when building requests. Under certain conditions, an absolute URL provided as input could replace the base URL defined by the application.

This is particularly relevant in applications that use Axios to reach external APIs and embed user-controlled data in the destination URL. If that data was not properly validated, an attacker could supply a specially crafted URL and cause the server to send a request to a destination other than the one the application originally expected.

Headers and credentials

Besides redirecting the request, there was a second risk factor: certain headers, including credentials used by the application, could be sent in the request to the attacker-controlled destination. That way, the issue could stop being just an unintended request and also result in the exposure of sensitive information.

Why can this result in SSRF?

In an SSRF scenario, the attacker does not send the request to the internal target directly. Instead, they use the vulnerable server as an intermediary.

For example, an application may expect to receive a URL to fetch information from an API:

https://api.example.com/users/123

If the application accepts a user-controlled absolute URL without the necessary validation, the expected behavior can change. Instead of accessing only the allowed domain, the server may end up making a request to another destination.

This is especially dangerous in environments where the server has access to internal services, administrative endpoints, or other resources that should not be reachable directly from the Internet.

Exploring the behavior

To better understand the issue, imagine an application that uses Axios to fetch the contents of a user-supplied URL. The application may set a base URL to keep requests pointed at a specific service:

const api = axios.create({
    baseURL: "https://api.example.com"
});

Under normal conditions, the application expects to work with relative paths:

api.get("/users/123");

In that case, the request is sent to:

https://api.example.com/users/123

The problem appears when user-controlled input is interpreted as an absolute URL. Instead of staying limited to the base URL configured by the application, the request can be sent to a different domain.

In a vulnerable application, for example, input such as:

https://attacker-controlled-server.example/

could cause Axios to send the request to that address instead of using the domain originally defined in baseURL.

This becomes even more relevant when the application automatically adds authentication headers to requests. In that scenario, a request that should have been sent only to the trusted API could end up going to an external server.

The impact

The impact of the vulnerability depends on how the application uses Axios. The issue does not mean that every application using Axios is automatically vulnerable to SSRF.

The risk mainly arises when an application combines the affected behavior with user-controlled input and sensitive information added automatically to requests.

A particularly concerning scenario occurs when the application uses an authentication token in a header:

Authorization: Bearer <token>

If a request can be redirected to an attacker-controlled destination and that header is included in the request, the token may be exposed.

Besides the possible credential leak, the ability to make the server send requests to arbitrary destinations may allow indirect access to services that are not available externally. The real impact will depend on the permissions and connectivity available to the vulnerable server.

Affected Axios versions

CVE-2025-27152 affects both of Axios’s main lines: the 0.x series and the 1.x series.

On the 0.x series, versions through 0.29.0 are affected. The fix on that line arrived in 0.30.0.

On the 1.x series, versions before 1.8.2 are affected, including the range from 1.0.0 through 1.7.9. The first version published as a fix was 1.8.2, but it only covered the HTTP adapter used in Node.js. The xhr and fetch adapters, used mainly in the browser, only started honoring the restriction in 1.8.3.

Anyone still on the 0.x line needs to move to 0.30.0 or later. Anyone on the 1.x line should move to 1.8.3 or later, and not stop at 1.8.2 if the application also fires requests through xhr or fetch.

The fix

Fixing this kind of issue means preventing an absolute URL supplied as input from silently replacing the origin defined by the application.

Besides updating Axios to a patched version, applications that receive user-controlled URLs or paths should apply their own validation. It is important to define which destinations are allowed and not rely only on the existence of a baseURL to restrict the final destination of a request.

A defense-in-depth approach can also include network restrictions in the environment where the application runs. That way, even if an application has an SSRF flaw, the server will have limited access to internal resources and services that should not be reachable.

Find vulnerable dependencies in your projects with runtz

Scan your projects' dependencies now. Get started at runtz.dev.