Common Weakness Enumeration

CWE-693

Discouraged

Protection Mechanism Failure

Abstraction: Pillar · Status: Draft

API response cwe.mitre.org

The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.

1393 vulnerabilities reference this CWE, most recent first.

GHSA-3V4J-G349-F7FR

Vulnerability from github – Published: 2025-09-04 21:31 – Updated: 2025-09-05 21:32
VLAI
Details

In executeAppFunction of AppSearchManagerService.java, there is a possible background activity launch due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-26464"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-09-04T19:15:35Z",
    "severity": "HIGH"
  },
  "details": "In executeAppFunction of AppSearchManagerService.java, there is a possible background activity launch due to a logic error in the code. This could lead to local escalation of privilege with no additional execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-3v4j-g349-f7fr",
  "modified": "2025-09-05T21:32:36Z",
  "published": "2025-09-04T21:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-26464"
    },
    {
      "type": "WEB",
      "url": "https://android.googlesource.com/platform/packages/modules/AppSearch/+/e272ad00529243f766c6ebd4e976549bd4fff4fb"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/security/bulletin/2025-09-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3VVW-RVGW-FJMH

Vulnerability from github – Published: 2024-04-09 18:30 – Updated: 2024-04-09 18:30
VLAI
Details

Secure Boot Security Feature Bypass Vulnerability

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2024-28920"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-09T17:15:51Z",
    "severity": "HIGH"
  },
  "details": "Secure Boot Security Feature Bypass Vulnerability",
  "id": "GHSA-3vvw-rvgw-fjmh",
  "modified": "2024-04-09T18:30:27Z",
  "published": "2024-04-09T18:30:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-28920"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-28920"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3W97-CPQW-J625

Vulnerability from github – Published: 2026-09-15 21:31 – Updated: 2026-09-16 15:30
VLAI
Details

