CWE-201
AllowedInsertion of Sensitive Information Into Sent Data
Abstraction: Base · Status: Draft
The code transmits data to another actor, but a portion of the data includes sensitive information that should not be accessible to that actor.
673 vulnerabilities reference this CWE, most recent first.
GHSA-VW2M-PPWV-6G52
Vulnerability from github – Published: 2026-01-26 18:31 – Updated: 2026-01-28 21:31Shenzhen Tenda W30E V2 firmware versions up to and including V16.01.0.19(5037) disclose sensitive account credentials in cleartext within HTTP responses generated by the maintenance interface. Because the management interface is accessible over unencrypted HTTP by default, credentials may be exposed to network-based interception.
{
"affected": [],
"aliases": [
"CVE-2026-24430"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-01-26T18:16:40Z",
"severity": "HIGH"
},
"details": "Shenzhen Tenda W30E V2 firmware versions up to and including V16.01.0.19(5037) disclose sensitive account credentials in cleartext within HTTP responses generated by the maintenance interface. Because the management interface is accessible over unencrypted HTTP by default, credentials may be exposed to network-based interception.",
"id": "GHSA-vw2m-ppwv-6g52",
"modified": "2026-01-28T21:31:19Z",
"published": "2026-01-26T18:31:31Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-24430"
},
{
"type": "WEB",
"url": "https://www.tendacn.com/product/W30E"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/tenda-w30e-v2-http-responses-expose-plaintext-credentials"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/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-VX9Q-RHV9-3JVG
Vulnerability from github – Published: 2025-12-12 22:12 – Updated: 2026-02-25 15:32Summary
Incorrect handling of malformed data in Java-based decompressor implementations for Snappy and LZ4 allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data.
Details
With certain crafted compressed inputs, elements from the output buffer can end up in the uncompressed output. This is relevant for applications that reuse the same output buffer to uncompress multiple inputs. This can be the case of a web server that allocates a fix-sized buffer for performance purposes. This is similar to GHSA-cmp6-m4wj-q63q.
Impact
Applications using aircompressor as described above may leak sensitive information to external unauthorized attackers.
Mitigation
The vulnerability is fixed in release 3.4 and 2.0.3. However, it can be mitigated by either: * Avoiding reuse of the decompression buffer across calls * Clearing the decompression buffer before a call to decompress data
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "io.airlift:aircompressor-v3"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.4"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"package": {
"ecosystem": "Maven",
"name": "io.airlift:aircompressor"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.0.3"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-67721"
],
"database_specific": {
"cwe_ids": [
"CWE-125",
"CWE-201"
],
"github_reviewed": true,
"github_reviewed_at": "2025-12-12T22:12:22Z",
"nvd_published_at": "2025-12-12T23:15:42Z",
"severity": "HIGH"
},
"details": "### Summary\nIncorrect handling of malformed data in Java-based decompressor implementations for Snappy and LZ4 allows remote attackers to read previous buffer contents via crafted compressed input. In applications where the output buffer is reused without being cleared, this may lead to disclosure of sensitive data.\n\n### Details\nWith certain crafted compressed inputs, elements from the output buffer can end up in the uncompressed output. This is relevant for applications that reuse the same output buffer to uncompress multiple inputs. This can be the case of a web server that allocates a fix-sized buffer for performance purposes. This is similar to [GHSA-cmp6-m4wj-q63q](https://github.com/yawkat/lz4-java/security/advisories/GHSA-cmp6-m4wj-q63q).\n\n### Impact\nApplications using aircompressor as described above may leak sensitive information to external unauthorized attackers.\n\n### Mitigation\n\nThe vulnerability is fixed in release 3.4 and 2.0.3. However, it can be mitigated by either:\n* Avoiding reuse of the decompression buffer across calls\n* Clearing the decompression buffer before a call to decompress data",
"id": "GHSA-vx9q-rhv9-3jvg",
"modified": "2026-02-25T15:32:27Z",
"published": "2025-12-12T22:12:22Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/airlift/aircompressor/security/advisories/GHSA-vx9q-rhv9-3jvg"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-67721"
},
{
"type": "WEB",
"url": "https://github.com/airlift/aircompressor/pull/309"
},
{
"type": "WEB",
"url": "https://github.com/airlift/aircompressor/commit/f2b489b398779b40c1ee29ddb11d7edef54ddc15"
},
{
"type": "WEB",
"url": "https://github.com/airlift/aircompressor/commit/ff12c4d5757c9d6d1de3d39a10402f1f84f9b765"
},
{
"type": "PACKAGE",
"url": "https://github.com/airlift/aircompressor"
},
{
"type": "WEB",
"url": "https://github.com/airlift/aircompressor/releases/tag/2.0.3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "aircompressor Snappy and LZ4 Java-based decompressor implementation can leak information from reused output buffer"
}
GHSA-VXMF-3R42-MV9X
Vulnerability from github – Published: 2026-06-15 21:30 – Updated: 2026-06-15 21:30Unauthenticated Sensitive Data Exposure in Simply Schedule Appointments < 1.6.11.2 versions.
{
"affected": [],
"aliases": [
"CVE-2026-42384"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-06-15T21:16:54Z",
"severity": "HIGH"
},
"details": "Unauthenticated Sensitive Data Exposure in Simply Schedule Appointments \u003c 1.6.11.2 versions.",
"id": "GHSA-vxmf-3r42-mv9x",
"modified": "2026-06-15T21:30:46Z",
"published": "2026-06-15T21:30:46Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42384"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/simply-schedule-appointments/vulnerability/wordpress-simply-schedule-appointments-plugin-1-6-11-2-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W2RF-V2FH-5MJH
Vulnerability from github – Published: 2023-06-07 18:30 – Updated: 2024-04-04 04:39An issue has been discovered in GitLab EE affecting all versions starting from 15.7 before 15.10.8, all versions starting from 15.11 before 15.11.7, all versions starting from 16.0 before 16.0.2. It was possible to disclose issue notes to an unauthorized user at project export.
{
"affected": [],
"aliases": [
"CVE-2023-1825"
],
"database_specific": {
"cwe_ids": [
"CWE-201",
"CWE-668"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-06-07T17:15:09Z",
"severity": "MODERATE"
},
"details": "An issue has been discovered in GitLab EE affecting all versions starting from 15.7 before 15.10.8, all versions starting from 15.11 before 15.11.7, all versions starting from 16.0 before 16.0.2. It was possible to disclose issue notes to an unauthorized user at project export.",
"id": "GHSA-w2rf-v2fh-5mjh",
"modified": "2024-04-04T04:39:31Z",
"published": "2023-06-07T18:30:18Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-1825"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/cves/-/blob/master/2023/CVE-2023-1825.json"
},
{
"type": "WEB",
"url": "https://gitlab.com/gitlab-org/gitlab/-/issues/384035"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W4GP-FJGQ-3Q4G
Vulnerability from github – Published: 2026-03-29 15:23 – Updated: 2026-03-29 15:23Summary
happy-dom may attach cookies from the current page origin (window.location) instead of the request target URL when fetch(..., { credentials: "include" }) is used. This can leak cookies from origin A to destination B.
Details
In packages/happy-dom/src/fetch/utilities/FetchRequestHeaderUtility.ts (getRequestHeaders()), cookie selection is performed with originURL:
const originURL = new URL(options.window.location.href);
const isCORS = FetchCORSUtility.isCORS(originURL, options.request[PropertySymbol.url]);
// ...
const cookies = options.browserFrame.page.context.cookieContainer.getCookies(
originURL,
false
);
Here, originURL represents the page URL, not the request destination URL. For outgoing requests, cookie lookup should use the request URL (for example: new URL(options.request[PropertySymbol.url])).
PoC Script Content
const http = require('http');
const dns = require('dns').promises;
const { Browser } = require('happy-dom');
async function listen(server, host) {
return new Promise((resolve) => server.listen(0, host, () => resolve(server.address().port)));
}
async function run() {
let observedCookieHeader = null;
const pageHost = process.env.PAGE_HOST || 'a.127.0.0.1.nip.io';
const apiHost = process.env.API_HOST || 'b.127.0.0.1.nip.io';
console.log('=== PoC: Wrong Cookie Source URL in credentials:include ===');
console.log('Setup:');
console.log(` Page Origin Host : ${pageHost}`);
console.log(` Request Target Host: ${apiHost}`);
console.log(' (both resolve to 127.0.0.1 via public wildcard DNS)');
console.log('');
await dns.lookup(pageHost);
await dns.lookup(apiHost);
const pageServer = http.createServer((req, res) => {
res.writeHead(200, { 'content-type': 'text/plain' });
res.end('page host');
});
const apiServer = http.createServer((req, res) => {
observedCookieHeader = req.headers.cookie || '';
const origin = req.headers.origin || '';
res.writeHead(200, {
'content-type': 'application/json',
'access-control-allow-origin': origin,
'access-control-allow-credentials': 'true'
});
res.end(JSON.stringify({ ok: true }));
});
const pagePort = await listen(pageServer, '127.0.0.1');
const apiPort = await listen(apiServer, '127.0.0.1');
const browser = new Browser();
try {
const context = browser.defaultContext;
// Page host: pageHost (local DNS)
const page = context.newPage();
page.mainFrame.url = `http://${pageHost}:${pagePort}/dashboard`;
page.mainFrame.window.document.cookie = 'page_cookie=PAGE_ONLY';
// Target host: apiHost (local DNS)
const apiSeedPage = context.newPage();
apiSeedPage.mainFrame.url = `http://${apiHost}:${apiPort}/seed`;
apiSeedPage.mainFrame.window.document.cookie = 'api_cookie=API_ONLY';
// Trigger cross-host request with credentials.
const res = await page.mainFrame.window.fetch(`http://${apiHost}:${apiPort}/data`, {
credentials: 'include'
});
await res.text();
const leakedPageCookie = observedCookieHeader.includes('page_cookie=PAGE_ONLY');
const expectedApiCookie = observedCookieHeader.includes('api_cookie=API_ONLY');
console.log('Expected:');
console.log(' Request to target host should include "api_cookie=API_ONLY".');
console.log(' Request should NOT include "page_cookie=PAGE_ONLY".');
console.log('');
console.log('Actual:');
console.log(` request cookie header: "${observedCookieHeader || '(empty)'}"`);
console.log(` includes page_cookie: ${leakedPageCookie}`);
console.log(` includes api_cookie : ${expectedApiCookie}`);
console.log('');
if (leakedPageCookie && !expectedApiCookie) {
console.log('Result: VULNERABLE behavior reproduced.');
process.exitCode = 0;
} else {
console.log('Result: Vulnerable behavior NOT reproduced in this run/version.');
process.exitCode = 1;
}
} finally {
await browser.close();
pageServer.close();
apiServer.close();
}
}
run().catch((error) => {
console.error(error);
process.exit(1);
});
Environment:
1. Node.js >= 22
2. happy-dom 20.6.1
3. DNS names resolving to local loopback via *.127.0.0.1.nip.io
Reproduction steps:
1. Set page host cookie: page_cookie=PAGE_ONLY on a.127.0.0.1.nip.io
2. Set target host cookie: api_cookie=API_ONLY on b.127.0.0.1.nip.io
3. From page host, call fetch to target host with credentials: "include"
4. Observe Cookie header received by the target host
Expected:
1. Include api_cookie=API_ONLY
2. Do not include page_cookie=PAGE_ONLY
Actual (observed):
1. Includes page_cookie=PAGE_ONLY
2. Does not include api_cookie=API_ONLY
Observed output:
=== PoC: Wrong Cookie Source URL in credentials:include ===
Setup:
Page Origin Host : a.127.0.0.1.nip.io
Request Target Host: b.127.0.0.1.nip.io
(both resolve to 127.0.0.1 via public wildcard DNS)
Expected:
Request to target host should include "api_cookie=API_ONLY".
Request should NOT include "page_cookie=PAGE_ONLY".
Actual:
request cookie header: "page_cookie=PAGE_ONLY"
includes page_cookie: true
includes api_cookie : false
Result: VULNERABLE behavior reproduced.
Impact
Cross-origin sensitive information disclosure (cookie leakage).
Impacted users are applications relying on happy-dom browser-like fetch behavior in authenticated/session-based flows (for example SSR/test/proxy-like scenarios), where cookies from one origin can be sent to another origin.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "happy-dom"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "20.8.9"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-34226"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-29T15:23:57Z",
"nvd_published_at": "2026-03-27T22:16:23Z",
"severity": "HIGH"
},
"details": "### Summary\n`happy-dom` may attach cookies from the current page origin (`window.location`) instead of the request target URL when `fetch(..., { credentials: \"include\" })` is used. This can leak cookies from origin A to destination B.\n\n### Details\nIn [`packages/happy-dom/src/fetch/utilities/FetchRequestHeaderUtility.ts`](https://github.com/capricorn86/happy-dom/blob/f8d8cad41e9722fab9eefb9dfb3cca696462e908/packages/happy-dom/src/fetch/utilities/FetchRequestHeaderUtility.ts) (`getRequestHeaders()`), cookie selection is performed with `originURL`:\n\n```ts\nconst originURL = new URL(options.window.location.href);\nconst isCORS = FetchCORSUtility.isCORS(originURL, options.request[PropertySymbol.url]);\n// ...\nconst cookies = options.browserFrame.page.context.cookieContainer.getCookies(\n originURL,\n false\n);\n```\n\nHere, `originURL` represents the page URL, not the request destination URL. For outgoing requests, cookie lookup should use the request URL (for example: `new URL(options.request[PropertySymbol.url])`).\n\n### PoC Script Content\n\n```javascript\nconst http = require(\u0027http\u0027);\nconst dns = require(\u0027dns\u0027).promises;\nconst { Browser } = require(\u0027happy-dom\u0027);\n\nasync function listen(server, host) {\n return new Promise((resolve) =\u003e server.listen(0, host, () =\u003e resolve(server.address().port)));\n}\n\nasync function run() {\n let observedCookieHeader = null;\n const pageHost = process.env.PAGE_HOST || \u0027a.127.0.0.1.nip.io\u0027;\n const apiHost = process.env.API_HOST || \u0027b.127.0.0.1.nip.io\u0027;\n\n console.log(\u0027=== PoC: Wrong Cookie Source URL in credentials:include ===\u0027);\n console.log(\u0027Setup:\u0027);\n console.log(` Page Origin Host : ${pageHost}`);\n console.log(` Request Target Host: ${apiHost}`);\n console.log(\u0027 (both resolve to 127.0.0.1 via public wildcard DNS)\u0027);\n console.log(\u0027\u0027);\n\n await dns.lookup(pageHost);\n await dns.lookup(apiHost);\n\n const pageServer = http.createServer((req, res) =\u003e {\n res.writeHead(200, { \u0027content-type\u0027: \u0027text/plain\u0027 });\n res.end(\u0027page host\u0027);\n });\n\n const apiServer = http.createServer((req, res) =\u003e {\n observedCookieHeader = req.headers.cookie || \u0027\u0027;\n const origin = req.headers.origin || \u0027\u0027;\n res.writeHead(200, {\n \u0027content-type\u0027: \u0027application/json\u0027,\n \u0027access-control-allow-origin\u0027: origin,\n \u0027access-control-allow-credentials\u0027: \u0027true\u0027\n });\n res.end(JSON.stringify({ ok: true }));\n });\n\n const pagePort = await listen(pageServer, \u0027127.0.0.1\u0027);\n const apiPort = await listen(apiServer, \u0027127.0.0.1\u0027);\n\n const browser = new Browser();\n\n try {\n const context = browser.defaultContext;\n\n // Page host: pageHost (local DNS)\n const page = context.newPage();\n page.mainFrame.url = `http://${pageHost}:${pagePort}/dashboard`;\n page.mainFrame.window.document.cookie = \u0027page_cookie=PAGE_ONLY\u0027;\n\n // Target host: apiHost (local DNS)\n const apiSeedPage = context.newPage();\n apiSeedPage.mainFrame.url = `http://${apiHost}:${apiPort}/seed`;\n apiSeedPage.mainFrame.window.document.cookie = \u0027api_cookie=API_ONLY\u0027;\n\n // Trigger cross-host request with credentials.\n const res = await page.mainFrame.window.fetch(`http://${apiHost}:${apiPort}/data`, {\n credentials: \u0027include\u0027\n });\n await res.text();\n\n const leakedPageCookie = observedCookieHeader.includes(\u0027page_cookie=PAGE_ONLY\u0027);\n const expectedApiCookie = observedCookieHeader.includes(\u0027api_cookie=API_ONLY\u0027);\n\n console.log(\u0027Expected:\u0027);\n console.log(\u0027 Request to target host should include \"api_cookie=API_ONLY\".\u0027);\n console.log(\u0027 Request should NOT include \"page_cookie=PAGE_ONLY\".\u0027);\n console.log(\u0027\u0027);\n\n console.log(\u0027Actual:\u0027);\n console.log(` request cookie header: \"${observedCookieHeader || \u0027(empty)\u0027}\"`);\n console.log(` includes page_cookie: ${leakedPageCookie}`);\n console.log(` includes api_cookie : ${expectedApiCookie}`);\n console.log(\u0027\u0027);\n\n if (leakedPageCookie \u0026\u0026 !expectedApiCookie) {\n console.log(\u0027Result: VULNERABLE behavior reproduced.\u0027);\n process.exitCode = 0;\n } else {\n console.log(\u0027Result: Vulnerable behavior NOT reproduced in this run/version.\u0027);\n process.exitCode = 1;\n }\n } finally {\n await browser.close();\n pageServer.close();\n apiServer.close();\n }\n}\n\nrun().catch((error) =\u003e {\n console.error(error);\n process.exit(1);\n});\n\n```\n\n\nEnvironment:\n1. Node.js \u003e= 22\n2. `happy-dom` 20.6.1\n3. DNS names resolving to local loopback via `*.127.0.0.1.nip.io`\n\nReproduction steps:\n1. Set page host cookie: `page_cookie=PAGE_ONLY` on `a.127.0.0.1.nip.io`\n2. Set target host cookie: `api_cookie=API_ONLY` on `b.127.0.0.1.nip.io`\n3. From page host, call fetch to target host with `credentials: \"include\"`\n4. Observe `Cookie` header received by the target host\n\nExpected:\n1. Include `api_cookie=API_ONLY`\n2. Do not include `page_cookie=PAGE_ONLY`\n\nActual (observed):\n1. Includes `page_cookie=PAGE_ONLY`\n2. Does not include `api_cookie=API_ONLY`\n\nObserved output:\n```text\n=== PoC: Wrong Cookie Source URL in credentials:include ===\nSetup:\n Page Origin Host : a.127.0.0.1.nip.io\n Request Target Host: b.127.0.0.1.nip.io\n (both resolve to 127.0.0.1 via public wildcard DNS)\n\nExpected:\n Request to target host should include \"api_cookie=API_ONLY\".\n Request should NOT include \"page_cookie=PAGE_ONLY\".\n\nActual:\n request cookie header: \"page_cookie=PAGE_ONLY\"\n includes page_cookie: true\n includes api_cookie : false\n\nResult: VULNERABLE behavior reproduced.\n```\n\n### Impact\nCross-origin sensitive information disclosure (cookie leakage).\nImpacted users are applications relying on `happy-dom` browser-like fetch behavior in authenticated/session-based flows (for example SSR/test/proxy-like scenarios), where cookies from one origin can be sent to another origin.",
"id": "GHSA-w4gp-fjgq-3q4g",
"modified": "2026-03-29T15:23:57Z",
"published": "2026-03-29T15:23:57Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/capricorn86/happy-dom/security/advisories/GHSA-w4gp-fjgq-3q4g"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-34226"
},
{
"type": "WEB",
"url": "https://github.com/capricorn86/happy-dom/pull/2117"
},
{
"type": "WEB",
"url": "https://github.com/capricorn86/happy-dom/commit/68324c21d7b98f53f7bb5a7b3e185bda7106e751"
},
{
"type": "PACKAGE",
"url": "https://github.com/capricorn86/happy-dom"
},
{
"type": "WEB",
"url": "https://github.com/capricorn86/happy-dom/blob/f8d8cad41e9722fab9eefb9dfb3cca696462e908/packages/happy-dom/src/fetch/utilities/FetchRequestHeaderUtility.ts"
},
{
"type": "WEB",
"url": "https://github.com/capricorn86/happy-dom/releases/tag/v20.8.9"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Happy DOM\u0027s fetch credentials include uses page-origin cookies instead of target-origin cookies"
}
GHSA-W59F-V72R-W493
Vulnerability from github – Published: 2026-04-10 18:31 – Updated: 2026-06-30 03:36A flaw was found in odh-dashboard in Red Hat Openshift AI. This vulnerability in the odh-dashboard component of Red Hat OpenShift AI (RHOAI) allows for the disclosure of Kubernetes Service Account tokens through a NodeJS endpoint. This could enable an attacker to gain unauthorized access to Kubernetes resources.
{
"affected": [],
"aliases": [
"CVE-2026-5483"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-04-10T18:16:46Z",
"severity": "HIGH"
},
"details": "A flaw was found in odh-dashboard in Red Hat Openshift AI. This vulnerability in the `odh-dashboard` component of Red Hat OpenShift AI (RHOAI) allows for the disclosure of Kubernetes Service Account tokens through a NodeJS endpoint. This could enable an attacker to gain unauthorized access to Kubernetes resources.",
"id": "GHSA-w59f-v72r-w493",
"modified": "2026-06-30T03:36:15Z",
"published": "2026-04-10T18:31:20Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-5483"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7397"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7398"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7403"
},
{
"type": "WEB",
"url": "https://access.redhat.com/errata/RHSA-2026:7404"
},
{
"type": "WEB",
"url": "https://access.redhat.com/security/cve/CVE-2026-5483"
},
{
"type": "WEB",
"url": "https://bugzilla.redhat.com/show_bug.cgi?id=2454764"
},
{
"type": "WEB",
"url": "https://security.access.redhat.com/data/csaf/v2/vex/2026/cve-2026-5483.json"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-W5P4-PRG7-WVR7
Vulnerability from github – Published: 2025-04-01 15:31 – Updated: 2026-04-01 18:34Insertion of Sensitive Information Into Sent Data vulnerability in viralloops Viral Loops WP Integration allows Retrieve Embedded Sensitive Data. This issue affects Viral Loops WP Integration: from n/a through 3.4.0.
{
"affected": [],
"aliases": [
"CVE-2025-31842"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-04-01T15:16:24Z",
"severity": "MODERATE"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in viralloops Viral Loops WP Integration allows Retrieve Embedded Sensitive Data. This issue affects Viral Loops WP Integration: from n/a through 3.4.0.",
"id": "GHSA-w5p4-prg7-wvr7",
"modified": "2026-04-01T18:34:22Z",
"published": "2025-04-01T15:31:43Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-31842"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/viral-loops-wp-integration/vulnerability/wordpress-viral-loops-wp-integration-plugin-3-4-0-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W5X6-33VR-7XMP
Vulnerability from github – Published: 2026-07-06 00:30 – Updated: 2026-07-06 00:30Insertion of Sensitive Information Into Sent Data vulnerability in Tim Strifler Exclusive Addons Elementor allows Retrieve Embedded Sensitive Data.
This issue affects Exclusive Addons Elementor: from n/a through 2.7.9.9.
{
"affected": [],
"aliases": [
"CVE-2026-59511"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-05T22:16:53Z",
"severity": "MODERATE"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in Tim Strifler Exclusive Addons Elementor allows Retrieve Embedded Sensitive Data.\n\nThis issue affects Exclusive Addons Elementor: from n/a through 2.7.9.9.",
"id": "GHSA-w5x6-33vr-7xmp",
"modified": "2026-07-06T00:30:23Z",
"published": "2026-07-06T00:30:22Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-59511"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/wordpress/plugin/exclusive-addons-for-elementor/vulnerability/wordpress-exclusive-addons-elementor-plugin-2-7-9-9-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-W842-93V8-G866
Vulnerability from github – Published: 2025-06-06 06:30 – Updated: 2025-06-06 06:30The Modern Events Calendar Lite plugin for WordPress is vulnerable to Full Path Disclosure in all versions up to, and including, 7.21.9. This is due improper or insufficient validation of the id property when exporting calendars. This makes it possible for unauthenticated attackers to retrieve the full path of the web application, which can be used to aid other attacks. The information displayed is not useful on its own, and requires another vulnerability to be present for damage to an affected website.
{
"affected": [],
"aliases": [
"CVE-2025-5733"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-06-06T04:16:01Z",
"severity": "MODERATE"
},
"details": "The Modern Events Calendar Lite plugin for WordPress is vulnerable to Full Path Disclosure in all versions up to, and including, 7.21.9. This is due improper or insufficient validation of the id property when exporting calendars. This makes it possible for unauthenticated attackers to retrieve the full path of the web application, which can be used to aid other attacks. The information displayed is not useful on its own, and requires another vulnerability to be present for damage to an affected website.",
"id": "GHSA-w842-93v8-g866",
"modified": "2025-06-06T06:30:26Z",
"published": "2025-06-06T06:30:26Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-5733"
},
{
"type": "WEB",
"url": "https://webnus.net/dox/modern-events-calendar"
},
{
"type": "WEB",
"url": "https://wordpress.org/plugins/modern-events-calendar-lite"
},
{
"type": "WEB",
"url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/e545b53e-7054-41dc-b69b-7552ef6c3240?source=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-WG3C-3523-F9FC
Vulnerability from github – Published: 2026-02-20 18:31 – Updated: 2026-02-25 18:31Insertion of Sensitive Information Into Sent Data vulnerability in themeglow JobBoard Job listing job-board-light allows Retrieve Embedded Sensitive Data.This issue affects JobBoard Job listing: from n/a through <= 1.2.8.
{
"affected": [],
"aliases": [
"CVE-2025-68855"
],
"database_specific": {
"cwe_ids": [
"CWE-201"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-02-20T16:22:14Z",
"severity": "MODERATE"
},
"details": "Insertion of Sensitive Information Into Sent Data vulnerability in themeglow JobBoard Job listing job-board-light allows Retrieve Embedded Sensitive Data.This issue affects JobBoard Job listing: from n/a through \u003c= 1.2.8.",
"id": "GHSA-wg3c-3523-f9fc",
"modified": "2026-02-25T18:31:28Z",
"published": "2026-02-20T18:31:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-68855"
},
{
"type": "WEB",
"url": "https://patchstack.com/database/Wordpress/Plugin/job-board-light/vulnerability/wordpress-jobboard-job-listing-plugin-1-2-8-sensitive-data-exposure-vulnerability?_s_id=cve"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
Mitigation
Specify which data in the software should be regarded as sensitive. Consider which types of users should have access to which types of data.
Mitigation
Ensure that any possibly sensitive data specified in the requirements is verified with designers to ensure that it is either a calculated risk or mitigated elsewhere. Any information that is not necessary to the functionality should be removed in order to lower both the overhead and the possibility of security sensitive data being sent.
Mitigation
Setup default error messages so that unexpected errors do not disclose sensitive information.
Mitigation MIT-46
Strategy: Separation of Privilege
- Compartmentalize the system to have "safe" areas where trust boundaries can be unambiguously drawn. Do not allow sensitive data to go outside of the trust boundary and always be careful when interfacing with a compartment outside of the safe area.
- Ensure that appropriate compartmentalization is built into the system design, and the compartmentalization allows for and reinforces privilege separation functionality. Architects and designers should rely on the principle of least privilege to decide the appropriate time to use privileges and the time to drop privileges.
CAPEC-12: Choosing Message Identifier
This pattern of attack is defined by the selection of messages distributed via multicast or public information channels that are intended for another client by determining the parameter value assigned to that client. This attack allows the adversary to gain access to potentially privileged information, and to possibly perpetrate other attacks through the distribution means by impersonation. If the channel/message being manipulated is an input rather than output mechanism for the system, (such as a command bus), this style of attack could be used to change the adversary's identifier to more a privileged one.
CAPEC-217: Exploiting Incorrectly Configured SSL/TLS
An adversary takes advantage of incorrectly configured SSL/TLS communications that enables access to data intended to be encrypted. The adversary may also use this type of attack to inject commands or other traffic into the encrypted stream to cause compromise of either the client or server.
CAPEC-612: WiFi MAC Address Tracking
In this attack scenario, the attacker passively listens for WiFi messages and logs the associated Media Access Control (MAC) addresses. These addresses are intended to be unique to each wireless device (although they can be configured and changed by software). Once the attacker is able to associate a MAC address with a particular user or set of users (for example, when attending a public event), the attacker can then scan for that MAC address to track that user in the future.
CAPEC-613: WiFi SSID Tracking
In this attack scenario, the attacker passively listens for WiFi management frame messages containing the Service Set Identifier (SSID) for the WiFi network. These messages are frequently transmitted by WiFi access points (e.g., the retransmission device) as well as by clients that are accessing the network (e.g., the handset/mobile device). Once the attacker is able to associate an SSID with a particular user or set of users (for example, when attending a public event), the attacker can then scan for this SSID to track that user in the future.
CAPEC-618: Cellular Broadcast Message Request
In this attack scenario, the attacker uses knowledge of the target’s mobile phone number (i.e., the number associated with the SIM used in the retransmission device) to cause the cellular network to send broadcast messages to alert the mobile device. Since the network knows which cell tower the target’s mobile device is attached to, the broadcast messages are only sent in the Location Area Code (LAC) where the target is currently located. By triggering the cellular broadcast message and then listening for the presence or absence of that message, an attacker could verify that the target is in (or not in) a given location.
CAPEC-619: Signal Strength Tracking
In this attack scenario, the attacker passively monitors the signal strength of the target’s cellular RF signal or WiFi RF signal and uses the strength of the signal (with directional antennas and/or from multiple listening points at once) to identify the source location of the signal. Obtaining the signal of the target can be accomplished through multiple techniques such as through Cellular Broadcast Message Request or through the use of IMSI Tracking or WiFi MAC Address Tracking.
CAPEC-621: Analysis of Packet Timing and Sizes
An attacker may intercept and log encrypted transmissions for the purpose of analyzing metadata such as packet timing and sizes. Although the actual data may be encrypted, this metadata may reveal valuable information to an attacker. Note that this attack is applicable to VOIP data as well as application data, especially for interactive apps that require precise timing and low-latency (e.g. thin-clients).
CAPEC-622: Electromagnetic Side-Channel Attack
In this attack scenario, the attacker passively monitors electromagnetic emanations that are produced by the targeted electronic device as an unintentional side-effect of its processing. From these emanations, the attacker derives information about the data that is being processed (e.g. the attacker can recover cryptographic keys by monitoring emanations associated with cryptographic processing). This style of attack requires proximal access to the device, however attacks have been demonstrated at public conferences that work at distances of up to 10-15 feet. There have not been any significant studies to determine the maximum practical distance for such attacks. Since the attack is passive, it is nearly impossible to detect and the targeted device will continue to operate as normal after a successful attack.
CAPEC-623: Compromising Emanations Attack
Compromising Emanations (CE) are defined as unintentional signals which an attacker may intercept and analyze to disclose the information processed by the targeted equipment. Commercial mobile devices and retransmission devices have displays, buttons, microchips, and radios that emit mechanical emissions in the form of sound or vibrations. Capturing these emissions can help an adversary understand what the device is doing.