Security patches (stable/1.x) by renovate[bot] · Pull Request #449 · DefGuard/defguard-renovate

renovate · 2026-07-16T07:39:32Z

ℹ️ Note

This PR body was truncated due to platform limits.

This PR contains the following updates:

Package	Change	Type	Update
@babel/core (source)	`7.29.0` → `7.29.6`	devDependencies	patch
ammonia	`4.1.3` → `4.1.4`	dependencies	patch
axios (source)	`1.18.1` → `1.20.0`	dependencies	minor
postcss (source)	`8.5.8` → `8.5.23`	devDependencies	patch
qs	`6.15.3` → `6.16.0`	dependencies	minor
react-router-dom (source)	`6.30.4` → `6.30.6`	dependencies	patch
vite (source)	`7.3.1` → `7.3.5`	devDependencies	patch
vitest (source)	`4.0.18` → `4.1.11`	devDependencies	minor
webauthn-authenticator-rs	`0.5.4` → `0.5.5`	dev-dependencies	patch
webauthn-authenticator-rs	`0.5.4` → `0.5.5`	workspace.dependencies	patch

@babel/core: Arbitrary File Read via sourceMappingURL Comment

CVE-2026-49356 / GHSA-4x5r-pxfx-6jf8

More information

Details

Impact

Using @babel/core to compile maliciously crafted code can allow ab attacker to read any source map from the system that is running Babel, if these conditions are all true:

the attacker controls the input source code
the attacker can read the output source code
the attacker knows the path of the source map file that they want to read

Users that only compile trusted code are not impacted.

Patches

The vulnerability has been fixed in @babel/core@7.29.6 and @babel/core@8.0.0-rc.6.

Workarounds

Callers can mitigate the issue without upgrading by setting inputSourceMap: false in their Babel options.

Callers can also manually extract the #sourceMappingURL comment from the input source code, validate whether the source map that it links to is allowed to be read, and if it is pass an object to inputSourceMap (passing false when it's not).

Credits

Thanks Teodor-Cristian Radoi for reporting the vulnerability.

Severity

CVSS Score: 3.2 / 10 (Low)
Vector String: CVSS:3.1/AV:L/AC:H/PR:N/UI:N/S:C/C:L/I:N/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Ammonia: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

CVE-2026-102342 / GHSA-m6mh-2hw2-555x

More information

Details

The following SVG will produce a link with a javascript scheme. If the user clicks this link, they will run it.

<svg xmlns="http://www.w3.org/2000/svg">
  <a>
    <set attributeName="href" to="javascript:alert('SET_XSS')"></set>
    <text y="30">Click set</text>
  </a>
</svg>

Impact

Allows stored XSS in applications that allow the animate and set tags.

Patches

Fixed in 3.3.3, 4.0.3, and 4.1.4

Workarounds

Do not enable the animate or set tags.

Severity

CVSS Score: 5.4 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

References

This data is provided by the GitHub Advisory Database (CC-BY 4.0).

Ammonia: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

CVE-2026-102342 / GHSA-m6mh-2hw2-555x / RUSTSEC-2026-0213

More information

Details

The following SVG will produce a link with a javascript scheme. If the user clicks this link, they will run it.

<svg xmlns="http://www.w3.org/2000/svg">
  <a>
    <set attributeName="href" to="javascript:alert('SET_XSS')"></set>
    <text y="30">Click set</text>
  </a>
</svg>

Impact

Allows stored XSS in applications that allow the animate and set tags.

Patches

Fixed in 3.3.3, 4.0.3, and 4.1.4

Workarounds

Do not enable the animate or set tags.

Severity

CVSS Score: 5.4 / 10 (Medium)
Vector String: CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

XSS in ammonia via SVG `animate` and `set` animation tags

CVE-2026-102342 / GHSA-m6mh-2hw2-555x / RUSTSEC-2026-0213

More information

Details

The following SVG will produce a link with a javascript scheme.
If the user clicks this link, they will run it.

<svg xmlns="http://www.w3.org/2000/svg">
  <a>
    <set attributeName="href" to="javascript:alert('SET_XSS')"></set>
    <text y="30">Click set</text>
  </a>
</svg>

Ammonia did not apply attribute filters based on attributeName,
so the contents of the to, from, and values tags were not sanitized as URLs.

Applications that do not explicitly allow either of these tags should not be affected,
since neither are allowed by default.

Discovered by: Younghun Ko (@koyokr)

Severity

Unknown

References

This data is provided by OSV and the Rust Advisory Database (CC0 1.0).

Axios: HTTP/2 adapter bypasses configured DNS lookup and proxy controls

CVE-2026-101898 / GHSA-3pq3-5fj3-cg6v

More information

Details

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:

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:

Start an HTTP/2 server on loopback.
Call axios.get("http://localhost:<port>/internal", { httpVersion: 2, lookup }) where lookup throws EPOLICY.
Observe that the request succeeds and the lookup counter remains 0.

For proxy routing:

Start an HTTPS HTTP/2 origin and a local HTTP proxy that rejects every request and CONNECT.
Call axios with httpVersion: 2, http2Options: { rejectUnauthorized: false }, and explicit proxy.
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.

Original report

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:

const { http2Options, headers } = options;
const session = http2Sessions.getSession(authority, http2Options);

lib/helpers/Http2Sessions.js then calls:

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. The PoC is entirely local and sets up three pieces:

An HTTPS origin with HTTP/2 enabled. If reached, it records the request and returns REACHED_BLOCKED_ORIGIN.
An HTTP proxy that records traffic but rejects every normal request and every CONNECT request with 502 Bad Gateway.
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:

git checkout v1.18.1
npm install --ignore-scripts
node /path/to/axios_http2_transport_controls_poc.mjs

Relevant output from my run:

{
  "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.

Severity

CVSS Score: 7.0 / 10 (High)
Vector String: 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

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Axios: CIDR-form NO_PROXY entries are ignored, causing proxy exclusion bypass for internal IP ranges

CVE-2026-101899 / GHSA-44g4-m2mj-wpvx

More information

Details

Summary

Axios supports proxy environment variables and evaluates NO_PROXY exclusions in the Node.js adapter. CIDR-form NO_PROXY entries such as 127.0.0.0/8, 10.0.0.0/8, or 169.254.169.254/32 are not interpreted as IP ranges. As a result, a request to an IP address inside a configured CIDR exclusion can still be sent through the configured proxy.

This affects deployments that rely on CIDR notation to keep loopback, private, Kubernetes, CI, or cloud metadata traffic away from proxy infrastructure.

Impact

If the configured proxy is outside the intended trust boundary, requests that operators expected to bypass the proxy may be exposed to it. For plaintext HTTP targets, the proxy can see and modify URLs, headers, and bodies. For HTTPS targets, the proxy still observes connection metadata and may receive CONNECT requests that policy expected to avoid.

This is a proxy exclusion bypass, not arbitrary proxy injection by itself.

Affected Functionality

Affected:

Node.js adapter proxy environment handling.
HTTP_PROXY, HTTPS_PROXY, NO_PROXY, or lowercase equivalents.
CIDR entries in NO_PROXY.

Not affected:

Exact host or exact IP NO_PROXY entries where axios matching succeeds.
Requests configured with proxy: false.
Browser adapters.

Technical Details

lib/helpers/shouldBypassProxy.js parses each NO_PROXY entry into a host and optional port, normalizes hostnames, and then compares exact hostnames, suffix entries, wildcard-prefix entries, and loopback equivalents. It does not parse CIDR notation.

Local verification on axios 1.18.1:

process.env.NO_PROXY = '127.0.0.0/8';
shouldBypassProxy('http://127.0.0.1:1234/'); // false

The expected result for CIDR-aware bypass policy is true.

Proof of Concept of Attack

Constrained local demonstration:

Set HTTP_PROXY=http://127.0.0.1:<proxy-port>.
Set NO_PROXY=127.0.0.0/8.
Request http://127.0.0.1:<internal-port>/metadata.
Observe that axios sends the request through the proxy instead of directly to the internal listener.

Workarounds

Use exact host or IP entries in NO_PROXY for sensitive destinations until CIDR matching is fixed, for example 127.0.0.1,localhost,169.254.169.254. For individual requests that must not use a proxy, set proxy: false.

Original report

Summary

Axios 1.17.0 honors HTTP_PROXY / HTTPS_PROXY and supports NO_PROXY host exclusions, but CIDR-form NO_PROXY entries such as 127.0.0.0/8 are not treated as network ranges. As a result, requests to IPs covered by a configured CIDR exclusion may still be sent through the configured proxy.

In the attached PoC, a request to 127.0.0.1 is sent through HTTP_PROXY despite NO_PROXY=127.0.0.0/8.

This can cause proxy exclusion bypass in environments where operators use CIDR notation to exclude loopback, private, internal, Kubernetes, CI, or cloud metadata address ranges from proxying.

Details

Axios supports proxy environment variables, including HTTP_PROXY / HTTPS_PROXY and NO_PROXY-style exclusions. Axios’s threat model treats environment proxy handling as security-relevant and lists NO_PROXY as a mitigation for proxy environment variable hijack, including hardening for CIDR ranges, IPv6 literals, and wildcard patterns. See: https://github.com/axios/axios/blob/a8e4f13aeecc45a3b8fab3ecfd9ddb5d70fb772b/THREATMODEL.md#t-r9-proxy-environment-variable-hijack

The issue is that CIDR-form NO_PROXY entries are not interpreted as network ranges. For example:

NO_PROXY=127.0.0.0/8
HTTP_PROXY=http://127.0.0.1:<proxy-port>
Target URL=http://127.0.0.1:<internal-port>/metadata

Since 127.0.0.1 is inside 127.0.0.0/8, an operator may reasonably expect Axios to bypass the proxy for this request. Instead, Axios sends the request through HTTP_PROXY.

This appears to affect the proxy bypass decision path used for NO_PROXY / no_proxy handling. The relevant behavior is in Axios's Node proxy handling and NO_PROXY evaluation logic, including the shouldBypassProxy helper introduced for no_proxy hostname normalization and bypass checks.

The issue is not that Axios ignores NO_PROXY entirely. Exact host exclusions work. The issue is specifically that CIDR-form exclusions are silently treated as non-matching host/domain tokens rather than as network ranges, causing the request to be proxied.

This is security-relevant because CIDR notation is commonly used in container, CI, enterprise proxy, and cloud environments for ranges such as:

127.0.0.0/8
10.0.0.0/8
172.16.0.0/12
192.168.0.0/16
169.254.169.254/32

If operators rely on those entries to prevent internal or metadata-style requests from traversing a proxy, Axios may violate that expectation.

PoC

import http from 'http';
import axios from 'axios';

function listen(server, host) {
  return new Promise((resolve, reject) => {
    server.once('error', reject);
    server.listen(0, host, () => resolve(server.address().port));
  });
}

function close(server) {
  return new Promise((resolve) => server.close(resolve));
}

let proxyHits = 0;
let internalHits = 0;

const internal = http.createServer((req, res) => {
  internalHits += 1;
  res.writeHead(200, { 'content-type': 'text/plain' });
  res.end(`internal service saw ${req.url}`);
});

const proxy = http.createServer((req, res) => {
  proxyHits += 1;
  res.writeHead(200, { 'content-type': 'text/plain' });
  res.end(`proxy saw request for ${req.url}`);
});

const internalHost = process.env.POC_INTERNAL_HOST || '127.0.0.2';
const proxyHost = process.env.POC_PROXY_HOST || '127.0.0.1';

let internalPort;
let proxyPort;

try {
  internalPort = await listen(internal, internalHost);
  proxyPort = await listen(proxy, proxyHost);
} catch (error) {
  console.error('Failed to bind local PoC servers.');
  console.error('On some systems 127.0.0.2 is unavailable; try:');
  console.error('  POC_INTERNAL_HOST=127.0.0.1 node poc-no-proxy-cidr-axios.mjs');
  console.error('');
  throw error;
}

const targetUrl = `http://${internalHost}:${internalPort}/metadata`;
const proxyUrl = `http://${proxyHost}:${proxyPort}`;
const noProxy = process.env.POC_NO_PROXY || '127.0.0.0/8';

process.env.http_proxy = proxyUrl;
process.env.HTTP_PROXY = proxyUrl;
process.env.no_proxy = noProxy;
process.env.NO_PROXY = noProxy;

console.log('Axios NO_PROXY CIDR full axios network PoC');
console.log(`axios VERSION=${axios.VERSION || 'unknown'}`);
console.log(`NO_PROXY=${process.env.no_proxy}`);
console.log(`HTTP_PROXY=${process.env.http_proxy}`);
console.log(`Target URL=${targetUrl}`);
console.log('');

try {
  const response = await axios.get(targetUrl, {
    timeout: 2000,
  });

  console.log(`Response=${response.data}`);
  console.log(`Proxy hits=${proxyHits}`);
  console.log(`Internal direct hits=${internalHits}`);
  console.log('');

  if (proxyHits > 0 && internalHits === 0) {
    console.log(`POC RESULT: axios sent the target through the proxy with NO_PROXY=${noProxy}.`);
  } else if (proxyHits === 0 && internalHits > 0) {
    console.log(`POC RESULT: axios bypassed the proxy with NO_PROXY=${noProxy}.`);
  } else {
    console.log('POC RESULT: mixed/ambiguous routing; inspect counts above.');
  }
} finally {
  delete process.env.http_proxy;
  delete process.env.HTTP_PROXY;
  delete process.env.no_proxy;
  delete process.env.NO_PROXY;
  await close(proxy);
  await close(internal);
}

Run the failing CIDR case:

POC_INTERNAL_HOST=127.0.0.1 node poc-no-proxy-cidr-axios.mjs

Observed:

Axios NO_PROXY CIDR full axios network PoC
axios VERSION=1.17.0
NO_PROXY=127.0.0.0/8
HTTP_PROXY=http://127.0.0.1:34315
Target URL=http://127.0.0.1:43993/metadata

Response=proxy saw request for http://127.0.0.1:43993/metadata
Proxy hits=1
Internal direct hits=0

POC RESULT: axios sent the target through the proxy with NO_PROXY=127.0.0.0/8.

Control

Axios does honor exact IP NO_PROXY entries:

POC_INTERNAL_HOST=127.0.0.1 POC_NO_PROXY=127.0.0.1 node poc-no-proxy-cidr-axios.mjs

Expected:

NO_PROXY=127.0.0.1
Response=internal service saw /metadata
Proxy hits=0
Internal direct hits=1

POC RESULT: axios bypassed the proxy with NO_PROXY=127.0.0.1.

This shows the issue is not that NO_PROXY is ignored entirely. The bypass failure is specific to CIDR-form entries such as 127.0.0.0/8.

Impact

This is a proxy exclusion bypass caused by unsupported CIDR matching in NO_PROXY.

The impact is configuration-dependent. It affects Axios users in Node.js environments who rely on proxy environment variables and configure NO_PROXY using CIDR notation to exclude internal, loopback, private, Kubernetes, CI, or cloud metadata ranges.

Potentially impacted environments include:

CI/CD runners with globally injected HTTP_PROXY / HTTPS_PROXY.
Containers inheriting proxy variables from the host or orchestrator.
Kubernetes workloads using NO_PROXY for cluster-internal service ranges.
Enterprise networks using HTTP proxies with internal network exclusions.
Cloud workloads relying on NO_PROXY to keep metadata or internal service requests off proxy infrastructure.

If a configured proxy is compromised, attacker-controlled, overly broad, or outside the intended trust boundary, requests that operators expected to stay direct may instead be exposed to that proxy. This may expose request URLs, internal hostnames, paths, headers, or credentials depending on application behavior.

This should not be characterized as arbitrary proxy injection by itself. The issue is that Axios silently fails to enforce common CIDR-form proxy exclusions, which can undermine proxy bypass policy and defense-in-depth assumptions.

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Axios: Fetch Adapter Header Injection via Inherited FormData getHeaders

CVE-2026-101900 / GHSA-4hqw-qxg8-jxx2

More information

Details

Summary

Axios contains a guard in the Node HTTP adapter to avoid using an inherited Object.prototype.getHeaders as a FormData header source. The fetch adapter calls the shared resolveConfig() helper before dispatch, and that helper lacks the same guard. If another vulnerability pollutes Object.prototype with FormData-like properties and getHeaders(), the fetch adapter can merge attacker-controlled headers into the outbound request.

Axios does not create the prototype pollution source. This is a read-side gadget in the fetch adapter configuration path.

Impact

An attacker with a prior same-process prototype-pollution primitive can inject headers into fetch-adapter requests. Depending on the target service, this may affect authorization, metadata-service access, cache behavior, conditional request handling, or other application-specific header logic.

Plain objects are blocked by current FormData detection. The confirmed path uses arrays or non-plain class instances whose prototype chain can resolve polluted FormData-like properties.

Affected Functionality

Affected:

Fetch adapter requests.
resolveConfig() handling of utils.isFormData(data).
Request bodies that can be spoofed as FormData through inherited Symbol.toStringTag, append, and getHeaders.

Not affected:

Node HTTP adapter's later FormData header path, which checks data.getHeaders !== Object.prototype.getHeaders.
Plain object request bodies rejected by current isFormData() plain-object guard.
Processes without prototype pollution.

Technical Details

lib/helpers/resolveConfig.js currently contains:

if (utils.isFormData(data)) {
  if (platform.hasStandardBrowserEnv || platform.hasStandardBrowserWebWorkerEnv || utils.isReactNative(data)) {
    headers.setContentType(undefined);
  } else if (utils.isFunction(data.getHeaders)) {
    setFormDataHeaders(headers, data.getHeaders(), own('formDataHeaderPolicy'));
  }
}

Unlike lib/adapters/http.js, this code does not reject Object.prototype.getHeaders. Local verification on axios 1.18.1 polluted Object.prototype[Symbol.toStringTag], append, and getHeaders, then sent an array body with adapter: 'fetch'. The loopback server received X-Poisoned: yes.

Proof of Concept of Attack

Constrained local demonstration:

Object.prototype[Symbol.toStringTag] = 'FormData';
Object.prototype.append = function () {};
Object.prototype.getHeaders = () => ({ 'X-Poisoned': 'yes' });

await axios.post(url, ['a', 'b'], { adapter: 'fetch' });

Expected safe behavior is that inherited Object.prototype.getHeaders is ignored. Current affected behavior merges the returned header.

Workarounds

Use the Node HTTP adapter for server-side requests that may run in a polluted process. Avoid passing array or class-instance bodies through the fetch adapter when prototype pollution is suspected.

Original report

Summary

The Node HTTP adapter contains a guard that prevents Object.prototype.getHeaders from being used as a FormData header source. The shared resolveConfig() helper does not have the same guard. The fetch adapter calls resolveConfig(), so it can still merge headers returned by inherited data.getHeaders().

This is a patch mismatch for the FormData prototype-pollution header-injection class.

Affected Version

Validated on:

axios: 1.17.0
commit: 4306df2
runtime: Node.js v24.15.0

Preconditions

Application uses adapter: 'fetch'.
A separate prototype-pollution primitive can write:
- Object.prototype[Symbol.toStringTag] = 'FormData'
- Object.prototype.append = function () {}
- Object.prototype.getHeaders = function () { ... }
The request body is an array or custom class instance. Plain objects are blocked by the current isFormData() plain-object guard.

Root Cause

lib/adapters/http.js contains:

data.getHeaders !== Object.prototype.getHeaders

But lib/helpers/resolveConfig.js only checks:

} else if (utils.isFunction(data.getHeaders)) {
  setFormDataHeaders(headers, data.getHeaders(), own('formDataHeaderPolicy'));
}