In Bootloader, there is a possible permission bypass due to a logic error in the code. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-58678"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-15T19:17:31Z",
    "severity": "HIGH"
  },
  "details": "In Bootloader, there is a possible permission bypass due to a logic error in the code. This could lead to local escalation of privilege with System execution privileges needed. User interaction is not needed for exploitation.",
  "id": "GHSA-3w97-cpqw-j625",
  "modified": "2026-09-16T15:30:56Z",
  "published": "2026-09-15T21:31:18Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-58678"
    },
    {
      "type": "WEB",
      "url": "https://source.android.com/docs/security/bulletin/pixel/2026/2026-09-01"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-3WP7-VQR4-G72H

Vulnerability from github – Published: 2022-04-22 00:24 – Updated: 2024-04-03 23:04
VLAI
Details

The Ubuntu SELinux initscript before version 1:0.10 used touch to create a lockfile in a world-writable directory. If the OS kernel does not have symlink protections then an attacker can cause a zero byte file to be allocated on any writable filesystem.

Severity
5.9 (Medium)
CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2011-3151"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-04-22T16:29:00Z",
    "severity": "MODERATE"
  },
  "details": "The Ubuntu SELinux initscript before version 1:0.10 used touch to create a lockfile in a world-writable directory. If the OS kernel does not have symlink protections then an attacker can cause a zero byte file to be allocated on any writable filesystem.",
  "id": "GHSA-3wp7-vqr4-g72h",
  "modified": "2024-04-03T23:04:32Z",
  "published": "2022-04-22T00:24:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2011-3151"
    },
    {
      "type": "WEB",
      "url": "https://launchpadlibrarian.net/88098106/selinux_0.10~10.04.1.debdiff"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-43X4-G22P-3HRQ

Vulnerability from github – Published: 2026-03-03 18:10 – Updated: 2026-03-30 13:35
VLAI
Summary
OpenClaw: Chrome --no-sandbox disabled OS-level browser sandbox in sandbox browser container
Details

Summary

Sandbox browser container launched Chromium with --no-sandbox by default, disabling Chromium's OS-level sandbox protections.

Affected Packages / Versions

  • Package: openclaw (npm ecosystem)
  • Latest published npm version at triage time (2026-02-21): 2026.2.19-2
  • Affected range: <= 2026.2.19-2
  • Planned patched version for next release: 2026.2.21

Impact

When --no-sandbox is enabled by default, renderer compromise no longer requires a separate sandbox escape. This weakens container browser isolation and increases impact from renderer-side bugs.

Resolution

  • Default --no-sandbox removed from sandbox browser entrypoint.
  • Explicit opt-in added via OPENCLAW_BROWSER_NO_SANDBOX / CLAWDBOT_BROWSER_NO_SANDBOX.
  • Browser container hash migration + security audit checks added so stale containers are surfaced and can be recreated safely.

Fix Commit(s)

  • e7eba01efc4c3c400e9cfd3ce3d661cbc788a631
  • 1835dec2004fe7a62c6a7ba46b8485f124ec6199

Release Process Note

The advisory patched_versions field is pre-set to the planned next release (2026.2.21). After npm release publication, only advisory publish action should remain.

OpenClaw thanks @TerminalsandCoffee for reporting.

Severity
4.8 (Medium)
CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.2.21"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-32046"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-03T18:10:34Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\nSandbox browser container launched Chromium with `--no-sandbox` by default, disabling Chromium\u0027s OS-level sandbox protections.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm ecosystem)\n- Latest published npm version at triage time (2026-02-21): `2026.2.19-2`\n- Affected range: `\u003c= 2026.2.19-2`\n- Planned patched version for next release: `2026.2.21`\n\n## Impact\nWhen `--no-sandbox` is enabled by default, renderer compromise no longer requires a separate sandbox escape. This weakens container browser isolation and increases impact from renderer-side bugs.\n\n## Resolution\n- Default `--no-sandbox` removed from sandbox browser entrypoint.\n- Explicit opt-in added via `OPENCLAW_BROWSER_NO_SANDBOX` / `CLAWDBOT_BROWSER_NO_SANDBOX`.\n- Browser container hash migration + security audit checks added so stale containers are surfaced and can be recreated safely.\n\n## Fix Commit(s)\n- e7eba01efc4c3c400e9cfd3ce3d661cbc788a631\n- 1835dec2004fe7a62c6a7ba46b8485f124ec6199\n\n## Release Process Note\nThe advisory `patched_versions` field is pre-set to the planned next release (`2026.2.21`). After npm release publication, only advisory publish action should remain.\n\nOpenClaw thanks @TerminalsandCoffee for reporting.",
  "id": "GHSA-43x4-g22p-3hrq",
  "modified": "2026-03-30T13:35:13Z",
  "published": "2026-03-03T18:10:34Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-43x4-g22p-3hrq"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32046"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/1835dec2004fe7a62c6a7ba46b8485f124ec6199"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/e7eba01efc4c3c400e9cfd3ce3d661cbc788a631"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-os-level-sandbox-bypass-via-no-sandbox-flag"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:L/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Chrome --no-sandbox disabled OS-level browser sandbox in sandbox browser container"
}

GHSA-443J-8JP8-4XCH

Vulnerability from github – Published: 2022-12-22 21:30 – Updated: 2025-04-16 15:34
VLAI
Details

