Common Weakness Enumeration

CWE-918

Allowed

Server-Side Request Forgery (SSRF)

Abstraction: Base · Status: Incomplete

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-9Q54-PG8P-25CG

Vulnerability from github – Published: 2024-03-28 06:30 – Updated: 2025-03-25 21:31
VLAI
Details

The Pz-LinkCard WordPress plugin through 2.5.1 does not prevent users from pinging arbitrary hosts via some of its shortcodes, which could allow high privilege users such as contributors to perform SSRF attacks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-0677"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-03-28T05:15:49Z",
    "severity": "MODERATE"
  },
  "details": "The Pz-LinkCard WordPress plugin through 2.5.1 does not prevent users from pinging arbitrary hosts via some of its shortcodes, which could allow high privilege users such as contributors to perform SSRF attacks.",
  "id": "GHSA-9q54-pg8p-25cg",
  "modified": "2025-03-25T21:31:29Z",
  "published": "2024-03-28T06:30:45Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-0677"
    },
    {
      "type": "WEB",
      "url": "https://wpscan.com/vulnerability/0f7757c9-69fa-49db-90b0-40f0ff29bee7"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:L/AC:L/PR:H/UI:N/S:U/C:L/I:H/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9Q7V-8MR7-G23P

Vulnerability from github – Published: 2026-04-02 21:22 – Updated: 2026-04-27 16:46
VLAI
Summary
OpenClaw: SSRF via Unguarded `fetch()` in Marketplace Plugin Download and Ollama Model Discovery
Details

Summary

SSRF via Unguarded fetch() in Marketplace Plugin Download and Ollama Model Discovery

Current Maintainer Triage

  • Status: narrow
  • Normalized severity: medium
  • Assessment: Keep the shipped marketplace archive-fetch SSRF, but narrow out the Ollama half because it is operator-configured and overlaps weaker trust-model or duplicate SSRF ground.

Affected Packages / Versions

  • Package: openclaw (npm)
  • Latest published npm version: 2026.3.31
  • Vulnerable version range: <=2026.3.28
  • Patched versions: >= 2026.3.31
  • First stable tag containing the fix: v2026.3.31

Fix Commit(s)

  • 8deb9522f3d2680820588b190adb4a2a52f3670b — 2026-03-30T20:08:38+01:00

OpenClaw thanks @tdjackey for reporting.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2026.3.28"
      },
      "package": {
        "ecosystem": "npm",
        "name": "openclaw"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "2026.3.31"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-41302"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-04-02T21:22:56Z",
    "nvd_published_at": "2026-04-21T00:16:31Z",
    "severity": "MODERATE"
  },
  "details": "## Summary\nSSRF via Unguarded `fetch()` in Marketplace Plugin Download and Ollama Model Discovery\n\n## Current Maintainer Triage\n- Status: narrow\n- Normalized severity: medium\n- Assessment: Keep the shipped marketplace archive-fetch SSRF, but narrow out the Ollama half because it is operator-configured and overlaps weaker trust-model or duplicate SSRF ground.\n\n## Affected Packages / Versions\n- Package: `openclaw` (npm)\n- Latest published npm version: `2026.3.31`\n- Vulnerable version range: `\u003c=2026.3.28`\n- Patched versions: `\u003e= 2026.3.31`\n- First stable tag containing the fix: `v2026.3.31`\n\n## Fix Commit(s)\n- `8deb9522f3d2680820588b190adb4a2a52f3670b` \u2014 2026-03-30T20:08:38+01:00\n\nOpenClaw thanks @tdjackey for reporting.",
  "id": "GHSA-9q7v-8mr7-g23p",
  "modified": "2026-04-27T16:46:50Z",
  "published": "2026-04-02T21:22:56Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/security/advisories/GHSA-9q7v-8mr7-g23p"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-41302"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/commit/8deb9522f3d2680820588b190adb4a2a52f3670b"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/openclaw/openclaw"
    },
    {
      "type": "WEB",
      "url": "https://github.com/openclaw/openclaw/releases/tag/v2026.3.31"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/openclaw-server-side-request-forgery-via-unguarded-fetch-in-marketplace-plugin-download"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:U/C:H/I:L/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:P/PR:L/UI:P/VC:N/VI:L/VA:N/SC:H/SI:L/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "OpenClaw: SSRF via Unguarded `fetch()` in Marketplace Plugin Download and Ollama Model Discovery"
}

