This issue is specific to configurations where 'httpVersion' is set to 2. Applications using default HTTP/1.1 settings or those utilizing browser-based XHR/fetch adapters are not affected. Defenders should prioritize auditing applications that interface with user-supplied or untrusted URLs via HTTP/2, as these provide the most direct vector for triggering the unhandled exception and achieving a denial-of-service state.

Attack Chain

1. The application initializes an Axios instance with httpVersion: 2 configured.
2. The application triggers an outgoing HTTP request to a destination controlled or influenced by an attacker.
3. Axios calls http2.connect() to initialize a new session with the target authority.
4. The remote target (or network intermediary) forces a connection error (e.g., reset, connection refused, or TLS failure).
5. The underlying ClientHttp2Session object emits an 'error' event to the process.
6. Because no error listener is attached within the Axios session manager, the Node.js process treats the error as an uncaught exception.
7. The application process exits abruptly, resulting in a denial-of-service for all concurrent users.

Impact

Successful exploitation results in an immediate denial-of-service for the vulnerable Node.js process. This can impact service availability for any users of the application. The vulnerability is highly disruptive in high-traffic microservices or web applications that rely on Axios for backend-to-backend communication, as a single malicious or malformed request can crash the entire service instance.

Recommendation

1. Upgrade to Axios version 1.20.0 or later immediately to incorporate the necessary 'error' event handling logic.
2. For environments where immediate patching is not feasible, disable the use of the HTTP/2 adapter in Axios for any request destinations that involve user input or untrusted origins.
3. Review application configurations to ensure 'http2Options' are not derived from raw, unvalidated user-controlled input, as this increases the likelihood of triggering edge-case connection failures.

When applications rely on the fetch adapter, either through explicit configuration, environment-specific resolution (such as in Deno, Bun, or Cloudflare Workers), or automatic adapter selection, the library fails to pass a restrictive redirect mode to the underlying fetch() API. Consequently, the default runtime behavior of redirect: 'follow' takes precedence. This discrepancy allows attackers who can influence the initial request URL or provide a malicious redirecting server to bypass intended SSRF protections, leading to potential unauthorized access to internal resources or state-changing operations on internal endpoints reachable from the application environment.

Impact

Successful exploitation allows for redirect-based SSRF, which may lead to the exposure of sensitive internal data or unauthorized modification of internal system states. The impact is significant for applications operating in cloud or serverless environments where network perimeter defenses are often bypassed by internal requests. If an internal service processes state-changing requests without additional authentication, an attacker can trigger unauthorized mutations by providing an open redirect or a malicious redirection chain that directs the application to the internal target.

Recommendation

Detection and remediation should focus on identifying applications using the fetch adapter in security-sensitive contexts.

• Audit application code for usages of axios.get() or axios.request() that specify maxRedirects: 0 without explicit fetchOptions to define redirect behavior.
• Where the fetch adapter is required, enforce manual redirect handling by setting fetchOptions: { redirect: 'manual' } in the axios configuration.
• If the application environment supports it, prefer the Node.js HTTP adapter for requests requiring strict adherence to redirect limits.
• Implement network-level egress filtering to prevent the application server from initiating connections to sensitive internal service segments (127.0.0.1, 169.254.169.254, or private RFC1918 ranges) unless explicitly required.