CWE-693
DiscouragedProtection Mechanism Failure
Abstraction: Pillar · Status: Draft
The product does not use or incorrectly uses a protection mechanism that provides sufficient defense against directed attacks against the product.
1336 vulnerabilities reference this CWE, most recent first.
GHSA-443J-8JP8-4XCH
Vulnerability from github – Published: 2022-12-22 21:30 – Updated: 2025-04-16 15:34Web-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.
{
"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:32Summary
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_PROXYentries 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
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
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);
}
POC_INTERNAL_HOST=127.0.0.1 node poc-no-proxy-cidr-axios.mjs
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.
POC_INTERNAL_HOST=127.0.0.1 POC_NO_PROXY=127.0.0.1 node poc-no-proxy-cidr-axios.mjs
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.
{
"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:30Protection mechanism failure in Windows UEFI allows an authorized attacker to bypass a security feature locally.
{
"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:31Policy 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)
{
"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:31Contrast, 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.
{
"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"
}
]
}
GHSA-45F5-XQ3V-73XQ
Vulnerability from github – Published: 2026-09-15 15:32 – Updated: 2026-09-22 18:33Mitigation bypass in the Widget: Win32 component. This vulnerability was fixed in Firefox 156 and Firefox ESR 153.3.
{
"affected": [],
"aliases": [
"CVE-2026-92079"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-09-15T13:17:03Z",
"severity": "CRITICAL"
},
"details": "Mitigation bypass in the Widget: Win32 component. This vulnerability was fixed in Firefox 156 and Firefox ESR 153.3.",
"id": "GHSA-45f5-xq3v-73xq",
"modified": "2026-09-22T18:33:15Z",
"published": "2026-09-15T15:32:11Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-92079"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=2067531"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-90"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-93"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-94"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2026-96"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-462W-V97R-4M45
Vulnerability from github – Published: 2019-04-10 14:30 – Updated: 2024-09-24 20:49In Pallets Jinja before 2.10.1, str.format_map allows a sandbox escape.
The sandbox is used to restrict what code can be evaluated when rendering untrusted, user-provided templates. Due to the way string formatting works in Python, the str.format_map method could be used to escape the sandbox.
This issue was previously addressed for the str.format method in Jinja 2.8.1, which discusses the issue in detail. However, the less-common str.format_map method was overlooked. This release applies the same sandboxing to both methods.
If you cannot upgrade Jinja, you can override the is_safe_attribute method on the sandbox and explicitly disallow the format_map method on string objects.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "Jinja2"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.10.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2019-10906"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2020-06-16T20:57:35Z",
"nvd_published_at": "2019-04-07T00:29:00Z",
"severity": "HIGH"
},
"details": "In Pallets Jinja before 2.10.1, `str.format_map` allows a sandbox escape.\n\nThe sandbox is used to restrict what code can be evaluated when rendering untrusted, user-provided templates. Due to the way string formatting works in Python, the `str.format_map` method could be used to escape the sandbox.\n\nThis issue was previously addressed for the `str.format` method in Jinja 2.8.1, which discusses the issue in detail. However, the less-common `str.format_map` method was overlooked. This release applies the same sandboxing to both methods.\n\nIf you cannot upgrade Jinja, you can override the `is_safe_attribute` method on the sandbox and explicitly disallow the `format_map` method on string objects.",
"id": "GHSA-462w-v97r-4m45",
"modified": "2024-09-24T20:49:55Z",
"published": "2019-04-10T14:30:24Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2019-10906"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4011-2"
},
{
"type": "WEB",
"url": "https://usn.ubuntu.com/4011-1"
},
{
"type": "WEB",
"url": "https://palletsprojects.com/blog/jinja-2-10-1-released"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/TS7IVZAJBWOHNRDMFJDIZVFCMRP6YIUQ"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QCDYIS254EJMBNWOG4S5QY6AOTOR4TZU"
},
{
"type": "WEB",
"url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/DSW3QZMFVVR7YE3UT4YRQA272TYAL5AF"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/f0c4a03418bcfe70c539c5dbaf99c04c98da13bfa1d3266f08564316@%3Ccommits.airflow.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/b2380d147b508bbcb90d2cad443c159e63e12555966ab4f320ee22da@%3Ccommits.airflow.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/7f39f01392d320dfb48e4901db68daeece62fd60ef20955966739993@%3Ccommits.airflow.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/57673a78c4d5c870d3f21465c7e2946b9f8285c7c57e54c2ae552f02@%3Ccommits.airflow.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/46c055e173b52d599c648a98199972dbd6a89d2b4c4647b0500f2284@%3Cdevnull.infra.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/320441dccbd9a545320f5f07306d711d4bbd31ba43dc9eebcfc602df@%3Cdevnull.infra.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/2b52b9c8b9d6366a4f1b407a8bde6af28d9fc73fdb3b37695fd0d9ac@%3Cdevnull.infra.apache.org%3E"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread.html/09fc842ff444cd43d9d4c510756fec625ef8eb1175f14fd21de2605f@%3Cdevnull.infra.apache.org%3E"
},
{
"type": "WEB",
"url": "https://github.com/pypa/advisory-database/tree/main/vulns/jinja2/PYSEC-2019-217.yaml"
},
{
"type": "PACKAGE",
"url": "https://github.com/pallets/jinja"
},
{
"type": "ADVISORY",
"url": "https://github.com/advisories/GHSA-462w-v97r-4m45"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:1329"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:1237"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2019:1152"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-05/msg00030.html"
},
{
"type": "WEB",
"url": "http://lists.opensuse.org/opensuse-security-announce/2019-06/msg00064.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Jinja2 sandbox escape via string formatting"
}
GHSA-46G3-37RH-V698
Vulnerability from github – Published: 2026-03-17 18:38 – Updated: 2026-03-20 21:21Summary
A vulnerability exists in the Community Tier of Harden-Runner that allows bypassing the egress-policy: block network restriction using DNS over HTTPS (DoH).
Harden-Runner secures GitHub Actions workflows on runners by applying network policies, including an allowed-endpoints configuration that limits outbound traffic to specified domains and ports (e.g., github.com:443). In egress-policy: block mode, non-compliant connections are intercepted and denied.
This vulnerability exploits DoH, a protocol that encapsulates DNS queries within HTTPS requests. By crafting a DNS query that embeds exfiltrated data as a subdomain (e.g., encoding the runner's hostname into a label), an attacker can route the request through a permitted HTTPS endpoint like dns.google (8.8.8.8's DoH service). The resolver processes the query and forwards it to the attacker's controlled domain, achieving exfiltration without directly accessing the blocked destination. This evades Harden-Runner's domain-based filtering, as the initial HTTPS connection appears legitimate.
This vulnerability requires the attacker to already have code execution capabilities within the GitHub Actions workflow.
The Enterprise Tier of Harden-Runner is not affected by this vulnerability.
Impact
When Harden-Runner is configured with egress-policy: block and a restrictive allowed-endpoints list, an attacker with existing code execution capabilities within a GitHub Actions workflow can bypass the allowed domains check via DNS over HTTPS by proxying DNS queries through a permitted resolver (e.g., Google's DoH service). This allows data exfiltration even when allowed-endpoints is set to only whitelisted domains.
This vulnerability affects only the Community Tier. It requires the attacker to already have code execution capabilities within the GitHub Actions workflow.
Remediation
For Community Tier Users
Upgrade to Harden-Runner v2.16.0 or later.
For Enterprise Tier Users
No action required. Enterprise tier customers are not affected by this vulnerability.
Credit
We would like to thank Devansh Batham for responsibly disclosing this vulnerability through our security reporting process.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.15.1"
},
"package": {
"ecosystem": "GitHub Actions",
"name": "step-security/harden-runner"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.16.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-32947"
],
"database_specific": {
"cwe_ids": [
"CWE-693",
"CWE-863"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-17T18:38:16Z",
"nvd_published_at": "2026-03-20T05:16:13Z",
"severity": "MODERATE"
},
"details": "## Summary\n\nA vulnerability exists in the Community Tier of Harden-Runner that allows bypassing the `egress-policy: block` network restriction using DNS over HTTPS (DoH).\n\nHarden-Runner secures GitHub Actions workflows on runners by applying network policies, including an `allowed-endpoints` configuration that limits outbound traffic to specified domains and ports (e.g., `github.com:443`). In `egress-policy: block` mode, non-compliant connections are intercepted and denied. \n\nThis vulnerability exploits DoH, a protocol that encapsulates DNS queries within HTTPS requests. By crafting a DNS query that embeds exfiltrated data as a subdomain (e.g., encoding the runner\u0027s hostname into a label), an attacker can route the request through a permitted HTTPS endpoint like `dns.google` (`8.8.8.8`\u0027s DoH service). The resolver processes the query and forwards it to the attacker\u0027s controlled domain, achieving exfiltration without directly accessing the blocked destination. This evades Harden-Runner\u0027s domain-based filtering, as the initial HTTPS connection appears legitimate. \n\nThis vulnerability requires the attacker to already have code execution capabilities within the GitHub Actions workflow.\n\nThe Enterprise Tier of Harden-Runner is **not affected** by this vulnerability.\n\n## Impact\n\nWhen Harden-Runner is configured with `egress-policy: block` and a restrictive `allowed-endpoints` list, an attacker with existing code execution capabilities within a GitHub Actions workflow can bypass the allowed domains check via DNS over HTTPS by proxying DNS queries through a permitted resolver (e.g., Google\u0027s DoH service). This allows data exfiltration even when `allowed-endpoints` is set to only whitelisted domains.\n\nThis vulnerability affects only the Community Tier. It requires the attacker to already have code execution capabilities within the GitHub Actions workflow.\n\n## Remediation\n\n### For Community Tier Users\n\nUpgrade to Harden-Runner v2.16.0 or later. \n\n### For Enterprise Tier Users\n\nNo action required. Enterprise tier customers are not affected by this vulnerability.\n\n## Credit \n\nWe would like to thank [Devansh Batham](https://github.com/devanshbatham) for responsibly disclosing this vulnerability through our security reporting process.",
"id": "GHSA-46g3-37rh-v698",
"modified": "2026-03-20T21:21:35Z",
"published": "2026-03-17T18:38:16Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/step-security/harden-runner/security/advisories/GHSA-46g3-37rh-v698"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-32947"
},
{
"type": "PACKAGE",
"url": "https://github.com/step-security/harden-runner"
},
{
"type": "WEB",
"url": "https://github.com/step-security/harden-runner/releases/tag/v2.16.0"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "Egress Policy Bypass via DNS over HTTPS (DoH) in Harden-Runner (Community Tier)"
}
GHSA-46J3-CWJR-4R6Q
Vulnerability from github – Published: 2026-08-11 18:30 – Updated: 2026-09-18 15:31Protection mechanism failure for some Intel(R) Transfer Learning Tool before version v0.7 within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with an unauthenticated user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via network access when attack requirements are present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (low), integrity (low) and availability (low) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.
{
"affected": [],
"aliases": [
"CVE-2026-39452"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-08-11T17:17:58Z",
"severity": "MODERATE"
},
"details": "Protection mechanism failure for some Intel(R) Transfer Learning Tool before version v0.7 within Ring 3: User Applications may allow an escalation of privilege. Unprivileged software adversary with an unauthenticated user combined with a low complexity attack may enable escalation of privilege. This result may potentially occur via network access when attack requirements are present without special internal knowledge and requires no user interaction. The potential vulnerability may impact the confidentiality (low), integrity (low) and availability (low) of the vulnerable system, resulting in subsequent system confidentiality (none), integrity (none) and availability (none) impacts.",
"id": "GHSA-46j3-cwjr-4r6q",
"modified": "2026-09-18T15:31:42Z",
"published": "2026-08-11T18:30:55Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39452"
},
{
"type": "WEB",
"url": "https://intel.com/content/www/us/en/security-center/advisory/intel-sa-01499.html"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:L/VA:L/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"
}
]
}
GHSA-46J6-8982-6XCV
Vulnerability from github – Published: 2024-07-09 18:30 – Updated: 2024-07-09 18:30BitLocker Security Feature Bypass Vulnerability
{
"affected": [],
"aliases": [
"CVE-2024-38058"
],
"database_specific": {
"cwe_ids": [
"CWE-693"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2024-07-09T17:15:36Z",
"severity": "MODERATE"
},
"details": "BitLocker Security Feature Bypass Vulnerability",
"id": "GHSA-46j6-8982-6xcv",
"modified": "2024-07-09T18:30:52Z",
"published": "2024-07-09T18:30:51Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2024-38058"
},
{
"type": "WEB",
"url": "https://msrc.microsoft.com/update-guide/vulnerability/CVE-2024-38058"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:P/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
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.