The fetch adapter calls resolveConfig(config) before dispatching the request.

Impact

An attacker can inject arbitrary headers into fetch-adapter requests. This may be used to influence internal APIs, metadata services, cache behavior, or application-specific authorization checks.

Proof of Concept

import axios from './index.js';
import http from 'http';

const start = (handler) => new Promise((resolve) => {
  const server = http.createServer((req, res) => {
    let body = '';
    req.on('data', (chunk) => (body += chunk));
    req.on('end', () => handler(req, res, body));
  });
  server.listen(0, '127.0.0.1', () => resolve(server));
});

const stop = (server) => new Promise((resolve) => server.close(resolve));

const hits = [];
const tag = Symbol.toStringTag;

const server = await start((req, res, body) => {
  hits.push({ headers: req.headers, body });
  res.setHeader('Content-Type', 'application/json');
  res.end('{"ok":true}');
});

try {
  Object.prototype[tag] = 'FormData';
  Object.prototype.append = function () {};
  Object.prototype.getHeaders = () => {
    const headers = Object.create(null);
    headers['X-Poisoned'] = 'yes';
    return headers;
  };

  await axios.post(`http://127.0.0.1:${server.address().port}/fetch-formdata`, ['a', 'b'], {
    adapter: 'fetch',
    timeout: 3000
  });

  console.log(hits[0]);
} finally {
  delete Object.prototype[tag];
  delete Object.prototype.append;
  delete Object.prototype.getHeaders;
  await stop(server);
}