Web-accessible extension pages (pages with a moz-extension:// scheme) were not correctly enforcing the frame-ancestors directive when it was used in the Web Extension's Content Security Policy. This vulnerability affects Firefox < 97, Thunderbird < 91.6, and Firefox ESR < 91.6.

Severity
8.8 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2022-22761"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-12-22T20:15:00Z",
    "severity": "HIGH"
  },
  "details": "Web-accessible extension pages (pages with a moz-extension:// scheme) were not correctly enforcing the frame-ancestors directive when it was used in the Web Extension\u0027s Content Security Policy. This vulnerability affects Firefox \u003c 97, Thunderbird \u003c 91.6, and Firefox ESR \u003c 91.6.",
  "id": "GHSA-443j-8jp8-4xch",
  "modified": "2025-04-16T15:34:06Z",
  "published": "2022-12-22T21:30:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-22761"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1745566"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2022-04"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2022-05"
    },
    {
      "type": "WEB",
      "url": "https://www.mozilla.org/security/advisories/mfsa2022-06"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-44G4-M2MJ-WPVX

Vulnerability from github – Published: 2026-09-30 15:32 – Updated: 2026-09-30 15:32
VLAI
Summary
Axios: CIDR-form NO_PROXY entries are ignored, causing proxy exclusion bypass for internal IP ranges
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:

  1. Set HTTP_PROXY=http://127.0.0.1:<proxy-port>.
  2. Set NO_PROXY=127.0.0.0/8.
  3. Request http://127.0.0.1:<internal-port>/metadata.
  4. 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
6.9 (Medium)
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
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "axios"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "1.15.0"
            },
            {
              "fixed": "1.20.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-101899"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-09-30T15:32:30Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nAxios 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.\n\nThis affects deployments that rely on CIDR notation to keep loopback, private, Kubernetes, CI, or cloud metadata traffic away from proxy infrastructure.\n\n## Impact\n\nIf 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.\n\nThis is a proxy exclusion bypass, not arbitrary proxy injection by itself.\n\n## Affected Functionality\n\nAffected:\n\n- Node.js adapter proxy environment handling.\n- `HTTP_PROXY`, `HTTPS_PROXY`, `NO_PROXY`, or lowercase equivalents.\n- CIDR entries in `NO_PROXY`.\n\nNot affected:\n\n- Exact host or exact IP `NO_PROXY` entries where axios matching succeeds.\n- Requests configured with `proxy: false`.\n- Browser adapters.\n\n## Technical Details\n\n`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.\n\nLocal verification on axios `1.18.1`:\n\n```js\nprocess.env.NO_PROXY = \u0027127.0.0.0/8\u0027;\nshouldBypassProxy(\u0027http://127.0.0.1:1234/\u0027); // false\n```\n\nThe expected result for CIDR-aware bypass policy is `true`.\n\n## Proof of Concept of Attack\n\nConstrained local demonstration:\n\n1. Set `HTTP_PROXY=http://127.0.0.1:\u003cproxy-port\u003e`.\n2. Set `NO_PROXY=127.0.0.0/8`.\n3. Request `http://127.0.0.1:\u003cinternal-port\u003e/metadata`.\n4. Observe that axios sends the request through the proxy instead of directly to the internal listener.\n\n## Workarounds\n\nUse 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`.\n\n\u003cdetails\u003e\n  \u003csummary\u003e\u003ch3\u003eOriginal report\u003c/h3\u003e\u003c/summary\u003e\n  \n## Summary\n\nAxios 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.\n\nIn the attached PoC, a request to `127.0.0.1` is sent through `HTTP_PROXY` despite `NO_PROXY=127.0.0.0/8`.\n\nThis 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.\n\n## Details\n\nAxios supports proxy environment variables, including `HTTP_PROXY` / `HTTPS_PROXY` and `NO_PROXY`-style exclusions. Axios\u2019s 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\n\nThe issue is that CIDR-form `NO_PROXY` entries are not interpreted as network ranges. For example:\n\n```text\nNO_PROXY=127.0.0.0/8\nHTTP_PROXY=http://127.0.0.1:\u003cproxy-port\u003e\nTarget URL=http://127.0.0.1:\u003cinternal-port\u003e/metadata\n```\n\nSince `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`.\n\nThis appears to affect the proxy bypass decision path used for `NO_PROXY` / `no_proxy` handling. The relevant behavior is in Axios\u0027s Node proxy handling and `NO_PROXY` evaluation logic, including the `shouldBypassProxy` helper introduced for `no_proxy` hostname normalization and bypass checks.\n\nThe 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.\n\nThis is security-relevant because CIDR notation is commonly used in container, CI, enterprise proxy, and cloud environments for ranges such as:\n\n```text\n127.0.0.0/8\n10.0.0.0/8\n172.16.0.0/12\n192.168.0.0/16\n169.254.169.254/32\n```\n\nIf operators rely on those entries to prevent internal or metadata-style requests from traversing a proxy, Axios may violate that expectation.\n\n## PoC\n\n```js\nimport http from \u0027http\u0027;\nimport axios from \u0027axios\u0027;\n\nfunction listen(server, host) {\n  return new Promise((resolve, reject) =\u003e {\n    server.once(\u0027error\u0027, reject);\n    server.listen(0, host, () =\u003e resolve(server.address().port));\n  });\n}\n\nfunction close(server) {\n  return new Promise((resolve) =\u003e server.close(resolve));\n}\n\nlet proxyHits = 0;\nlet internalHits = 0;\n\nconst internal = http.createServer((req, res) =\u003e {\n  internalHits += 1;\n  res.writeHead(200, { \u0027content-type\u0027: \u0027text/plain\u0027 });\n  res.end(`internal service saw ${req.url}`);\n});\n\nconst proxy = http.createServer((req, res) =\u003e {\n  proxyHits += 1;\n  res.writeHead(200, { \u0027content-type\u0027: \u0027text/plain\u0027 });\n  res.end(`proxy saw request for ${req.url}`);\n});\n\nconst internalHost = process.env.POC_INTERNAL_HOST || \u0027127.0.0.2\u0027;\nconst proxyHost = process.env.POC_PROXY_HOST || \u0027127.0.0.1\u0027;\n\nlet internalPort;\nlet proxyPort;\n\ntry {\n  internalPort = await listen(internal, internalHost);\n  proxyPort = await listen(proxy, proxyHost);\n} catch (error) {\n  console.error(\u0027Failed to bind local PoC servers.\u0027);\n  console.error(\u0027On some systems 127.0.0.2 is unavailable; try:\u0027);\n  console.error(\u0027  POC_INTERNAL_HOST=127.0.0.1 node poc-no-proxy-cidr-axios.mjs\u0027);\n  console.error(\u0027\u0027);\n  throw error;\n}\n\nconst targetUrl = `http://${internalHost}:${internalPort}/metadata`;\nconst proxyUrl = `http://${proxyHost}:${proxyPort}`;\nconst noProxy = process.env.POC_NO_PROXY || \u0027127.0.0.0/8\u0027;\n\nprocess.env.http_proxy = proxyUrl;\nprocess.env.HTTP_PROXY = proxyUrl;\nprocess.env.no_proxy = noProxy;\nprocess.env.NO_PROXY = noProxy;\n\nconsole.log(\u0027Axios NO_PROXY CIDR full axios network PoC\u0027);\nconsole.log(`axios VERSION=${axios.VERSION || \u0027unknown\u0027}`);\nconsole.log(`NO_PROXY=${process.env.no_proxy}`);\nconsole.log(`HTTP_PROXY=${process.env.http_proxy}`);\nconsole.log(`Target URL=${targetUrl}`);\nconsole.log(\u0027\u0027);\n\ntry {\n  const response = await axios.get(targetUrl, {\n    timeout: 2000,\n  });\n\n  console.log(`Response=${response.data}`);\n  console.log(`Proxy hits=${proxyHits}`);\n  console.log(`Internal direct hits=${internalHits}`);\n  console.log(\u0027\u0027);\n\n  if (proxyHits \u003e 0 \u0026\u0026 internalHits === 0) {\n    console.log(`POC RESULT: axios sent the target through the proxy with NO_PROXY=${noProxy}.`);\n  } else if (proxyHits === 0 \u0026\u0026 internalHits \u003e 0) {\n    console.log(`POC RESULT: axios bypassed the proxy with NO_PROXY=${noProxy}.`);\n  } else {\n    console.log(\u0027POC RESULT: mixed/ambiguous routing; inspect counts above.\u0027);\n  }\n} finally {\n  delete process.env.http_proxy;\n  delete process.env.HTTP_PROXY;\n  delete process.env.no_proxy;\n  delete process.env.NO_PROXY;\n  await close(proxy);\n  await close(internal);\n}\n```\n\nRun the failing CIDR case:\n\n```bash\nPOC_INTERNAL_HOST=127.0.0.1 node poc-no-proxy-cidr-axios.mjs\n```\n\nObserved:\n\n```text\nAxios NO_PROXY CIDR full axios network PoC\naxios VERSION=1.17.0\nNO_PROXY=127.0.0.0/8\nHTTP_PROXY=http://127.0.0.1:34315\nTarget URL=http://127.0.0.1:43993/metadata\n\nResponse=proxy saw request for http://127.0.0.1:43993/metadata\nProxy hits=1\nInternal direct hits=0\n\nPOC RESULT: axios sent the target through the proxy with NO_PROXY=127.0.0.0/8.\n```\n\n## Control\n\nAxios does honor exact IP `NO_PROXY` entries:\n\n```bash\nPOC_INTERNAL_HOST=127.0.0.1 POC_NO_PROXY=127.0.0.1 node poc-no-proxy-cidr-axios.mjs\n```\n\nExpected:\n\n```text\nNO_PROXY=127.0.0.1\nResponse=internal service saw /metadata\nProxy hits=0\nInternal direct hits=1\n\nPOC RESULT: axios bypassed the proxy with NO_PROXY=127.0.0.1.\n```\n\nThis 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`.\n\n## Impact\n\nThis is a proxy exclusion bypass caused by unsupported CIDR matching in `NO_PROXY`.\n\nThe 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.\n\nPotentially impacted environments include:\n\n- CI/CD runners with globally injected `HTTP_PROXY` / `HTTPS_PROXY`.\n- Containers inheriting proxy variables from the host or orchestrator.\n- Kubernetes workloads using `NO_PROXY` for cluster-internal service ranges.\n- Enterprise networks using HTTP proxies with internal network exclusions.\n- Cloud workloads relying on `NO_PROXY` to keep metadata or internal service requests off proxy infrastructure.\n\nIf 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.\n\nThis 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.\n\u003c/details\u003e\n\n---",
  "id": "GHSA-44g4-m2mj-wpvx",
  "modified": "2026-09-30T15:32:30Z",
  "published": "2026-09-30T15:32:30Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/axios/axios/security/advisories/GHSA-44g4-m2mj-wpvx"
    },
    {
      "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"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "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",
      "type": "CVSS_V4"
    }
  ],
  "summary": "Axios: CIDR-form NO_PROXY entries are ignored, causing proxy exclusion bypass for internal IP ranges"
}

