CWE-290
AllowedAuthentication Bypass by Spoofing
Abstraction: Base · Status: Incomplete
This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.
1199 vulnerabilities reference this CWE, most recent first.
GHSA-3MF6-CPXV-733M
Vulnerability from github – Published: 2022-05-13 01:07 – Updated: 2022-05-13 01:07EMC Unisphere for VMAX Virtual Appliance (vApp) versions prior to 8.4.0.15, EMC Solutions Enabler Virtual Appliance versions prior to 8.4.0.15, EMC VASA Virtual Appliance versions prior to 8.4.0.512, and EMC VMAX Embedded Management (eManagement) versions prior to and including 1.4 (Enginuity Release 5977.1125.1125 and earlier) contain an authentication bypass vulnerability that may potentially be exploited by malicious users to compromise the affected system.
{
"affected": [],
"aliases": [
"CVE-2017-14375"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-01T01:29:00Z",
"severity": "CRITICAL"
},
"details": "EMC Unisphere for VMAX Virtual Appliance (vApp) versions prior to 8.4.0.15, EMC Solutions Enabler Virtual Appliance versions prior to 8.4.0.15, EMC VASA Virtual Appliance versions prior to 8.4.0.512, and EMC VMAX Embedded Management (eManagement) versions prior to and including 1.4 (Enginuity Release 5977.1125.1125 and earlier) contain an authentication bypass vulnerability that may potentially be exploited by malicious users to compromise the affected system.",
"id": "GHSA-3mf6-cpxv-733m",
"modified": "2022-05-13T01:07:27Z",
"published": "2022-05-13T01:07:27Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-14375"
},
{
"type": "WEB",
"url": "http://seclists.org/fulldisclosure/2017/Oct/70"
},
{
"type": "WEB",
"url": "http://www.securityfocus.com/bid/101673"
},
{
"type": "WEB",
"url": "http://www.securitytracker.com/id/1039704"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3MM3-WFPV-Q85G
Vulnerability from github – Published: 2025-11-20 21:30 – Updated: 2025-11-21 00:38An issue was discovered in Clerk-js 5.88.0 allowing attackers to bypass the OAuth authentication flow by manipulating the request at the OTP verification stage.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "@clerk/clerk-js"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"last_affected": "5.88.0"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2025-63700"
],
"database_specific": {
"cwe_ids": [
"CWE-290",
"CWE-639"
],
"github_reviewed": true,
"github_reviewed_at": "2025-11-21T00:38:59Z",
"nvd_published_at": "2025-11-20T19:16:21Z",
"severity": "MODERATE"
},
"details": "An issue was discovered in Clerk-js 5.88.0 allowing attackers to bypass the OAuth authentication flow by manipulating the request at the OTP verification stage.",
"id": "GHSA-3mm3-wfpv-q85g",
"modified": "2025-11-21T00:38:59Z",
"published": "2025-11-20T21:30:32Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-63700"
},
{
"type": "WEB",
"url": "https://clerk.com"
},
{
"type": "PACKAGE",
"url": "https://github.com/clerk/javascript"
},
{
"type": "WEB",
"url": "https://github.com/itsnishat08/CVE-2025-63700"
}
],
"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:N/VI:H/VA:N/SC:N/SI:N/SA:N/E:U",
"type": "CVSS_V4"
}
],
"summary": "Clerk-js vulnerable to bypass of OAuth authentication flow by manipulating request at OTP verification stage"
}
GHSA-3MP7-4RH5-JRV9
Vulnerability from github – Published: 2026-09-03 22:34 – Updated: 2026-09-03 22:34CVE: This vulnerability corresponds to CVE-2026-72809.
Summary
The kernel's CheckAuth grants RoleAdministrator to any request whose RemoteAddr is loopback (127.0.0.1), for a specific set of endpoints, and these localhost bypasses sit outside the accessAuthCode gate so they apply even when an access auth code is configured. This is demonstrated live (Part A below).
Separately, the fixed-port reverse proxy (fixedport.go) forwards requests to the kernel over loopback and injects no authentication token, and no SetTrustedProxies is configured, so gin does not derive the client address from forwarding headers. By code inspection, a request forwarded through this proxy would reach the kernel with RemoteAddr = 127.0.0.1. If the fixed-port proxy is bound to a network interface (via NetworkServe) and forwards remote requests to the kernel this way, the localhost bypass would grant a remote unauthenticated caller admin on those endpoints. This second step is established by reading the code but was not reproduced end-to-end, and I'm asking the maintainer to confirm the proxy's runtime forwarding behavior (Part B below).
Details
Localhost-trust admin bypass (proven). CheckAuth (session.go:298-321) contains localhost-only bypasses that key off RemoteAddr and grant RoleAdministrator. They sit outside the accessAuthCode gate i.e. they apply even when an access auth code is set and cover /api/system/exit, getNetwork, getWorkspaceInfo, /assets/*, and /export/*.
Fixed-port proxy behavior (code inspection). fixedport.go is a plain reverse proxy that dials the kernel at 127.0.0.1 and injects no token unlike the publish proxy, which injects a RoleReader JWT. There is no SetTrustedProxies call, so gin does not rewrite RemoteAddr from X-Forwarded-For. On this reading, a request forwarded through the fixed-port proxy reaches the kernel with RemoteAddr = 127.0.0.1.
The composition (conditional). If both hold at runtime, then: remote request → fixed-port proxy on a network interface → forwarded to kernel at 127.0.0.1 (no token) → kernel sees RemoteAddr = 127.0.0.1 → localhost bypass grants admin for the endpoints above. I have proven the final link (localhost → admin) and read the code for the forwarding link, but have not confirmed at runtime that the fixed-port proxy is instantiated and forwards remote requests as loopback in a shipped configuration.
Distinct from the previously-dismissed localhost→admin observation. That observation concerned the publish proxy path, where the injected RoleReader JWT causes CheckAuth to early-return before reaching the localhost bypasses. The fixed-port proxy injects no token, so a request through it would fall through to the RemoteAddr-keyed bypass instead. Different proxy, different code path.
Proof of Concept
Part A: the localhost bypass grants admin without auth, outside the auth-code gate (demonstrated live).
On a local instance with an access auth code configured, the same no-token getWorkspaceInfo request returns different results depending on the source address the kernel sees:
- From a non-loopback source (kernel sees a non-127.0.0.1 address): HTTP 401.
- From 127.0.0.1 (kernel sees loopback): {"code":0,"data":{"workspaceDir":"/siyuan/workspace",…}} admin data, no auth, despite accessAuthCode being set.
This confirms the localhost-trust bypass grants admin for these endpoints and is not gated by the access auth code.
Part B: remote → proxy → loopback (code inspection only; NOT reproduced).
By reading fixedport.go, the proxy dials 127.0.0.1, injects no token, and no SetTrustedProxies is set. I was not able to reproduce this end-to-end: the serve CLI in the container image tested exposes only --port and --accessAuthCode, not a flag that instantiates the fixed-port proxy in the NetworkServe-on-a-non-default-port shape, so the remote→proxy→loopback chain was not exercised at runtime. I did not invoke the destructive /api/system/exit endpoint. I'm asking the maintainer to confirm: under what conditions is the fixed-port proxy instantiated, does it bind a non-loopback interface under NetworkServe, and does it forward to the kernel preserving the client address or as loopback? That determines whether Part A's bypass is remotely reachable.
Impact
Confirmed (Part A): on any deployment where a caller can cause the kernel to see a loopback RemoteAddr, the endpoints /api/system/exit, getNetwork, getWorkspaceInfo, /assets/*, and /export/* are reachable with admin rights without the access auth code i.e. the auth code does not protect these endpoints against a loopback-sourced caller. On its own this is a local/adjacent bypass of the access-code control for those endpoints. If the fixed-port proxy forwards remote requests to the kernel as loopback (to be confirmed by the maintainer), a remote unauthenticated attacker obtains those admin capabilities, remote kernel shutdown (DoS), network/workspace-path disclosure, and admin-level asset/export reads that bypass the publish-access filter. This would be a remote authentication bypass. It does not grant the full admin API only the localhost-trusted endpoints.
Suggested fix
Do not derive admin trust from RemoteAddr when a proxy forwards over loopback. Options: have the fixed-port proxy inject an explicit role/token (as the publish proxy does) so the kernel authorizes on the claim rather than the source address; or configure SetTrustedProxies and derive the real client address before applying any localhost bypass; or require the access auth code for these endpoints regardless of source address. The localhost bypass assumes loopback implies a local trusted caller, any loopback-dialing proxy breaks that assumption.
{
"affected": [
{
"package": {
"ecosystem": "Go",
"name": "github.com/siyuan-note/siyuan/kernel"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "0.0.0-20260723031701-9c16e9851f0b"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-72809"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-09-03T22:34:06Z",
"nvd_published_at": null,
"severity": "HIGH"
},
"details": "**CVE:** This vulnerability corresponds to [CVE-2026-72809](https://nvd.nist.gov/vuln/detail/CVE-2026-72809).\n\n### Summary\n\nThe kernel\u0027s `CheckAuth` grants `RoleAdministrator` to any request whose `RemoteAddr` is loopback (`127.0.0.1`), for a specific set of endpoints, and these localhost bypasses sit **outside** the `accessAuthCode` gate so they apply even when an access auth code is configured. This is demonstrated live (Part A below).\n\nSeparately, the fixed-port reverse proxy (`fixedport.go`) forwards requests to the kernel over loopback and injects no authentication token, and no `SetTrustedProxies` is configured, so gin does not derive the client address from forwarding headers. By code inspection, a request forwarded through this proxy would reach the kernel with `RemoteAddr = 127.0.0.1`. **If** the fixed-port proxy is bound to a network interface (via `NetworkServe`) and forwards remote requests to the kernel this way, the localhost bypass would grant a remote unauthenticated caller admin on those endpoints. This second step is established by reading the code but was **not reproduced end-to-end**, and I\u0027m asking the maintainer to confirm the proxy\u0027s runtime forwarding behavior (Part B below).\n\n### Details\n\n**Localhost-trust admin bypass (proven).** `CheckAuth` (`session.go:298-321`) contains localhost-only bypasses that key off `RemoteAddr` and grant `RoleAdministrator`. They sit outside the `accessAuthCode` gate i.e. they apply even when an access auth code is set and cover `/api/system/exit`, `getNetwork`, `getWorkspaceInfo`, `/assets/*`, and `/export/*`.\n\n**Fixed-port proxy behavior (code inspection).** `fixedport.go` is a plain reverse proxy that dials the kernel at `127.0.0.1` and injects no token unlike the publish proxy, which injects a `RoleReader` JWT. There is no `SetTrustedProxies` call, so gin does not rewrite `RemoteAddr` from `X-Forwarded-For`. On this reading, a request forwarded through the fixed-port proxy reaches the kernel with `RemoteAddr = 127.0.0.1`.\n\n**The composition (conditional).** If both hold at runtime, then: remote request \u2192 fixed-port proxy on a network interface \u2192 forwarded to kernel at `127.0.0.1` (no token) \u2192 kernel sees `RemoteAddr = 127.0.0.1` \u2192 localhost bypass grants admin for the endpoints above. I have proven the final link (localhost \u2192 admin) and read the code for the forwarding link, but have not confirmed at runtime that the fixed-port proxy is instantiated and forwards remote requests as loopback in a shipped configuration.\n\n**Distinct from the previously-dismissed localhost\u2192admin observation.** That observation concerned the *publish* proxy path, where the injected `RoleReader` JWT causes `CheckAuth` to early-return before reaching the localhost bypasses. The fixed-port proxy injects no token, so a request through it would fall through to the `RemoteAddr`-keyed bypass instead. Different proxy, different code path.\n\n### Proof of Concept\n\n**Part A: the localhost bypass grants admin without auth, outside the auth-code gate (demonstrated live).**\nOn a local instance with an access auth code configured, the same no-token `getWorkspaceInfo` request returns different results depending on the source address the kernel sees:\n- From a non-loopback source (kernel sees a non-127.0.0.1 address): `HTTP 401`.\n- From `127.0.0.1` (kernel sees loopback): `{\"code\":0,\"data\":{\"workspaceDir\":\"/siyuan/workspace\",\u2026}}` admin data, no auth, despite `accessAuthCode` being set.\n\nThis confirms the localhost-trust bypass grants admin for these endpoints and is not gated by the access auth code.\n\n**Part B: remote \u2192 proxy \u2192 loopback (code inspection only; NOT reproduced).**\nBy reading `fixedport.go`, the proxy dials `127.0.0.1`, injects no token, and no `SetTrustedProxies` is set. I was not able to reproduce this end-to-end: the `serve` CLI in the container image tested exposes only `--port` and `--accessAuthCode`, not a flag that instantiates the fixed-port proxy in the `NetworkServe`-on-a-non-default-port shape, so the remote\u2192proxy\u2192loopback chain was not exercised at runtime. I did not invoke the destructive `/api/system/exit` endpoint. **I\u0027m asking the maintainer to confirm: under what conditions is the fixed-port proxy instantiated, does it bind a non-loopback interface under `NetworkServe`, and does it forward to the kernel preserving the client address or as loopback?** That determines whether Part A\u0027s bypass is remotely reachable.\n\n### Impact\n\n**Confirmed (Part A):** on any deployment where a caller can cause the kernel to see a loopback `RemoteAddr`, the endpoints `/api/system/exit`, `getNetwork`, `getWorkspaceInfo`, `/assets/*`, and `/export/*` are reachable with admin rights without the access auth code i.e. the auth code does not protect these endpoints against a loopback-sourced caller. On its own this is a local/adjacent bypass of the access-code control for those endpoints. If the fixed-port proxy forwards remote requests to the kernel as loopback (to be confirmed by the maintainer), a *remote* unauthenticated attacker obtains those admin capabilities, remote kernel shutdown (DoS), network/workspace-path disclosure, and admin-level asset/export reads that bypass the publish-access filter. This would be a remote authentication bypass. It does not grant the full admin API only the localhost-trusted endpoints.\n\n### Suggested fix\n\nDo not derive admin trust from `RemoteAddr` when a proxy forwards over loopback. Options: have the fixed-port proxy inject an explicit role/token (as the publish proxy does) so the kernel authorizes on the claim rather than the source address; or configure `SetTrustedProxies` and derive the real client address before applying any localhost bypass; or require the access auth code for these endpoints regardless of source address. The localhost bypass assumes loopback implies a local trusted caller, any loopback-dialing proxy breaks that assumption.",
"id": "GHSA-3mp7-4rh5-jrv9",
"modified": "2026-09-03T22:34:06Z",
"published": "2026-09-03T22:34:06Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/security/advisories/GHSA-3mp7-4rh5-jrv9"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72809"
},
{
"type": "WEB",
"url": "https://github.com/siyuan-note/siyuan/commit/9c16e9851f0b5d7ed179e5c2fca15a7724666871"
},
{
"type": "PACKAGE",
"url": "https://github.com/siyuan-note/siyuan"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/siyuan-before-authentication-bypass-via-localhost-trust"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:H",
"type": "CVSS_V3"
}
],
"summary": "SiYuan: Localhost-trust admin bypass on auth-code-gated endpoints, with potential remote reachability via the fixed-port proxy"
}
GHSA-3QG8-HQ7J-JJ33
Vulnerability from github – Published: 2026-06-13 00:34 – Updated: 2026-08-28 15:55Duplicate Advisory
This advisory has been withdrawn because it is a duplicate of GHSA-rggc-m335-3wvj. This link is maintained to preserve external references.
Original Description
OpenClaw before 2026.5.18 contains an identity header validation vulnerability allowing local same-host callers to forge trusted-proxy identity headers. Attackers with access to the proxy-facing Gateway port can supply forged identity headers to assume operator identity and potentially escalate privileges.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "openclaw"
},
"ranges": [
{
"events": [
{
"introduced": "0"
},
{
"fixed": "2026.5.18"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-08-28T15:55:42Z",
"nvd_published_at": "2026-06-12T22:16:54Z",
"severity": "HIGH"
},
"details": "### Duplicate Advisory\nThis advisory has been withdrawn because it is a duplicate of GHSA-rggc-m335-3wvj. This link is maintained to preserve external references.\n\n### Original Description\nOpenClaw before 2026.5.18 contains an identity header validation vulnerability allowing local same-host callers to forge trusted-proxy identity headers. Attackers with access to the proxy-facing Gateway port can supply forged identity headers to assume operator identity and potentially escalate privileges.",
"id": "GHSA-3qg8-hq7j-jj33",
"modified": "2026-08-28T15:55:42Z",
"published": "2026-06-13T00:34:32Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-rggc-m335-3wvj"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53832"
},
{
"type": "PACKAGE",
"url": "https://github.com/openclaw/openclaw"
},
{
"type": "WEB",
"url": "https://www.vulncheck.com/advisories/openclaw-identity-header-forgery-via-trusted-proxy-configuration"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:L/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
},
{
"score": "CVSS:4.0/AV:L/AC:L/AT:P/PR:N/UI:N/VC:H/VI:H/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: OpenClaw: Same-host trusted-proxy deployments could accept local forged identity headers",
"withdrawn": "2026-08-28T15:55:42Z"
}
GHSA-3QQR-W7GM-52GV
Vulnerability from github – Published: 2022-05-13 01:01 – Updated: 2022-05-13 01:01An exploitable vulnerability exists in the WiFi management of Circle with Disney. A crafted Access Point with the same name as the legitimate one can be used to make Circle connect to an untrusted network. An attacker needs to setup an Access Point reachable by the device and to send a series of spoofed "deauth" packets to trigger this vulnerability.
{
"affected": [],
"aliases": [
"CVE-2017-12096"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2017-11-07T16:29:00Z",
"severity": "MODERATE"
},
"details": "An exploitable vulnerability exists in the WiFi management of Circle with Disney. A crafted Access Point with the same name as the legitimate one can be used to make Circle connect to an untrusted network. An attacker needs to setup an Access Point reachable by the device and to send a series of spoofed \"deauth\" packets to trigger this vulnerability.",
"id": "GHSA-3qqr-w7gm-52gv",
"modified": "2022-05-13T01:01:40Z",
"published": "2022-05-13T01:01:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2017-12096"
},
{
"type": "WEB",
"url": "https://www.talosintelligence.com/vulnerability_reports/TALOS-2017-0448"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H",
"type": "CVSS_V3"
}
]
}
GHSA-3QXC-7G4V-3GM9
Vulnerability from github – Published: 2026-07-30 18:31 – Updated: 2026-07-31 18:32UserManager lack of checks allows impersonation in Apache JSPWiki up to 2.12.3 which may allow attackers to escalate privileges. Users are recommended to upgrade to version 2.12.4 or newer which fixes this issue.
{
"affected": [],
"aliases": [
"CVE-2026-28812"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2026-07-30T16:17:10Z",
"severity": "CRITICAL"
},
"details": "UserManager lack of checks allows impersonation in Apache JSPWiki up to 2.12.3 which may allow attackers to escalate privileges.\nUsers are recommended to upgrade to version 2.12.4 or newer which fixes this issue.",
"id": "GHSA-3qxc-7g4v-3gm9",
"modified": "2026-07-31T18:32:12Z",
"published": "2026-07-30T18:31:39Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-28812"
},
{
"type": "WEB",
"url": "https://lists.apache.org/thread/n3m666d6t6871dldvz3ct49ooqkbgw2p"
},
{
"type": "WEB",
"url": "http://www.openwall.com/lists/oss-security/2026/07/30/15"
}
],
"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-3R2V-4FP3-8G3H
Vulnerability from github – Published: 2025-08-04 15:31 – Updated: 2025-08-04 15:31Dell PowerProtect Data Domain with Data Domain Operating System (DD OS) of Feature Release versions 7.7.1.0 through 8.3.0.15, LTS2024 release Versions 7.13.1.0 through 7.13.1.25, LTS 2023 release versions 7.10.1.0 through 7.10.1.60, contain an Authentication Bypass by Spoofing vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Protection mechanism bypass. Remote unauthenticated user can create account that potentially expose customer info, affect system integrity and availability.
{
"affected": [],
"aliases": [
"CVE-2025-36594"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2025-08-04T15:15:32Z",
"severity": "CRITICAL"
},
"details": "Dell PowerProtect Data Domain with Data Domain Operating System (DD OS) of Feature Release versions 7.7.1.0 through 8.3.0.15, LTS2024 release Versions 7.13.1.0 through 7.13.1.25, LTS 2023 release versions 7.10.1.0 through 7.10.1.60, contain an Authentication Bypass by Spoofing vulnerability. An unauthenticated attacker with remote access could potentially exploit this vulnerability, leading to Protection mechanism bypass. Remote unauthenticated user can create account that potentially expose customer info, affect system integrity and availability.",
"id": "GHSA-3r2v-4fp3-8g3h",
"modified": "2025-08-04T15:31:23Z",
"published": "2025-08-04T15:31:23Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2025-36594"
},
{
"type": "WEB",
"url": "https://www.dell.com/support/kbdoc/en-us/000348708/dsa-2025-159-security-update-for-dell-powerprotect-data-domain-multiple-vulnerabilities"
}
],
"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-3V83-X3VQ-3MMV
Vulnerability from github – Published: 2022-12-22 21:30 – Updated: 2025-04-16 15:34When exiting fullscreen mode, an iframe could have confused the browser about the current state of fullscreen, resulting in potential user confusion or spoofing attacks. This vulnerability affects Thunderbird < 91.10, Firefox < 101, and Firefox ESR < 91.10.
{
"affected": [],
"aliases": [
"CVE-2022-31738"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-12-22T20:15:00Z",
"severity": "MODERATE"
},
"details": "When exiting fullscreen mode, an iframe could have confused the browser about the current state of fullscreen, resulting in potential user confusion or spoofing attacks. This vulnerability affects Thunderbird \u003c 91.10, Firefox \u003c 101, and Firefox ESR \u003c 91.10.",
"id": "GHSA-3v83-x3vq-3mmv",
"modified": "2025-04-16T15:34:08Z",
"published": "2022-12-22T21:30:29Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-31738"
},
{
"type": "WEB",
"url": "https://bugzilla.mozilla.org/show_bug.cgi?id=1756388"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2022-20"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2022-21"
},
{
"type": "WEB",
"url": "https://www.mozilla.org/security/advisories/mfsa2022-22"
}
],
"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-3VJ8-JMXQ-CGJ5
Vulnerability from github – Published: 2026-03-18 16:18 – Updated: 2026-03-20 21:28H3 NodeRequestUrl bugs
Vulnerable pieces of code :
import { H3, serve, defineHandler, getQuery, getHeaders, readBody, defineNodeHandler } from "h3";
let app = new H3()
const internalOnly = defineHandler((event, next) => {
const token = event.headers.get("x-internal-key");
if (token !== "SUPERRANDOMCANNOTBELEAKED") {
return new Response("Forbidden", { status: 403 });
}
return next();
});
const logger = defineHandler((event, next) => {
console.log("Logging : " + event.url.hostname)
return next()
})
app.use(logger);
app.use("/internal/run", internalOnly);
app.get("/internal/run", () => {
return "Internal OK";
});
serve(app, { port: 3001 });
The middleware is super safe now with just a logger and a middleware to block internal access.
But there's one problems here at the logger .
When it log out the event.url or event.url.hostname or event.url._url
It will lead to trigger one specials method
// _url.mjs FastURL
get _url() {
if (this.#url) return this.#url;
this.#url = new NativeURL(this.href);
this.#href = void 0;
this.#protocol = void 0;
this.#host = void 0;
this.#pathname = void 0;
this.#search = void 0;
this.#searchParams = void 0;
this.#pos = void 0;
return this.#url;
}
The NodeRequestUrl is extends from FastURL so when we just access .url or trying to dump all data of this class . This function will be triggered !!
And as debugging , the this.#url is null and will reach to this code :
this.#url = new NativeURL(this.href);
Where is the this.href comes from ?
get href() {
if (this.#url) return this.#url.href;
if (!this.#href) this.#href = `${this.#protocol || "http:"}//${this.#host || "localhost"}${this.#pathname || "/"}${this.#search || ""}`;
return this.#href;
}
Because the this.#url is still null so this.#href is built up by :
if (!this.#href) this.#href = `${this.#protocol || "http:"}//${this.#host || "localhost"}${this.#pathname || "/"}${this.#search || ""}`;
Yeah and this is untrusted data go . An attacker can pollute the Host header from requests lead overwrite the event.url .
Middleware bypass
What can be done with overwriting the event.url?
Audit the code we can easily realize that the routeHanlder is found before running any middlewares
handler(event) {
const route = this["~findRoute"](event);
if (route) {
event.context.params = route.params;
event.context.matchedRoute = route.data;
}
const routeHandler = route?.data.handler || NoHandler;
const middleware = this["~getMiddleware"](event, route);
return middleware.length > 0 ? callMiddleware(event, middleware, routeHandler) : routeHandler(event);
}
So the handleRoute is fixed but when checking with middleware it check with the spoofed one lead to MIDDLEWARE BYPASS
We have this poc :
import requests
url = "http://localhost:3000"
headers = {
"Host":f"localhost:3000/abchehe?"
}
res = requests.get(f"{url}/internal/run",headers=headers)
print(res.text)
This is really dangerous if some one just try to dump all the event.url or something that trigger _url() from class FastURL and need a fix immediately.
{
"affected": [
{
"package": {
"ecosystem": "npm",
"name": "h3"
},
"ranges": [
{
"events": [
{
"introduced": "2.0.0-0"
},
{
"fixed": "2.0.1-rc.15"
}
],
"type": "ECOSYSTEM"
}
]
}
],
"aliases": [
"CVE-2026-33131"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": true,
"github_reviewed_at": "2026-03-18T16:18:12Z",
"nvd_published_at": "2026-03-20T11:18:02Z",
"severity": "HIGH"
},
"details": "# H3 NodeRequestUrl bugs \n\nVulnerable pieces of code : \n```js\nimport { H3, serve, defineHandler, getQuery, getHeaders, readBody, defineNodeHandler } from \"h3\";\nlet app = new H3()\n\nconst internalOnly = defineHandler((event, next) =\u003e {\n const token = event.headers.get(\"x-internal-key\");\n\n if (token !== \"SUPERRANDOMCANNOTBELEAKED\") {\n return new Response(\"Forbidden\", { status: 403 });\n }\n\n return next();\n});\nconst logger = defineHandler((event, next) =\u003e {\n console.log(\"Logging : \" + event.url.hostname)\n return next() \n})\napp.use(logger);\napp.use(\"/internal/run\", internalOnly);\n\n\napp.get(\"/internal/run\", () =\u003e {\n return \"Internal OK\";\n});\n\nserve(app, { port: 3001 });\n```\n\nThe middleware is super safe now with just a logger and a middleware to block internal access.\nBut there\u0027s one problems here at the logger .\nWhen it log out the ```event.url``` or ```event.url.hostname``` or ```event.url._url```\n\nIt will lead to trigger one specials method \n\n```js \n// _url.mjs FastURL\nget _url() {\n if (this.#url) return this.#url;\n this.#url = new NativeURL(this.href);\n this.#href = void 0;\n this.#protocol = void 0;\n this.#host = void 0;\n this.#pathname = void 0;\n this.#search = void 0;\n this.#searchParams = void 0;\n this.#pos = void 0;\n return this.#url;\n}\n```\n\nThe `NodeRequestUrl` is extends from `FastURL` so when we just access ```.url``` or trying to dump all data of this class . This function will be triggered !! \n\nAnd as debugging , the `this.#url` is null and will reach to this code : \n```js\n this.#url = new NativeURL(this.href);\n```\nWhere is the `this.href` comes from ? \n```js \nget href() {\n if (this.#url) return this.#url.href;\n if (!this.#href) this.#href = `${this.#protocol || \"http:\"}//${this.#host || \"localhost\"}${this.#pathname || \"/\"}${this.#search || \"\"}`;\n return this.#href;\n}\n```\nBecause the `this.#url` is still null so `this.#href` is built up by : \n```js\nif (!this.#href) this.#href = `${this.#protocol || \"http:\"}//${this.#host || \"localhost\"}${this.#pathname || \"/\"}${this.#search || \"\"}`;\n```\nYeah and this is untrusted data go . An attacker can pollute the `Host` header from requests lead overwrite the `event.url` .\n\n# Middleware bypass\nWhat can be done with overwriting the `event.url`? \nAudit the code we can easily realize that the `routeHanlder` is found before running any middlewares \n```js\nhandler(event) {\n const route = this[\"~findRoute\"](event);\n if (route) {\n event.context.params = route.params;\n event.context.matchedRoute = route.data;\n }\n const routeHandler = route?.data.handler || NoHandler;\n const middleware = this[\"~getMiddleware\"](event, route);\n return middleware.length \u003e 0 ? callMiddleware(event, middleware, routeHandler) : routeHandler(event);\n}\n```\n\nSo the handleRoute is fixed but when checking with middleware it check with the **spoofed** one lead to **MIDDLEWARE BYPASS**\n\nWe have this poc : \n```py\nimport requests\nurl = \"http://localhost:3000\"\nheaders = {\n \"Host\":f\"localhost:3000/abchehe?\"\n}\nres = requests.get(f\"{url}/internal/run\",headers=headers)\nprint(res.text)\n```\n\nThis is really dangerous if some one just try to dump all the `event.url` or something that trigger `_url()` from class FastURL and need a fix immediately.",
"id": "GHSA-3vj8-jmxq-cgj5",
"modified": "2026-03-20T21:28:00Z",
"published": "2026-03-18T16:18:12Z",
"references": [
{
"type": "WEB",
"url": "https://github.com/h3js/h3/security/advisories/GHSA-3vj8-jmxq-cgj5"
},
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33131"
},
{
"type": "PACKAGE",
"url": "https://github.com/h3js/h3"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:H/I:H/A:N",
"type": "CVSS_V3"
}
],
"summary": "h3 has a middleware bypass with one gadget"
}
GHSA-3VQ5-H8QX-C7QM
Vulnerability from github – Published: 2022-11-04 12:00 – Updated: 2022-11-04 19:01"IBM WebSphere Application Server 7.0, 8.0, 8.5, and 9.0 Web services could allow a man-in-the-middle attacker to conduct SOAPAction spoofing to execute unwanted or unauthorized operations. IBM X-Force ID: 234762."
{
"affected": [],
"aliases": [
"CVE-2022-38712"
],
"database_specific": {
"cwe_ids": [
"CWE-290"
],
"github_reviewed": false,
"github_reviewed_at": null,
"nvd_published_at": "2022-11-03T20:15:00Z",
"severity": "MODERATE"
},
"details": "\"IBM WebSphere Application Server 7.0, 8.0, 8.5, and 9.0 Web services could allow a man-in-the-middle attacker to conduct SOAPAction spoofing to execute unwanted or unauthorized operations. IBM X-Force ID: 234762.\"",
"id": "GHSA-3vq5-h8qx-c7qm",
"modified": "2022-11-04T19:01:16Z",
"published": "2022-11-04T12:00:25Z",
"references": [
{
"type": "ADVISORY",
"url": "https://nvd.nist.gov/vuln/detail/CVE-2022-38712"
},
{
"type": "WEB",
"url": "https://www.ibm.com/support/pages/node/6829907"
}
],
"schema_version": "1.4.0",
"severity": [
{
"score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
"type": "CVSS_V3"
}
]
}
No mitigation information available for this CWE.
CAPEC-21: Exploitation of Trusted Identifiers
An adversary guesses, obtains, or "rides" a trusted identifier (e.g. session ID, resource ID, cookie, etc.) to perform authorized actions under the guise of an authenticated user or service.
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-459: Creating a Rogue Certification Authority Certificate
An adversary exploits a weakness resulting from using a hashing algorithm with weak collision resistance to generate certificate signing requests (CSR) that contain collision blocks in their "to be signed" parts. The adversary submits one CSR to be signed by a trusted certificate authority then uses the signed blob to make a second certificate appear signed by said certificate authority. Due to the hash collision, both certificates, though different, hash to the same value and so the signed blob works just as well in the second certificate. The net effect is that the adversary's second X.509 certificate, which the Certification Authority has never seen, is now signed and validated by that Certification Authority.
CAPEC-461: Web Services API Signature Forgery Leveraging Hash Function Extension Weakness
An adversary utilizes a hash function extension/padding weakness, to modify the parameters passed to the web service requesting authentication by generating their own call in order to generate a legitimate signature hash (as described in the notes), without knowledge of the secret token sometimes provided by the web service.
CAPEC-473: Signature Spoof
An attacker generates a message or datablock that causes the recipient to believe that the message or datablock was generated and cryptographically signed by an authoritative or reputable source, misleading a victim or victim operating system into performing malicious actions.
CAPEC-476: Signature Spoofing by Misrepresentation
An attacker exploits a weakness in the parsing or display code of the recipient software to generate a data blob containing a supposedly valid signature, but the signer's identity is falsely represented, which can lead to the attacker manipulating the recipient software or its victim user to perform compromising actions.
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-60: Reusing Session IDs (aka Session Replay)
This attack targets the reuse of valid session ID to spoof the target system in order to gain privileges. The attacker tries to reuse a stolen session ID used previously during a transaction to perform spoofing and session hijacking. Another name for this type of attack is Session Replay.
CAPEC-667: Bluetooth Impersonation AttackS (BIAS)
An adversary disguises the MAC address of their Bluetooth enabled device to one for which there exists an active and trusted connection and authenticates successfully. The adversary can then perform malicious actions on the target Bluetooth device depending on the target’s capabilities.
CAPEC-94: Adversary in the Middle (AiTM)
An adversary targets the communication between two components (typically client and server), in order to alter or obtain data from transactions. A general approach entails the adversary placing themself within the communication channel between the two components.