GHSA-9QFV-WGH2-M6P8

Vulnerability from github – Published: 2026-06-19 14:13 – Updated: 2026-06-19 14:13
VLAI
Summary
canto-saas-api: Authenticated API requests can be redirected via unencoded path variables
Details

Summary

In affected versions, Request::buildRequestUrl() inserts path variables into the request URL without URL encoding (implode('/', $pathVariables)). All request classes implementing getPathVariables() are affected, e.g. GetContentDetailsRequest (scheme, contentId).

If a consuming application passes untrusted input (such as an ID taken from an HTTP request parameter) as a path variable, characters like ../, ? or # are sent verbatim and can change the path of the resulting API request.

## Impact

An attacker who controls a path variable value can redirect the library's authenticated request — the Bearer access token is attached in AbstractEndpoint::sendRequest() — to a different API endpoint of the same Canto instance, causing unintended reads or writes with the privileges of the configured app. The impact depends on how the consuming application sources path variable values; applications that only pass trusted, validated IDs are not exploitable.

## Patches

Fixed in 3.0.0: every path segment is encoded with rawurlencode() before being inserted into the request URL.

## Workarounds

If you cannot upgrade, validate untrusted values before passing them to request classes, e.g. enforce an allowlist pattern such as ^[A-Za-z0-9_-]+$ for content IDs and schemes.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 2.0.0"
      },
      "package": {
        "ecosystem": "Packagist",
        "name": "jleehr/canto-saas-api"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "3.0.0"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [
    "CVE-2026-55374"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-74",
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-06-19T14:13:55Z",
    "nvd_published_at": null,
    "severity": "MODERATE"
  },
  "details": "## Summary\n\n  In affected versions, `Request::buildRequestUrl()` inserts path variables into\n  the request URL without URL encoding (`implode(\u0027/\u0027, $pathVariables)`). All\n  request classes implementing `getPathVariables()` are affected, e.g.\n  `GetContentDetailsRequest` (`scheme`, `contentId`).\n\n  If a consuming application passes untrusted input (such as an ID taken from\n  an HTTP request parameter) as a path variable, characters like `../`, `?` or\n  `#` are sent verbatim and can change the path of the resulting API request.\n\n  ## Impact\n\n  An attacker who controls a path variable value can redirect the\n  library\u0027s authenticated request \u2014 the Bearer access token is attached in\n  `AbstractEndpoint::sendRequest()` \u2014 to a different API endpoint of the same\n  Canto instance, causing unintended reads or writes with the privileges of the\n  configured app. The impact depends on how the consuming application sources\n  path variable values; applications that only pass trusted, validated IDs are\n  not exploitable.\n\n  ## Patches\n\n  Fixed in 3.0.0: every path segment is encoded with `rawurlencode()` before\n  being inserted into the request URL.\n\n  ## Workarounds\n\n  If you cannot upgrade, validate untrusted values before passing them to\n  request classes, e.g. enforce an allowlist pattern such as\n  `^[A-Za-z0-9_-]+$` for content IDs and schemes.",
  "id": "GHSA-9qfv-wgh2-m6p8",
  "modified": "2026-06-19T14:13:55Z",
  "published": "2026-06-19T14:13:55Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/jleehr/canto-saas-api/security/advisories/GHSA-9qfv-wgh2-m6p8"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/jleehr/canto-saas-api"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:U/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "canto-saas-api: Authenticated API requests can be redirected via unencoded path variables"
}

GHSA-9QHG-99WW-9MQC

Vulnerability from github – Published: 2026-08-25 15:48 – Updated: 2026-08-25 15:48
VLAI
Summary
utcp-http SSRF: HTTP tool invocation follows redirects without re-validating the target
Details

Summary

HttpCommunicationProtocol.call_tool validates only the pre-redirect tool URL, then issues the request with redirects enabled and never re-checks where it lands. A tool whose endpoint is an attacker-controlled public URL can therefore 302-redirect the UTCP client into an internal service including the cloud metadata endpoint and the response body is returned to the tool caller. This is a working SSRF + internal-data-exfiltration primitive.

This is the redirect invariant of the SSRF class fixed in GHSA-39j6-4867-gg4w; that fix added an invocation-time URL check but left the redirect hop unguarded. This vector bypasses the GHSA-39j6-4867-gg4w mitigation via unvalidated redirects.