GHSA-44JF-FMCV-XP6F

Vulnerability from github – Published: 2026-06-09 18:30 – Updated: 2026-06-09 18:30
VLAI
Details

Protection mechanism failure in Windows UEFI allows an authorized attacker to bypass a security feature locally.

Severity
7.8 (High)
CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-45656"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-09T17:17:32Z",
    "severity": "HIGH"
  },
  "details": "Protection mechanism failure in Windows UEFI allows an authorized attacker to bypass a security feature locally.",
  "id": "GHSA-44jf-fmcv-xp6f",
  "modified": "2026-06-09T18:30:54Z",
  "published": "2026-06-09T18:30:54Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-45656"
    },
    {
      "type": "WEB",
      "url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45656"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4567-QCR7-FJV3

Vulnerability from github – Published: 2026-07-30 03:31 – Updated: 2026-07-30 21:31
VLAI
Details

Policy bypass in Enterprise in Google Chrome prior to 151.0.7922.72 allowed a remote attacker to bypass navigation restrictions via a crafted domain name. (Chromium security severity: Low)

Severity
6.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2026-17923"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-30T01:16:56Z",
    "severity": "MODERATE"
  },
  "details": "Policy bypass in Enterprise in Google Chrome prior to 151.0.7922.72 allowed a remote attacker to bypass navigation restrictions via a crafted domain name. (Chromium security severity: Low)",
  "id": "GHSA-4567-qcr7-fjv3",
  "modified": "2026-07-30T21:31:41Z",
  "published": "2026-07-30T03:31:17Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-17923"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2026/07/stable-channel-update-for-desktop_0887107924.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/513612928"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-4585-2273-G8CW

