CVE-2026-101898: Axios HTTP/2 Adapter Bypasses Configured DNS Vulnerability

HIGH
Advisory Identifier: GHSA-3pq3-5fj3-cg6v
CWE-918
Published
Advisory Summary

CVE-2026-101898 is a HIGH http/2 adapter bypasses configured dns vulnerability (CWE-918: Server-Side Request Forgery (SSRF)) affecting Axios libraries in the npm ecosystem. The issue involves http/2 adapter bypasses configured dns lookup and proxy controls. Remediation is available by upgrading affected packages to version 1.20.0.

CVE-2026-101898 at a Glance

CVE Identifier CVE-2026-101898
GHSA Identifier GHSA-3pq3-5fj3-cg6v
Severity HIGH
CVSS v3.1 Base Score N/A
CWE Classification CWE-918: Server-Side Request Forgery (SSRF)
Affected Product Axios
Package Ecosystem npm
Published Date
Last Updated

How to Fix CVE-2026-101898

To remediate this vulnerability, upgrade all affected Axios dependencies to a patched release. Both direct and transitive dependencies should be checked, as frameworks or security libraries may pull in vulnerable versions transitively.

axios fixed: 1.20.0
npm install axios@1.20.0
Verify Direct and Transitive Dependencies

Run the following command in your project directory to verify that all resolved dependencies use the patched release:

npm ls axios

How to Check if You Are Affected

To determine whether your Node.js application is affected by CVE-2026-101898, inspect your project dependencies using npm:

npm ls axios

Analyze the terminal output to locate any version of Axios in your dependency tree. If any resolved version matches the vulnerable ranges listed in the table below (for example, versions earlier than 1.20.0), your application is affected.

Note: The npm ls axios command inspects dependencies declared in your package.json and lockfile; it does not perform automated runtime dynamic scanning.

Technical Details

Vulnerability Mechanism & Technical Analysis

This vulnerability is classified under CWE-918: Server-Side Request Forgery (SSRF), where the web server receives a url or similar request from an upstream component and retrieves the contents of this url, but it does not sufficiently ensure that the request is being sent to the expected destination. In Axios, software state validation or input boundaries are circumvented during processing. Review the official source advisory statement below for specific affected components, classes, and reproduction details.

Source Advisory Statement

## 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> ---

CVE-2026-101898 Affected Axios Versions

1 component(s)
Fixed Versions:
1.20.0
Product / Package Ecosystem Affected Versions Fixed Version
axios
npm
≥ 1.13.0
< 1.20.0
1.20.0

References

Frequently Asked Questions