Root cause

  1. The resolved URL is validated once, before the request:

https://github.com/universal-tool-calling-protocol/python-utcp/blob/4ed0a48b84a452338bd3e996efb0d169e8d75ac2/plugins/communication_protocols/http/src/utcp_http/http_communication_protocol.py#L281

  1. The request is then made with aiohttp's default allow_redirects=True and no per-hop revalidation, so the redirect target bypasses the check entirely:

https://github.com/universal-tool-calling-protocol/python-utcp/blob/4ed0a48b84a452338bd3e996efb0d169e8d75ac2/plugins/communication_protocols/http/src/utcp_http/http_communication_protocol.py#L313-L332

The validator (_security.py) blocks plain-HTTP to non-loopback hosts, exactly the metadata/internal case, but only the first hop ever reaches it.

Reachability

Triggered whenever the host registers a tool/manual whose endpoint URL is attacker-influenced (e.g. a manual or OpenAPI spec discovered from a runtime-supplied URL: a core UTCP usage pattern) and that tool is then called. The initial URL only has to pass the validator (any https://, or a benign host the attacker controls); the attacker's server supplies the redirect. No special configuration is required.

Preconditions

  • The attacker controls the server the tool points at - either the registered tool/manual endpoint URL is attacker-influenced (e.g. a manual/OpenAPI spec discovered from a runtime-supplied URL), or a legitimate endpoint the tool already points at is attacker-controlled or compromised.
  • The initial tool URL passes ensure_secure_url — trivially met by any https:// URL or a benign attacker-owned host; the attacker only needs to return a 3xx Location.
  • The tool is invoked (call_tool) after registration.
  • An internal HTTP service is reachable from the UTCP process and returns useful data on an unauthenticated GET (cloud metadata, internal admin panel, unauth datastore, link-local endpoint).
  • The tool's return value is surfaced back to the caller/agent (the usual agentic flow), giving the attacker the response body.
  • For the IAM-credential outcome specifically: the host runs on a cloud instance with IMDSv1 enabled. IMDSv2-only hosts block this exact result (it needs a PUT for a session token), but other internal-SSRF targets remain reachable.

PoC

The validator rejects the internal targets directly, but the redirect from an allowed tool URL reaches one anyway and returns its body. Runs the real released HttpCommunicationProtocol; the "metadata" service is bound on a non-loopback LAN IP, which the validator rejects exactly like 169.254.169.254.

Run: pip install utcp-http==1.1.3 aiohttp && python poc.py

import asyncio, socket
from aiohttp import web
from utcp_http.http_communication_protocol import HttpCommunicationProtocol
from utcp_http.http_call_template import HttpCallTemplate

MD = "/latest/meta-data/iam/security-credentials/app-role"
STOLEN = {"Code": "Success", "AccessKeyId": "ASIAEXAMPLESTOLENKEY",
          "SecretAccessKey": "wJalr/EXAMPLE/STOLEN/SECRET", "Token": "Fwo...session"}

def lan_ip():
    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)
    try: s.connect(("8.8.8.8", 80)); return s.getsockname()[0]
    finally: s.close()

async def main():
    internal = lan_ip()
    meta = web.Application(); meta.router.add_get(MD, lambda r: web.json_response(STOLEN))
    mr = web.AppRunner(meta, access_log=None); await mr.setup()
    ms = web.TCPSite(mr, "0.0.0.0", 0); await ms.start()
    internal_url = f"http://{internal}:{ms._server.sockets[0].getsockname()[1]}{MD}"

    atk = web.Application()
    atk.router.add_get("/tool", lambda r: web.Response(status=302, headers={"Location": internal_url}))
    ar = web.AppRunner(atk, access_log=None); await ar.setup()
    as_ = web.TCPSite(ar, "127.0.0.1", 0); await as_.start()
    tool_url = f"http://127.0.0.1:{as_._server.sockets[0].getsockname()[1]}/tool"

    proto = HttpCommunicationProtocol()
    ct = HttpCallTemplate(name="lookup", url=tool_url, http_method="GET")  # passes the validator
    result = await proto.call_tool(None, "lookup", {}, ct)                 # follows 302 -> internal
    print("caller received:", result)
    await ar.cleanup(); await mr.cleanup()

asyncio.run(main())

Output:

caller received: {'Code': 'Success', 'AccessKeyId': 'ASIAEXAMPLESTOLENKEY', 'SecretAccessKey': 'wJalr/EXAMPLE/STOLEN/SECRET', 'Token': 'Fwo...session'}

Impact

Blind-to-readable SSRF from the UTCP host's network position, with the internal response handed back to the caller. On a cloud instance with IMDSv1 this yields the instance role's IAM credentials (as shown), i.e. infrastructure takeover; more generally it reaches internal HTTP services (admin panels, unauth datastores, link-local endpoints) that the validator is specifically meant to block.

Possible fix

Disable automatic redirects for tool invocation (allow_redirects=False) and, if redirects must be supported, re-run ensure_secure_url on every hop's Location before following it. Resolving the host and rejecting private/link-local/loopback IPs (not just plain-HTTP non-loopback) closes the residual https://-to-internal case as well.

Patched

Fixed in utcp-http 1.1.4. _security.py now ships safe_request_with_redirects, a per-hop revalidator that disables aiohttp's auto-follow, runs ensure_secure_url on every Location header before issuing the next hop, caps the chain at 5 hops, and drops the body on 303 per RFC 7231. The HTTP, SSE, and streamable-HTTP plugins use it for both register_manual and call_tool; SSE + streamable handshakes additionally reject any 3xx outright because the streaming response has to stay open for the lifetime of the call. The OAuth2 token-fetch path uses the same helper, closing the redirect-on-token-URL variant.

The sister TypeScript implementation @utcp/http is fixed the same way in 1.1.4.

Upgrade to utcp-http >= 1.1.4. No workaround in earlier versions short of disabling all attacker-influenced manuals.

Show details on source website