Vulnerability from github – Published: 2026-09-27 03:31 – Updated: 2026-09-27 03:31
VLAI
Details

Contrast, Edgeless Systems' runtime for confidential containers on Kubernetes, is affected in versions up to and including 1.9.0. The VOLUME directive in a Dockerfile (config.volumes in the OCI image configuration) is only a hint and is not handled specially by Kubernetes, but containerd adds a mount point for it when Kubernetes sets none, requiring the runtime to be able to push arbitrary data to the Kata agent. As a result, on bare-metal Contrast deployments (AKS deployments are not affected) that run an image declaring at least one VOLUME for which no Kubernetes mount exists at that path, the untrusted host can write arbitrary file trees below that mount point inside the confidential container, compromising the integrity of a directory that is typically important to the application's core functionality. Version 1.9.1 fixes the issue by disallowing this configuration in contrast generate.

Severity
3.5 (Low)
CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N
5.1 (Medium)
CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2025-71424"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-693"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-27T02:17:16Z",
    "severity": "MODERATE"
  },
  "details": "Contrast, Edgeless Systems\u0027 runtime for confidential containers on Kubernetes, is affected in versions up to and including 1.9.0. The VOLUME directive in a Dockerfile (config.volumes in the OCI image configuration) is only a hint and is not handled specially by Kubernetes, but containerd adds a mount point for it when Kubernetes sets none, requiring the runtime to be able to push arbitrary data to the Kata agent. As a result, on bare-metal Contrast deployments (AKS deployments are not affected) that run an image declaring at least one VOLUME for which no Kubernetes mount exists at that path, the untrusted host can write arbitrary file trees below that mount point inside the confidential container, compromising the integrity of a directory that is typically important to the application\u0027s core functionality. Version 1.9.1 fixes the issue by disallowing this configuration in `contrast generate`.",
  "id": "GHSA-4585-2273-g8cw",
  "modified": "2026-09-27T03:31:03Z",
  "published": "2026-09-27T03:31:03Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/edgelesssys/contrast/security/advisories/GHSA-phhq-63jg-fp7r"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-71424"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/edgeless-systems-contrast-before-1.9.1-insecure-volume-mount"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:L/PR:L/UI:N/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:A/AC:L/AT:N/PR:L/UI:N/VC:N/VI:L/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