Observed wire request:

{
  "headers": {
    "x-poisoned": "yes",
    "content-type": "text/plain;charset=UTF-8",
    "content-length": "3"
  },
  "body": "a,b"
}

References

GHSA-6chq-wfr3-2hj9
https://osv.dev/vulnerability/GHSA-6chq-wfr3-2hj9
Related patch area: lib/adapters/http.js, lib/helpers/resolveConfig.js

Severity

CVSS Score: 6.9 / 10 (Medium)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:N/SC:L/SI:H/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Axios: Denial of Service via Unhandled 'error' Event in HTTP/2 ClientHttp2Session Initialization

CVE-2026-101901 / GHSA-542g-h47m-68v8

More information

Details

Summary

Axios versions with Node.js HTTP/2 support can terminate the caller’s process when a ClientHttp2Session emits an error event that is not handled by axios.

This affects applications that use the Node HTTP adapter with httpVersion: 2. A malicious, unavailable, or non-HTTP/2 endpoint can cause an uncaught exception instead of a normal rejected axios request.

Impact

The impact is denial of service. In affected applications, an attacker who can influence the request destination, or operate the destination server, may be able to crash the Node.js process.

This does not affect default HTTP/1.1 usage, browser XHR/fetch adapters, or applications that do not enable axios HTTP/2 support.