{
  "affected": [
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 1.1.3"
      },
      "package": {
        "ecosystem": "PyPI",
        "name": "utcp-http"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0"
            },
            {
              "fixed": "1.1.4"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-08-25T15:48:51Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "## Summary\n\n`HttpCommunicationProtocol.call_tool` validates only the pre-redirect tool URL, then issues the request with redirects enabled and never re-checks where it lands. A tool whose endpoint is an attacker-controlled public URL can therefore `302`-redirect the UTCP client into an internal service including the cloud metadata endpoint and the response body is returned to the tool caller. This is a working SSRF + internal-data-exfiltration primitive.\n\nThis is the redirect invariant of the SSRF class fixed in GHSA-39j6-4867-gg4w; that fix added an invocation-time URL check but left the redirect hop unguarded. This vector bypasses the GHSA-39j6-4867-gg4w mitigation via unvalidated redirects.\n\n## Root cause\n\n1. The resolved URL is validated once, before the request:\n\nhttps://github.com/universal-tool-calling-protocol/python-utcp/blob/4ed0a48b84a452338bd3e996efb0d169e8d75ac2/plugins/communication_protocols/http/src/utcp_http/http_communication_protocol.py#L281\n\n2. The request is then made with aiohttp\u0027s default `allow_redirects=True` and no\n   per-hop revalidation, so the redirect target bypasses the check entirely:\n\nhttps://github.com/universal-tool-calling-protocol/python-utcp/blob/4ed0a48b84a452338bd3e996efb0d169e8d75ac2/plugins/communication_protocols/http/src/utcp_http/http_communication_protocol.py#L313-L332\n\nThe validator (`_security.py`) blocks plain-HTTP to non-loopback hosts, exactly the metadata/internal case, but only the first hop ever reaches it.\n\n## Reachability\n\nTriggered whenever the host registers a tool/manual whose endpoint URL is attacker-influenced (e.g. a manual or OpenAPI spec discovered from a runtime-supplied URL: a core UTCP usage pattern) and that tool is then called. The initial URL only has to pass the validator (any `https://`, or a benign host the attacker controls); the attacker\u0027s server supplies the redirect. No special configuration is required.\n\n## Preconditions\n\n- The attacker controls the server the tool points at - either the registered tool/manual endpoint URL is attacker-influenced (e.g. a manual/OpenAPI spec discovered from a runtime-supplied URL), or a legitimate endpoint the tool already points at is attacker-controlled or compromised.\n- The initial tool URL passes `ensure_secure_url` \u00e2\u20ac\u201d trivially met by any `https://` URL or a benign attacker-owned host; the attacker only needs to return a `3xx` `Location`.\n- The tool is invoked (`call_tool`) after registration.\n- An internal HTTP service is reachable from the UTCP process and returns useful data on an unauthenticated `GET` (cloud metadata, internal admin panel, unauth datastore, link-local endpoint).\n- The tool\u0027s return value is surfaced back to the caller/agent (the usual agentic flow), giving the attacker the response body.\n- For the IAM-credential outcome specifically: the host runs on a cloud instance with **IMDSv1** enabled. IMDSv2-only hosts block this exact result (it needs a `PUT` for a session token), but other internal-SSRF targets remain reachable.\n\n## PoC\n\nThe validator rejects the internal targets directly, but the redirect from an allowed tool URL reaches one anyway and returns its body. Runs the real released `HttpCommunicationProtocol`; the \"metadata\" service is bound on a non-loopback LAN IP, which the validator rejects exactly like `169.254.169.254`.\n\nRun: `pip install utcp-http==1.1.3 aiohttp \u0026\u0026 python poc.py`\n\n```python\nimport asyncio, socket\nfrom aiohttp import web\nfrom utcp_http.http_communication_protocol import HttpCommunicationProtocol\nfrom utcp_http.http_call_template import HttpCallTemplate\n\nMD = \"/latest/meta-data/iam/security-credentials/app-role\"\nSTOLEN = {\"Code\": \"Success\", \"AccessKeyId\": \"ASIAEXAMPLESTOLENKEY\",\n          \"SecretAccessKey\": \"wJalr/EXAMPLE/STOLEN/SECRET\", \"Token\": \"Fwo...session\"}\n\ndef lan_ip():\n    s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM)\n    try: s.connect((\"8.8.8.8\", 80)); return s.getsockname()[0]\n    finally: s.close()\n\nasync def main():\n    internal = lan_ip()\n    meta = web.Application(); meta.router.add_get(MD, lambda r: web.json_response(STOLEN))\n    mr = web.AppRunner(meta, access_log=None); await mr.setup()\n    ms = web.TCPSite(mr, \"0.0.0.0\", 0); await ms.start()\n    internal_url = f\"http://{internal}:{ms._server.sockets[0].getsockname()[1]}{MD}\"\n\n    atk = web.Application()\n    atk.router.add_get(\"/tool\", lambda r: web.Response(status=302, headers={\"Location\": internal_url}))\n    ar = web.AppRunner(atk, access_log=None); await ar.setup()\n    as_ = web.TCPSite(ar, \"127.0.0.1\", 0); await as_.start()\n    tool_url = f\"http://127.0.0.1:{as_._server.sockets[0].getsockname()[1]}/tool\"\n\n    proto = HttpCommunicationProtocol()\n    ct = HttpCallTemplate(name=\"lookup\", url=tool_url, http_method=\"GET\")  # passes the validator\n    result = await proto.call_tool(None, \"lookup\", {}, ct)                 # follows 302 -\u003e internal\n    print(\"caller received:\", result)\n    await ar.cleanup(); await mr.cleanup()\n\nasyncio.run(main())\n```\n\nOutput:\n\n```\ncaller received: {\u0027Code\u0027: \u0027Success\u0027, \u0027AccessKeyId\u0027: \u0027ASIAEXAMPLESTOLENKEY\u0027, \u0027SecretAccessKey\u0027: \u0027wJalr/EXAMPLE/STOLEN/SECRET\u0027, \u0027Token\u0027: \u0027Fwo...session\u0027}\n```\n\n## Impact\n\nBlind-to-readable SSRF from the UTCP host\u0027s network position, with the internal response handed back to the caller. On a cloud instance with IMDSv1 this yields the instance role\u0027s IAM credentials (as shown), i.e. infrastructure takeover; more generally it reaches internal HTTP services (admin panels, unauth datastores, link-local endpoints) that the validator is specifically meant to block.\n\n## Possible fix\n\nDisable automatic redirects for tool invocation (`allow_redirects=False`) and, if redirects must be supported, re-run `ensure_secure_url` on every hop\u0027s `Location` before following it. Resolving the host and rejecting private/link-local/loopback IPs (not just plain-HTTP non-loopback) closes the residual `https://`-to-internal case as well.\n\n## Patched\n\nFixed in `utcp-http` 1.1.4. `_security.py` now ships\n`safe_request_with_redirects`, a per-hop revalidator that disables\naiohttp\u0027s auto-follow, runs `ensure_secure_url` on every `Location`\nheader before issuing the next hop, caps the chain at 5 hops, and drops\nthe body on 303 per RFC 7231. The HTTP, SSE, and streamable-HTTP\nplugins use it for both `register_manual` and `call_tool`; SSE +\nstreamable handshakes additionally reject any 3xx outright because the\nstreaming response has to stay open for the lifetime of the call. The\nOAuth2 token-fetch path uses the same helper, closing the\nredirect-on-token-URL variant.\n\nThe sister TypeScript implementation `@utcp/http` is fixed the same way\nin 1.1.4.\n\nUpgrade to `utcp-http \u003e= 1.1.4`. No workaround in earlier versions\nshort of disabling all attacker-influenced manuals.",
  "id": "GHSA-9qhg-99ww-9mqc",
  "modified": "2026-08-25T15:48:51Z",
  "published": "2026-08-25T15:48:51Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/universal-tool-calling-protocol/python-utcp/security/advisories/GHSA-9qhg-99ww-9mqc"
    },
    {
      "type": "WEB",
      "url": "https://github.com/universal-tool-calling-protocol/python-utcp/commit/fc3268e2a62e1181f91a63faf0a9bcee7639db29"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/universal-tool-calling-protocol/python-utcp"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:N/UI:R/S:C/C:H/I:L/A:N",
      "type": "CVSS_V3"
    }
  ],
  "summary": "utcp-http SSRF: HTTP tool invocation follows redirects without re-validating the target"
}

