CVE-2026-101898: Axios: HTTP/2 adapter bypasses configured DNS lookup and proxy controls

## Summary Axios for Node.js does not apply configured DNS lookup or proxy controls when a request uses `httpVersion: 2`. The HTTP/1 adapter path wraps and forwards `config.lookup`, builds normal request options, and applies proxy routing through `setProxy()`. The HTTP/2 path builds a session with `http2.connect()` using only `options.http2Options`, which drops the top-level `lookup`, `agent`, and proxy state. Applications are affected when they allow a user to influence request destinations, enable axios HTTP/2, and rely on axios `lookup` or proxy routing to prevent SSRF or enforce outbound network policy. ## Impact In affected server-side deployments, an attacker can cause axios to connect directly to destinations that the configured resolver or proxy would have rejected. Depending on reachable services, this can expose cloud metadata, internal service responses, or allow state-changing requests to internal systems. This is not an unconditional SSRF in every axios deployment. It requires `httpVersion: 2` and an application-level trust boundary where user-influenced URLs are constrained by `lookup` or proxy policy. ## Affected Functionality Affected: - Node.js HTTP adapter with `httpVersion: 2`. - `config.lookup` supplied as a DNS policy. - Explicit `config.proxy` and environment-derived proxy settings for HTTPS HTTP/2 requests. Not affected: - Browser adapters. - Node HTTP/1 requests, which pass `lookup` to the transport and apply proxy handling. - Applications that validate destination hosts independently before calling axios. ## Technical Details In `lib/adapters/http.js`, the adapter reads `lookup`, wraps it, stores it on the request `options`, and applies `setProxy()` before selecting a transport. For HTTP/2, `http2Transport.request()` builds an authority from `options.protocol`, `options.hostname`, and `options.port`, then calls: ```js const { http2Options, headers } = options; const session = http2Sessions.getSession(authority, http2Options); ``` `lib/helpers/Http2Sessions.js` ultimately calls `http2.connect(authority, options)` with only the `http2Options` object. The configured DNS lookup and the proxy or tunneling agent installed on the top-level request options are not forwarded into that call. Local verification on axios `1.18.1` showed `lookupCalls: 0` while an HTTP/2 request to a local h2 origin succeeded. A second local HTTPS h2 verification with an explicit rejecting HTTP proxy showed the origin received the request and the proxy observed no traffic. ## Proof of Concept of Attack Local constrained demonstration: 1. Start an HTTP/2 server on loopback. 2. Call `axios.get("http://localhost:<port>/internal", { httpVersion: 2, lookup })` where `lookup` throws `EPOLICY`. 3. Observe that the request succeeds and the lookup counter remains `0`. For proxy routing: 1. Start an HTTPS HTTP/2 origin and a local HTTP proxy that rejects every request and CONNECT. 2. Call axios with `httpVersion: 2`, `http2Options: { rejectUnauthorized: false }`, and explicit `proxy`. 3. Observe that the origin receives the request and the proxy receives nothing. Expected safe behavior is that either the lookup policy blocks the request or the proxy observes and rejects the request. ## Workarounds Use the HTTP/1 adapter path for requests that depend on axios `lookup` or proxy controls. Alternatively, enforce destination allow/deny policy before calling axios, outside the adapter transport path. <details> <summary><h3>Original report</h3></summary> ### Summary I found that Axios does not apply the configured `lookup` function or proxy when a request uses `httpVersion: 2`. The HTTP/1 adapter applies both controls, but the HTTP/2 path connects straight to the URL's hostname using `http2.connect()`. This matters for server applications that accept a user-influenced URL and use a custom DNS lookup or mandatory outbound proxy to prevent SSRF. Switching the Axios instance to HTTP/2 silently removes those controls, allowing the request to reach an address the application intended to block. I reproduced this on the current npm release, Axios 1.18.1. ### Details The HTTP adapter reads and wraps the caller's `lookup` function, builds the normal request options, and calls `setProxy()`: - `lib/adapters/http.js`, around lines 530-578: reads and wraps `lookup` - `lib/adapters/http.js`, around lines 895-954: adds `lookup` to `options` and applies `setProxy()` For HTTP/2, however, the adapter selects `http2Transport`. That transport creates an authority from the destination and only passes `options.http2Options` to the session pool: ```js const { http2Options, headers } = options; const session = http2Sessions.getSession(authority, http2Options); ``` `lib/helpers/Http2Sessions.js` then calls: ```js const session = http2.connect(authority, options); ``` At this point `options` is only the `http2Options` object. The top-level `lookup`, the proxy tunnelling agent created by `setProxy()`, and the selected `httpAgent`/`httpsAgent` are not forwarded. The request therefore uses the system resolver and opens a direct connection to the origin. The same root cause affects both explicit proxy configuration and environment-derived proxy configuration. I kept the PoC local and used an explicit proxy so the result does not depend on shell environment variables. ### PoC I attached [axios_http2_transport_controls_poc.mjs](https://drive.google.com/file/d/1lKXBOLDoysOFRmaRyV1tMVLx3P0Ah4gV/view?usp=sharing). The PoC is entirely local and sets up three pieces: 1. An HTTPS origin with HTTP/2 enabled. If reached, it records the request and returns `REACHED_BLOCKED_ORIGIN`. 2. An HTTP proxy that records traffic but rejects every normal request and every CONNECT request with `502 Bad Gateway`. 3. A custom Axios `lookup` callback that rejects every DNS lookup with an `EPOLICY` error. The first request is an HTTP/1 control request. It uses the blocking `lookup` callback and has proxying disabled. Axios calls the callback, receives `EPOLICY`, and does not reach the origin. This confirms that the callback works and that the hostname is blocked through the normal adapter path. The second request targets the same URL with `httpVersion: 2`. It is given both security controls: the same blocking `lookup` callback and the rejecting proxy. If Axios honors either one, this request cannot reach the origin. It should fail with `EPOLICY`, or it should reach the proxy and receive its `502` response. Instead, the request returns HTTP 200 with `REACHED_BLOCKED_ORIGIN`. The lookup counter does not increase, and the proxy records no request or CONNECT attempt. The origin is the only server that records traffic. This shows that the HTTP/2 path skipped both controls and connected directly using the system resolver. To reproduce, run the attachment from the root of an Axios checkout: Run it from the root of an Axios checkout: ```bash git checkout v1.18.1 npm install --ignore-scripts node /path/to/axios_http2_transport_controls_poc.mjs ``` Relevant output from my run: ```json { "axiosVersion": "1.18.1", "configuredControls": { "lookup": "reject every DNS lookup with EPOLICY", "proxy": "http://127.0.0.1:<port> (reject every request)" }, "http1Control": "EPOLICY: blocked by application DNS policy", "http2Result": { "status": 200, "data": "REACHED_BLOCKED_ORIGIN" }, "lookupCalls": 1, "proxyObservedTraffic": false, "events": [ { "server": "origin", "protocol": "h2", "path": "/internal" } ] } ``` The important parts of the output are: - `http1Control` contains `EPOLICY`, proving the DNS policy blocks the destination under HTTP/1. - `lookupCalls` is still `1` after both requests, proving HTTP/2 never called the configured resolver. - `proxyObservedTraffic` is `false`, proving HTTP/2 did not use the configured proxy. - `http2Result.status` is `200`, and the sole event belongs to the origin, proving Axios connected directly to the blocked destination. ### Impact The vulnerable configuration is a Node.js application that: - enables Axios HTTP/2 using `httpVersion: 2`; - lets an application user influence the request destination; and - relies on Axios's `lookup` option or proxy routing to enforce a destination or egress policy. In that setup, an unauthenticated application user may be able to make the server connect directly to loopback, private-network, or link-local services that the lookup policy or proxy would have rejected. Depending on the reachable service, this can expose cloud credentials or internal data, modify internal services, or affect availability. HTTP/2 support is marked experimental, but neither the HTTP/2 documentation nor the proxy documentation says that `lookup` and proxy controls are ignored. The proxy documentation states that HTTPS requests are sent through a CONNECT tunnel. More importantly, Axios's threat model tells callers that destination validation is their responsibility; this behavior silently bypasses such caller-supplied validation. I did not test against any third-party or production service. The PoC only uses listeners on my own machine. </details> ---