Affected Functionality

Affected path:

Node.js HTTP adapter
httpVersion: 2
HTTP/2 session creation/reuse through Http2Sessions
Network/session failures emitted as ClientHttp2Session error events

Caller-controlled http2Options can make the issue easier to trigger, but passing arbitrary attacker input into axios config is caller-controlled behavior and should not be the primary advisory framing.

Technical Details

Http2Sessions.getSession() creates a session with http2.connect(authority, options) but only registers a close handler. It does not register an error handler on the returned ClientHttp2Session.

When the session emits error, Node treats it as an unhandled EventEmitter error and throws. This can bypass the normal axios Promise rejection path and terminate the process.

Proof of Concept of Attack

import axios from './index.js';

await axios.get('http://127.0.0.1:1/', {
  httpVersion: 2,
  timeout: 1000
});

Expected vulnerable behavior: the process exits with an uncaught ECONNREFUSED session error instead of only rejecting the axios request.

Workarounds

Disable axios HTTP/2 for untrusted or user-influenced destinations and use the default HTTP/1.1 adapter until a fixed release is available. Also avoid passing attacker-controlled values into http2Options; axios config is trusted application input.

Original report

Hi, i'm RelunSec a security researcher working with InsiteTech.jp

i want let you known, i finded a DoS in axios, to reproduce that, that is the example of a server

const http = require('http');
// Import the local axios version to ensure the patch is active
const axios = require('../../lib/axios.js').default; 
const url = require('url');

// A public HTTP/2 server to make internal requests to.
// This simulates an external service your application might interact with over HTTP/2.
const TARGET_URL = 'https://nghttp2.org/'; 
const PORT = 3000;

const server = http.createServer(async (req, res) => {
  const parsedUrl = url.parse(req.url, true);
  const http2optionId = parsedUrl.query.http2optionId;

  if (!http2optionId) {
  console.warn(`[SERVER] Rejected request: Missing http2optionId parameter`);
  res.writeHead(400, { 'Content-Type': 'text/plain' });
  res.end('Error: Missing http2optionId query parameter. Usage: ?http2optionId=value\n');
  return; 
}

  console.log(`[SERVER] Received request with http2optionId: ${http2optionId}`);

  // Create an Axios instance configured for HTTP/2
  // The 'id' in http2Options makes each session configuration unique.
  const axiosInstance = axios.create({
    baseURL: TARGET_URL,
    httpVersion: 2,
    http2Options: {
      // rejectUnauthorized: false, // Uncomment if targeting a local HTTP/2 server with self-signed cert
      id: http2optionId, // This is the attacker-controlled unique part
    },
    // Adding a short timeout to prevent attacker from waiting too long if target is slow
    timeout: 5000 
  });

  try {
    const response = await axiosInstance.get('/');
    res.writeHead(200, { 'Content-Type': 'text/plain' });
    res.end(`Internal HTTP/2 request successful for ID: ${http2optionId}\nStatus: ${response.status}`);
  } catch (error) {
    // Check for the specific error indicating session limit reached
    if (error.isAxiosError && error.code === axios.AxiosError.ERR_BAD_OPTION_VALUE) {
      console.error(`[SERVER] Internal HTTP/2 request failed for ID: ${http2optionId}: ${error.message}`);
      res.writeHead(500, { 'Content-Type': 'text/plain' });
      res.end(`Internal HTTP/2 request failed for ID: ${http2optionId}: ${error.message}`);
    } else {
      console.error(`[SERVER] Internal HTTP/2 request failed for ID: ${http2optionId}:`, error.message);
      res.writeHead(500, { 'Content-Type': 'text/plain' });
      res.end(`Internal HTTP/2 request failed for ID: ${http2optionId}: Generic error - ${error.message}`);
    }
  }
});