GHSA-9QPF-Q9V6-4Q5C

Vulnerability from github – Published: 2025-03-29 00:31 – Updated: 2025-03-31 18:31
VLAI
Details

OneNav 1.1.0 is vulnerable to Server-Side Request Forgery (SSRF) in custom headers.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-28096"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-03-28T22:15:18Z",
    "severity": "MODERATE"
  },
  "details": "OneNav 1.1.0 is vulnerable to Server-Side Request Forgery (SSRF) in custom headers.",
  "id": "GHSA-9qpf-q9v6-4q5c",
  "modified": "2025-03-31T18:31:07Z",
  "published": "2025-03-29T00:31:35Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-28096"
    },
    {
      "type": "WEB",
      "url": "https://www.yuque.com/morysummer/vx41bz/oqi6pyv26gci6465"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:R/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9QWV-3X3P-RG99

Vulnerability from github – Published: 2025-05-02 03:30 – Updated: 2025-05-02 03:30
VLAI
Details

IBM Concert Software 1.0.0 through 1.0.5 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-55910"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-05-02T01:15:53Z",
    "severity": "MODERATE"
  },
  "details": "IBM Concert Software 1.0.0 through 1.0.5 is vulnerable to server-side request forgery (SSRF). This may allow an authenticated attacker to send unauthorized requests from the system, potentially leading to network enumeration or facilitating other attacks.",
  "id": "GHSA-9qwv-3x3p-rg99",
  "modified": "2025-05-02T03:30:34Z",
  "published": "2025-05-02T03:30:34Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-55910"
    },
    {
      "type": "WEB",
      "url": "https://www.ibm.com/support/pages/node/7232169"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9R7R-J892-2C6M

Vulnerability from github – Published: 2026-07-20 21:31 – Updated: 2026-09-14 21:31
VLAI
Details

Huginn through 2022.08.18 contains a server-side request forgery vulnerability in the fetch_url method of ScenarioImport that allows authenticated users to make arbitrary HTTP requests by submitting crafted URLs. Attackers can probe internal network services, enumerate ports via error signatures, and access cloud metadata endpoints to retrieve sensitive credentials.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2026-63769"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2026-07-20T19:17:29Z",
    "severity": "MODERATE"
  },
  "details": "Huginn through 2022.08.18 contains a server-side request forgery vulnerability in the fetch_url method of ScenarioImport that allows authenticated users to make arbitrary HTTP requests by submitting crafted URLs. Attackers can probe internal network services, enumerate ports via error signatures, and access cloud metadata endpoints to retrieve sensitive credentials.",
  "id": "GHSA-9r7r-j892-2c6m",
  "modified": "2026-09-14T21:31:16Z",
  "published": "2026-07-20T21:31:49Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/huginn/huginn/security/advisories/GHSA-f7cq-gj98-cfjp"
    },
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2026-63769"
    },
    {
      "type": "WEB",
      "url": "https://github.com/huginn/huginn/issues/3679"
    },
    {
      "type": "WEB",
      "url": "https://github.com/huginn/huginn/pull/3684"
    },
    {
      "type": "WEB",
      "url": "https://github.com/huginn/huginn/releases/tag/v2026.09.09"
    },
    {
      "type": "WEB",
      "url": "https://www.vulncheck.com/advisories/huginn-ssrf-via-scenarioimport-fetch-url-method"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:C/C:H/I:N/A:N",
      "type": "CVSS_V3"
    },
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:L/UI:N/VC:N/VI:N/VA:N/SC:H/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-9RGF-3X56-49QR