No mitigation information available for this CWE.

CAPEC-1: Accessing Functionality Not Properly Constrained by ACLs

In applications, particularly web applications, access to functionality is mitigated by an authorization framework. This framework maps Access Control Lists (ACLs) to elements of the application's functionality; particularly URL's for web apps. In the case that the administrator failed to specify an ACL for a particular element, an attacker may be able to access it with impunity. An attacker with the ability to access functionality not properly constrained by ACLs can obtain sensitive information and possibly compromise the entire application. Such an attacker can access resources that must be available only to users at a higher privilege level, can access management sections of the application, or can run queries for data that they otherwise not supposed to.

CAPEC-107: Cross Site Tracing

Cross Site Tracing (XST) enables an adversary to steal the victim's session cookie and possibly other authentication credentials transmitted in the header of the HTTP request when the victim's browser communicates to a destination system's web server.

CAPEC-127: Directory Indexing

An adversary crafts a request to a target that results in the target listing/indexing the content of a directory as output. One common method of triggering directory contents as output is to construct a request containing a path that terminates in a directory name rather than a file name since many applications are configured to provide a list of the directory's contents when such a request is received. An adversary can use this to explore the directory tree on a target as well as learn the names of files. This can often end up revealing test files, backup files, temporary files, hidden files, configuration files, user accounts, script contents, as well as naming conventions, all of which can be used by an attacker to mount additional attacks.

CAPEC-17: Using Malicious Files

An attack of this type exploits a system's configuration that allows an adversary to either directly access an executable file, for example through shell access; or in a possible worst case allows an adversary to upload a file and then execute it. Web servers, ftp servers, and message oriented middleware systems which have many integration points are particularly vulnerable, because both the programmers and the administrators must be in synch regarding the interfaces and the correct privileges for each interface.

CAPEC-20: Encryption Brute Forcing

An attacker, armed with the cipher text and the encryption algorithm used, performs an exhaustive (brute force) search on the key space to determine the key that decrypts the cipher text to obtain the plaintext.

CAPEC-22: Exploiting Trust in Client