What is CVE-2026-101898?
CVE-2026-101898 is a security vulnerability in Axios involving HTTP/2 adapter bypasses configured DNS lookup and proxy controls under CWE-918: Server-Side Request Forgery (SSRF).
Which Axios versions are affected?
Affected versions include releases prior to 1.20.0 across affected packages: axios.
What version fixes CVE-2026-101898?
Upgrading to 1.20.0 (or the latest patched release for your respective branch) resolves the vulnerability.
Is axios affected?
Yes, axios is affected in releases prior to 1.20.0. Upgrade your dependency to 1.20.0 or later.
What CWE is associated with CVE-2026-101898?
CVE-2026-101898 is classified under CWE-918: Server-Side Request Forgery (SSRF) (The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.).
How can I check npm dependencies for CVE-2026-101898?
Run the dependency tree command: 'npm ls axios'. This command lists direct and transitive dependencies in your build configuration so you can verify if a vulnerable version is resolved.
Machine-readable OSV JSON OSV v1.5 Schema
Normalized schema output
{
  "schema_version" : "1.4.0",
  "id" : "GHSA-3pq3-5fj3-cg6v",
  "modified" : "2026-09-30T15:02:14Z",
  "published" : "2026-09-30T15:02:14Z",
  "aliases" : [ "CVE-2026-101898" ],
  "summary" : "Axios: HTTP/2 adapter bypasses configured DNS lookup and proxy controls",
  "details" : "## Summary\n\nAxios 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.\n\nApplications 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.\n\n## Impact\n\nIn 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.\n\nThis 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.\n\n## Affected Functionality\n\nAffected:\n\n- Node.js HTTP adapter with `httpVersion: 2`.\n- `config.lookup` supplied as a DNS policy.\n- Explicit `config.proxy` and environment-derived proxy settings for HTTPS HTTP/2 requests.\n\nNot affected:\n\n- Browser adapters.\n- Node HTTP/1 requests, which pass `lookup` to the transport and apply proxy handling.\n- Applications that validate destination hosts independently before calling axios.\n\n## Technical Details\n\nIn `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:\n\n```js\nconst { http2Options, headers } = options;\nconst session = http2Sessions.getSession(authority, http2Options);\n```\n\n`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.\n\nLocal 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.\n\n## Proof of Concept of Attack\n\nLocal constrained demonstration:\n\n1. Start an HTTP/2 server on loopback.\n2. Call `axios.get(\"http://localhost:<port>/internal\", { httpVersion: 2, lookup })` where `lookup` throws `EPOLICY`.\n3. Observe that the request succeeds and the lookup counter remains `0`.\n\nFor proxy routing:\n\n1. Start an HTTPS HTTP/2 origin and a local HTTP proxy that rejects every request and CONNECT.\n2. Call axios with `httpVersion: 2`, `http2Options: { rejectUnauthorized: false }`, and explicit `proxy`.\n3. Observe that the origin receives the request and the proxy receives nothing.\n\nExpected safe behavior is that either the lookup policy blocks the request or the proxy observes and rejects the request.\n\n## Workarounds\n\nUse 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.\n\n<details>\n  <summary><h3>Original report</h3></summary>\n  \n  ### Summary\n\nI 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()`.\n\nThis 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.\n\nI reproduced this on the current npm release, Axios 1.18.1.\n\n### Details\n\nThe HTTP adapter reads and wraps the caller's `lookup` function, builds the normal request options, and calls `setProxy()`:\n\n- `lib/adapters/http.js`, around lines 530-578: reads and wraps `lookup`\n- `lib/adapters/http.js`, around lines 895-954: adds `lookup` to `options` and applies `setProxy()`\n\nFor HTTP/2, however, the adapter selects `http2Transport`. That transport creates an authority from the destination and only passes `options.http2Options` to the session pool:\n\n```js\nconst { http2Options, headers } = options;\nconst session = http2Sessions.getSession(authority, http2Options);\n```\n\n`lib/helpers/Http2Sessions.js` then calls:\n\n```js\nconst session = http2.connect(authority, options);\n```\n\nAt 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.\n\nThe 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.\n\n### PoC\n\nI 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:\n\n1. An HTTPS origin with HTTP/2 enabled. If reached, it records the request and returns `REACHED_BLOCKED_ORIGIN`.\n2. An HTTP proxy that records traffic but rejects every normal request and every CONNECT request with `502 Bad Gateway`.\n3. A custom Axios `lookup` callback that rejects every DNS lookup with an `EPOLICY` error.\n\nThe 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.\n\nThe 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.\n\nInstead, 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.\n\nTo reproduce, run the attachment from the root of an Axios checkout:\n\nRun it from the root of an Axios checkout:\n\n```bash\ngit checkout v1.18.1\nnpm install --ignore-scripts\nnode /path/to/axios_http2_transport_controls_poc.mjs\n```\n\nRelevant output from my run:\n\n```json\n{\n  \"axiosVersion\": \"1.18.1\",\n  \"configuredControls\": {\n    \"lookup\": \"reject every DNS lookup with EPOLICY\",\n    \"proxy\": \"http://127.0.0.1:<port> (reject every request)\"\n  },\n  \"http1Control\": \"EPOLICY: blocked by application DNS policy\",\n  \"http2Result\": {\n    \"status\": 200,\n    \"data\": \"REACHED_BLOCKED_ORIGIN\"\n  },\n  \"lookupCalls\": 1,\n  \"proxyObservedTraffic\": false,\n  \"events\": [\n    {\n      \"server\": \"origin\",\n      \"protocol\": \"h2\",\n      \"path\": \"/internal\"\n    }\n  ]\n}\n```\n\nThe important parts of the output are:\n\n- `http1Control` contains `EPOLICY`, proving the DNS policy blocks the destination under HTTP/1.\n- `lookupCalls` is still `1` after both requests, proving HTTP/2 never called the configured resolver.\n- `proxyObservedTraffic` is `false`, proving HTTP/2 did not use the configured proxy.\n- `http2Result.status` is `200`, and the sole event belongs to the origin, proving Axios connected directly to the blocked destination.\n\n### Impact\n\nThe vulnerable configuration is a Node.js application that:\n\n- enables Axios HTTP/2 using `httpVersion: 2`;\n- lets an application user influence the request destination; and\n- relies on Axios's `lookup` option or proxy routing to enforce a destination or egress policy.\n\nIn 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.\n\nHTTP/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.\n\nI did not test against any third-party or production service. The PoC only uses listeners on my own machine.\n</details>\n\n---",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "npm",
      "name" : "axios"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "1.13.0"
      }, {
        "fixed" : "1.20.0"
      } ]
    } ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/axios/axios/security/advisories/GHSA-3pq3-5fj3-cg6v"
  }, {
    "type" : "ADVISORY",
    "url" : "https://nvd.nist.gov/vuln/detail/CVE-2026-101898"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/axios/axios/pull/11141"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/axios/axios/commit/d19040bda7a8be2f82c3c6e1a5bc03917daee39a"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/axios/axios"
  }, {
    "type" : "WEB",
    "url" : "https://github.com/axios/axios/releases/tag/v1.20.0"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-918" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-09-30T15:02:14Z",
    "nvd_published_at" : "2026-09-28T18:17:17Z"
  }
}