Vulnerability from github – Published: 2023-11-22 15:31 – Updated: 2023-11-28 00:30
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in Darren Cooney Instant Images plugin <= 5.1.0.2 versions.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2023-27451"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2023-11-22T14:15:08Z",
    "severity": "HIGH"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in Darren Cooney Instant Images plugin \u003c=\u00a05.1.0.2 versions.",
  "id": "GHSA-9rgf-3x56-49qr",
  "modified": "2023-11-28T00:30:32Z",
  "published": "2023-11-22T15:31:29Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2023-27451"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/vulnerability/instant-images/wordpress-instant-images-5-1-0-1-auth-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:L/PR:H/UI:N/S:U/C:H/I:H/A:H",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9RH2-63C5-4G3X

Vulnerability from github – Published: 2025-04-24 18:31 – Updated: 2026-04-01 18:34
VLAI
Details

Server-Side Request Forgery (SSRF) vulnerability in josheli Simple Google Photos Grid allows Server Side Request Forgery. This issue affects Simple Google Photos Grid: from n/a through 1.5.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2025-46503"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2025-04-24T16:15:41Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery (SSRF) vulnerability in josheli Simple Google Photos Grid allows Server Side Request Forgery. This issue affects Simple Google Photos Grid: from n/a through 1.5.",
  "id": "GHSA-9rh2-63c5-4g3x",
  "modified": "2026-04-01T18:34:58Z",
  "published": "2025-04-24T18:31:07Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2025-46503"
    },
    {
      "type": "WEB",
      "url": "https://patchstack.com/database/wordpress/plugin/simple-google-photos-grid/vulnerability/wordpress-simple-google-photos-grid-1-5-server-side-request-forgery-ssrf-vulnerability?_s_id=cve"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:3.1/AV:N/AC:H/PR:L/UI:N/S:C/C:L/I:L/A:N",
      "type": "CVSS_V3"
    }
  ]
}

GHSA-9RJ9-V7HH-CG8Q

Vulnerability from github – Published: 2024-02-28 15:30 – Updated: 2024-02-28 15:30
VLAI
Details

Server-Side Request Forgery vulnerability in Haivision's Aviwest Manager and Aviwest Steamhub. This vulnerability could allow an attacker to enumerate internal network configuration without the need for credentials. An attacker could compromise an internal server and retrieve requests sent by other users.

Show details on source website

{
  "affected": [],
  "aliases": [
    "CVE-2024-1965"
  ],
  "database_specific": {
    "cwe_ids": [
      "CWE-918"
    ],
    "github_reviewed": false,
    "github_reviewed_at": null,
    "nvd_published_at": "2024-02-28T13:15:07Z",
    "severity": "MODERATE"
  },
  "details": "Server-Side Request Forgery vulnerability in Haivision\u0027s Aviwest Manager and Aviwest Steamhub. This vulnerability could allow an attacker to enumerate internal network configuration without the need for credentials. An attacker could compromise an internal server and retrieve requests sent by other users.",
  "id": "GHSA-9rj9-v7hh-cg8q",
  "modified": "2024-02-28T15:30:56Z",
  "published": "2024-02-28T15:30:56Z",
  "references": [
    {
      "type": "ADVISORY",
      "url": "https://nvd.nist.gov/vuln/detail/CVE-2024-1965"
    },
    {
      "type": "WEB",
      "url": "https://www.incibe.es/en/incibe-cert/notices/aviso/server-side-request-forgery-vulnerability-haivision-products"
    }
  ],
  "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:N",
      "type": "CVSS_V3"
    }
  ]
}

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.