server.listen(PORT, () => {
  console.log(`PoC Server listening on http://localhost:${PORT}`);
  console.log(`Targeting internal HTTP/2 requests to: ${TARGET_URL}`);
  console.log(`Send requests to http://localhost:${PORT}?http2optionId=...`);
  console.log(`Expected behavior with current patch: After ~100 unique http2optionIds, subsequent requests will receive ERR_BAD_OPTION_VALUE.`);
});

i tested all that in latest git version, after starting the server.cjs, to trigger that you just need do

relunsec@relunsec:~/software/axios-1/poc/poc$ curl http://127.0.0.1:3000/?http2optionId=hi
curl: (52) Empty reply from server

that is extremly simple to trigger

it confirms a DoS in the HTTP/2 session cache, that needs be patched, the impact is will lead the server crashes and shutdown by an attacker, the server is written properly and no flaws in it and try catch blocks and errors handled however because that is an axios internal error will crash

Severity

CVSS Score: 8.2 / 10 (High)
Vector String: CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

References

This data is provided by OSV and the GitHub Advisory Database (CC-BY 4.0).

Axios: Prototype-Pollution Gadget in the Default Instance Allows Inherited Object.prototype.method to Override HTTP Method

CVE-2026-101902 / GHSA-9fr6-4gfg-395g

More information

Details

Summary

Axios default-instance requests that omit an explicit method can read an inherited method value from Object.prototype. If another vulnerability in the same process pollutes Object.prototype.method, calls such as axios.request({ url }) and axios({ url }) can send a state-changing HTTP method instead of the expected default GET.

Axios does not create the prototype pollution source. This is a read-side gadget in axios request dispatch.

Impact

In an affected application with a separate prototype-pollution primitive, an attacker can change axios default-instance requests that omit method from GET to methods such as DELETE, POST, PUT, or PATCH. The practical impact depends on the target endpoint and can include unintended writes, deletion, or other state changes.

Method aliases such as axios.get(url) and requests with an explicit own method are not affected by the confirmed method path.

Affected Functionality

Affected:

Default axios instance calls: axios.request({ url }).
Callable shorthand: axios({ url }).
Requests where no own config.method is provided.

Not affected in the confirmed method PoC:

axios.get(url) and other method aliases.
axios.request({ url, method: 'GET' }).
axios.create().request({ url }) when the created instance defaults are produced by current mergeConfig() and do not inherit from Object.prototype.

Technical Details

lib/core/Axios.js sets the request method with:

config.method = (config.method || this.defaults.method || 'get').toLowerCase();

mergeConfig() now returns a null-prototype request config, so config.method is safe from Object.prototype. However, the default axios instance stores the module defaults object as this.defaults, and that defaults object is a normal object. If Object.prototype.method exists, this.defaults.method resolves to the polluted inherited value.

Local verification on axios 1.18.1 showed a default-instance axios.request({ url }) request reaching a loopback server as DELETE after Object.prototype.method = 'DELETE'.

Proof of Concept of Attack

Constrained local demonstration:

Object.prototype.method = 'DELETE';
try {
  await axios.request({ url: 'http://127.0.0.1:<port>/resource' });
} finally {
  delete Object.prototype.method;
}

Expected safe behavior is a GET request. Current affected behavior sends DELETE on the default instance when no method is provided.

Workarounds

Use explicit method aliases such as axios.get() or set an own method on request configs. Avoid default-instance shorthand for requests in processes where prototype pollution is suspected or possible.

Original report

Summary

Axios 1.17.0 contains a read-side prototype-pollution gadget in the default Axios instance. If another vulnerability in the same Node.js process pollutes Object.prototype.method, default-instance calls such as axios.request({ url }) and axios({ url }) can be forced to use an attacker-controlled HTTP method, such as DELETE, instead of the expected default GET.

Axios does not create the prototype pollution by itself. The issue is that Axios reads fallback values from this.defaults without an own-property guard, allowing inherited values from Object.prototype to influence request behavior.

This should be treated as a prototype-pollution gadget, not as a standalone prototype-pollution source. In other words, Axios is not the component that lets the attacker write to Object.prototype; Axios is the component that becomes dangerous after Object.prototype has already been polluted by another bug in the same process.

Details

The vulnerable fallback read is in lib/core/Axios.js:

// Set config.allowAbsoluteUrls
if (config.allowAbsoluteUrls !== undefined) {
  // do nothing
} else if (this.defaults.allowAbsoluteUrls !== undefined) {
  config.allowAbsoluteUrls = this.defaults.allowAbsoluteUrls;
} else {
  config.allowAbsoluteUrls = true;
}