An attack of this type exploits vulnerabilities in client/server communication channel authentication and data integrity. It leverages the implicit trust a server places in the client, or more importantly, that which the server believes is the client. An attacker executes this type of attack by communicating directly with the server where the server believes it is communicating only with a valid client. There are numerous variations of this type of attack.

CAPEC-237: Escaping a Sandbox by Calling Code in Another Language

The attacker may submit malicious code of another language to obtain access to privileges that were not intentionally exposed by the sandbox, thus escaping the sandbox. For instance, Java code cannot perform unsafe operations, such as modifying arbitrary memory locations, due to restrictions placed on it by the Byte code Verifier and the JVM. If allowed, Java code can call directly into native C code, which may perform unsafe operations, such as call system calls and modify arbitrary memory locations on their behalf. To provide isolation, Java does not grant untrusted code with unmediated access to native C code. Instead, the sandboxed code is typically allowed to call some subset of the pre-existing native code that is part of standard libraries.

CAPEC-36: Using Unpublished Interfaces or Functionality

An adversary searches for and invokes interfaces or functionality that the target system designers did not intend to be publicly available. If interfaces fail to authenticate requests, the attacker may be able to invoke functionality they are not authorized for.

CAPEC-477: Signature Spoofing by Mixing Signed and Unsigned Content

An attacker exploits the underlying complexity of a data structure that allows for both signed and unsigned content, to cause unsigned data to be processed as though it were signed data.

CAPEC-480: Escaping Virtualization

An adversary gains access to an application, service, or device with the privileges of an authorized or privileged user by escaping the confines of a virtualized environment. The adversary is then able to access resources or execute unauthorized code within the host environment, generally with the privileges of the user running the virtualized process. Successfully executing an attack of this type is often the first step in executing more complex attacks.

CAPEC-51: Poison Web Service Registry

SOA and Web Services often use a registry to perform look up, get schema information, and metadata about services. A poisoned registry can redirect (think phishing for servers) the service requester to a malicious service provider, provide incorrect information in schema or metadata, and delete information about service provider interfaces.

CAPEC-57: Utilizing REST's Trust in the System Resource to Obtain Sensitive Data

This attack utilizes a REST(REpresentational State Transfer)-style applications' trust in the system resources and environment to obtain sensitive data once SSL is terminated.

CAPEC-59: Session Credential Falsification through Prediction

This attack targets predictable session ID in order to gain privileges. The attacker can predict the session ID used during a transaction to perform spoofing and session hijacking.

CAPEC-65: Sniff Application Code

An adversary passively sniffs network communications and captures application code bound for an authorized client. Once obtained, they can use it as-is, or through reverse-engineering glean sensitive information or exploit the trust relationship between the client and server. Such code may belong to a dynamic update to the client, a patch being applied to a client component or any such interaction where the client is authorized to communicate with the server.

CAPEC-668: Key Negotiation of Bluetooth Attack (KNOB)

An adversary can exploit a flaw in Bluetooth key negotiation allowing them to decrypt information sent between two devices communicating via Bluetooth. The adversary uses an Adversary in the Middle setup to modify packets sent between the two devices during the authentication process, specifically the entropy bits. Knowledge of the number of entropy bits will allow the attacker to easily decrypt information passing over the line of communication.

CAPEC-74: Manipulating State

The adversary modifies state information maintained by the target software or causes a state transition in hardware. If successful, the target will use this tainted state and execute in an unintended manner.

State management is an important function within a software application. User state maintained by the application can include usernames, payment information, browsing history as well as application-specific contents such as items in a shopping cart. Manipulating user state can be employed by an adversary to elevate privilege, conduct fraudulent transactions or otherwise modify the flow of the application to derive certain benefits.

If there is a hardware logic error in a finite state machine, the adversary can use this to put the system in an undefined state which could cause a denial of service or exposure of secure data.

CAPEC-87: Forceful Browsing

An attacker employs forceful browsing (direct URL entry) to access portions of a website that are otherwise unreachable. Usually, a front controller or similar design pattern is employed to protect access to portions of a web application. Forceful browsing enables an attacker to access information, perform privileged operations and otherwise reach sections of the web application that have been improperly protected.

← Back to the CWE list