The MCP Registry provides MCP clients with a list of MCP servers, like an app store for MCP servers. Prior to 1.7.6, the client-side and server-side GitHub OIDC flow is bound only to a global audience string, not to the specific registry instance being targeted. On the client side, the publisher always appends audience=mcp-registry when requesting the GitHub Actions ID token, regardless of the selected --registry URL. On the server side, the exchange endpoint validates only that same fixed audience and then derives publish permissions directly from repository_owner. As a result, a token legitimately obtained while interacting with one registry deployment remains acceptable to any other deployment that shares the same code and audience string. This vulnerability is fixed in 1.7.6.

The MCP Registry provides MCP clients with a list of MCP servers, like an app store for MCP servers. Prior to 1.7.7, the Registry's HTTP-based namespace verification (POST /v0/auth/http, POST /v0.1/auth/http) uses safeDialContext (internal/api/handlers/v0/auth/http.go:67-110) to refuse dialling private/internal addresses when fetching the well-known public-key file from a publisher-supplied domain. The blocklist (isBlockedIP, lines 125-133) relies entirely on Go stdlib's IsLoopback / IsPrivate / IsLinkLocalUnicast / IsMulticast / IsUnspecified plus a manual CGNAT range. None of these cover IPv6 6to4 (2002::/16), NAT64 (64:ff9b::/96 and 64:ff9b:1::/48 per RFC 8215), or deprecated site-local (fec0::/10) — all of which encode arbitrary IPv4 in the address bits and tunnel to RFC1918 / cloud-metadata services on dual-stack / NAT64-enabled hosts. This vulnerability is fixed in 1.7.7.

A malicious user could use this issue to access internal HTTP(s) servers and in the worst case (ie: aws instance) it could be abuse to get a remote code execution on the victim machine.

Plane is an open-source project management tool. Plane uses the ** wildcard support to retrieve the image from any hostname as in /web/next.config.js. This may permit an attacker to induce the server side into performing requests to unintended locations. This vulnerability is fixed in 0.23.0.

OpenClaw versions prior to 2026.2.14 contain a server-side request forgery vulnerability in the optional Tlon Urbit extension that accepts user-provided base URLs for authentication without proper validation. Attackers who can influence the configured Urbit URL can induce the gateway to make HTTP requests to arbitrary hosts including internal addresses.

DoraCMS version 3.1 and prior contains a server-side request forgery (SSRF) vulnerability in its UEditor remote image fetch functionality. The application accepts user-supplied URLs and performs server-side HTTP or HTTPS requests without sufficient validation or destination restrictions. The implementation does not enforce allowlists, block internal or private IP address ranges, or apply request timeouts or response size limits. An attacker can abuse this behavior to induce the server to issue outbound requests to arbitrary hosts, including internal network resources, potentially enabling internal network scanning and denial of service through resource exhaustion.

PinchTab is a standalone HTTP server that gives AI agents direct control over a Chrome browser. Versions 0.8.2 and below have a Blind SSRF vulnerability in the /download endpoint. The validateDownloadURL() function only checks the initial user-supplied URL, but the embedded Chromium browser can follow attacker-controlled redirects/navigations to internal network addresses after validation. Exploitation requires security.allowDownload=true (disabled by default), limiting real-world impact. An attacker-controlled page can use JavaScript redirects or resource requests to make the browser reach internal services from the PinchTab host, resulting in a blind Server-Side Request Forgery (SSRF) condition against internal-only services. The issue has been patched in version 0.8.3.

A vulnerability in the web-based management interface of Cisco Unified Intelligence Center could allow an unauthenticated, remote attacker to conduct a server-side request forgery (SSRF) attack through an affected device. This vulnerability is due to improper input validation for specific HTTP requests. An attacker could exploit this vulnerability by sending a crafted HTTP request to an affected device. A successful exploit could allow the attacker to send arbitrary network requests that are sourced from the affected device.

Server-Side Request Forgery in Canvas LMS 2020-07-29 allows a remote, unauthenticated attacker to cause the Canvas application to perform HTTP GET requests to arbitrary domains.

Akamai CloudTest before 60 2025.06.09 (12989) allows SSRF.