// Set config.method
config.method = (config.method || this.defaults.method || 'get').toLowerCase();

The merged request config is created as a null-prototype object in lib/core/mergeConfig.js:

const config = Object.create(null);

Therefore, when the caller does not provide config.method, the fallback becomes:

this.defaults.method

The default Axios instance uses the module defaults object. In the tested version, that defaults object is affected by inherited properties from Object.prototype. If Object.prototype.method is polluted, this.defaults.method resolves to that inherited value and Axios uses it as the request method.

The same unsafe inherited-property pattern also affects this.defaults.allowAbsoluteUrls, which can change how absolute URLs are combined with baseURL.

Proof of Concept

Access and Attack Conditions

No admin access is required for Axios itself. This is a library-level gadget.

The attacker must have an existing way to pollute Object.prototype in the same Node.js process, for example through a separate prototype-pollution vulnerability in another dependency or application input path. Axios is the gadget that turns that pollution into dangerous HTTP request behavior.

Required condition:

Some other bug or unsafe merge path in the application must allow Object.prototype pollution.

What Axios contributes:

Axios reads inherited Object.prototype.method through this.defaults.method and uses it as the HTTP method fallback.

What Axios does not do:

Axios does not create Object.prototype pollution by itself.

Affected usage:

axios.request({ url });
axios({ url });

Not affected in the confirmed PoC:

axios.get(url);
axios.request({ url, method: "GET" });
axios.create().request({ url });

Reproduction Steps

Create a clean test directory and install Axios 1.17.0:

mkdir axios-validation
cd axios-validation
npm init -y
npm install axios@1.17.0 --no-audit --no-fund

Save the method override PoC below as:

validate-prototype-method-gadget.mjs

Run the PoC:

node validate-prototype-method-gadget.mjs

Confirm that the output shows:

defaultRequestMethod=DELETE
defaultShorthandMethod=DELETE
getAliasMethod=GET
explicitGetMethod=GET
createdInstanceMethod=GET
RESULT: CONFIRMED

This proves that after Object.prototype.method = "DELETE", default-instance calls that omit an explicit method are sent as DELETE.

What the Method PoC Script Does

The PoC starts a temporary local HTTP server for each Axios call and records the HTTP method received by that server. It then simulates an already-existing prototype-pollution condition by setting:

Object.prototype.method = "DELETE";

While that pollution is active, the script sends five Axios requests:

axios.request({ url });                 // expected vulnerable path
axios({ url });                         // expected vulnerable shorthand path
axios.get(url);                         // expected safe alias path
axios.request({ url, method: "GET" });  // expected safe explicit-method path
axios.create().request({ url });        // expected safe isolated-instance path

The script then deletes the polluted property:

delete Object.prototype.method;

Finally, it prints the method observed by the local server for each request. The vulnerable behavior is confirmed when the default Axios instance sends DELETE for axios.request({ url }) and axios({ url }), while the safe comparison paths still send GET.

Method Override PoC

Create validate-prototype-method-gadget.mjs:

import http from "node:http";
import axios from "axios";

async function listen(server) {
  await new Promise((resolve) => server.listen(0, "127.0.0.1", resolve));
  return server.address().port;
}

async function runRequest(label, requestFn) {
  const hits = [];
  const server = http.createServer((req, res) => {
    hits.push({
      method: req.method,
      url: req.url,
    });
    res.writeHead(200, { "content-type": "a

> ❗ **Important**
> 
> ✂ PR body was truncated to here.

renovate · 2026-07-16T07:39:34Z

⚠️ Artifact update problem

Renovate failed to update artifacts related to this branch. You probably do not want to merge this PR as-is.

♻ Renovate will retry this branch, including artifacts, only when one of the following happens:

any of the package files in this branch needs updating, or
the branch becomes conflicted, or
you click the rebase/retry checkbox if found above, or
you rename this PR's title to start with "rebase!" to trigger it manually

The artifact failure details are included below:

File name: Cargo.lock

    Updating crates.io index
error: failed to select a version for `base64urlsafedata`.
    ... required by package `webauthn-rs v0.5.4`
    ... which satisfies dependency `webauthn-rs = "^0.5"` (locked to 0.5.4) of package `defguard_core v0.0.0 (/tmp/renovate/repos/github/DefGuard/defguard-renovate/crates/defguard_core)`
    ... which satisfies path dependency `defguard_core` (locked to 0.0.0) of package `defguard v0.0.0 (/tmp/renovate/repos/github/DefGuard/defguard-renovate/crates/defguard)`
versions that meet the requirements `=0.5.4` are: 0.5.4

all possible versions conflict with previously selected packages

  previously selected package `base64urlsafedata v0.5.5`
    ... which satisfies dependency `base64urlsafedata = "=0.5.5"` of package `webauthn-authenticator-rs v0.5.5`
    ... which satisfies dependency `webauthn-authenticator-rs = "^0.5"` of package `defguard_core v0.0.0 (/tmp/renovate/repos/github/DefGuard/defguard-renovate/crates/defguard_core)`
    ... which satisfies path dependency `defguard_core` (locked to 0.0.0) of package `defguard v0.0.0 (/tmp/renovate/repos/github/DefGuard/defguard-renovate/crates/defguard)`

failed to select a version for `base64urlsafedata` which could resolve this conflict

File name: Cargo.lock

    Updating crates.io index
error: failed to select a version for `base64urlsafedata`.
    ... required by package `webauthn-rs v0.5.4`
    ... which satisfies dependency `webauthn-rs = "^0.5"` (locked to 0.5.4) of package `defguard_core v0.0.0 (/tmp/renovate/repos/github/DefGuard/defguard-renovate/crates/defguard_core)`
    ... which satisfies path dependency `defguard_core` (locked to 0.0.0) of package `defguard v0.0.0 (/tmp/renovate/repos/github/DefGuard/defguard-renovate/crates/defguard)`
versions that meet the requirements `=0.5.4` are: 0.5.4

all possible versions conflict with previously selected packages

  previously selected package `base64urlsafedata v0.5.5`
    ... which satisfies dependency `base64urlsafedata = "=0.5.5"` of package `webauthn-authenticator-rs v0.5.5`
    ... which satisfies dependency `webauthn-authenticator-rs = "^0.5"` of package `defguard_core v0.0.0 (/tmp/renovate/repos/github/DefGuard/defguard-renovate/crates/defguard_core)`
    ... which satisfies path dependency `defguard_core` (locked to 0.0.0) of package `defguard v0.0.0 (/tmp/renovate/repos/github/DefGuard/defguard-renovate/crates/defguard)`

failed to select a version for `base64urlsafedata` which could resolve this conflict

renovate Bot added dependencies renovate security labels Jul 16, 2026

renovate Bot added the security label Jul 16, 2026

renovate Bot force-pushed the renovate/stable/1.x-security-patches branch 2 times, most recently from f6c4c88 to a9c9003 Compare July 25, 2026 07:49

renovate Bot force-pushed the renovate/stable/1.x-security-patches branch 2 times, most recently from 96c2b2f to 83c866f Compare August 3, 2026 23:50

renovate Bot force-pushed the renovate/stable/1.x-security-patches branch 2 times, most recently from 6ef6c49 to 47ed3b9 Compare August 22, 2026 00:02

renovate Bot force-pushed the renovate/stable/1.x-security-patches branch 2 times, most recently from 2157a88 to 147b827 Compare September 3, 2026 01:55

renovate Bot force-pushed the renovate/stable/1.x-security-patches branch 2 times, most recently from 4fb2fb9 to c2f3d9a Compare September 11, 2026 00:01

renovate Bot force-pushed the renovate/stable/1.x-security-patches branch from c2f3d9a to d54ee0c Compare September 20, 2026 00:22

Update security patches [SECURITY]

6e5d2ea

renovate Bot force-pushed the renovate/stable/1.x-security-patches branch from d54ee0c to 6e5d2ea Compare October 3, 2026 12:08

Navigation Menu

Security patches (stable/1.x) - #449

Security patches (stable/1.x)#449
renovate[bot] wants to merge 1 commit into
stable/1.xfrom
renovate/stable/1.x-security-patches

renovate Bot commented Jul 16, 2026 •

edited

Loading

Uh oh!

renovate Bot commented Jul 16, 2026 •

edited

Loading

Uh oh!

Reviewers

Assignees

Labels

Projects

Milestone

Development

Uh oh!

0 participants

Conversation

renovate Bot commented Jul 16, 2026 • edited Loading Uh oh! There was an error while loading. Please reload this page.

Uh oh!

@​babel/core: Arbitrary File Read via sourceMappingURL Comment

Details

Impact

Patches

Workarounds

Credits

Severity

References

Ammonia: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Details

Impact

Patches

Workarounds

Severity

References

Ammonia: Improper Neutralization of Input During Web Page Generation ('Cross-site Scripting')

Details

Impact

Patches

Workarounds

Severity

References

XSS in ammonia via SVG animate and set animation tags

Details

Severity

References

Axios: HTTP/2 adapter bypasses configured DNS lookup and proxy controls

Details

Summary

Impact

Affected Functionality

Technical Details

Proof of Concept of Attack

Workarounds

Original report

Summary

Details

PoC

Impact

Severity

References

Axios: CIDR-form NO_PROXY entries are ignored, causing proxy exclusion bypass for internal IP ranges

Details

Summary

Impact

Affected Functionality

Technical Details

Proof of Concept of Attack

Workarounds

Original report

Summary

Details

PoC

Control

Impact

Severity

References

Axios: Fetch Adapter Header Injection via Inherited FormData getHeaders

Details

Summary

Impact

Affected Functionality

Technical Details

Proof of Concept of Attack

Workarounds

Original report

Summary

Affected Version

Preconditions

Root Cause

Impact

Proof of Concept

References

Severity

References

Axios: Denial of Service via Unhandled 'error' Event in HTTP/2 ClientHttp2Session Initialization

Details

renovate Bot commented Jul 16, 2026 •

edited

Loading

@babel/core: Arbitrary File Read via sourceMappingURL Comment

XSS in ammonia via SVG `animate` and `set` animation tags

renovate Bot commented Jul 16, 2026 •

edited

Loading