Threat Library

IBM's ContextForge MCP Gateway contains a server-side request forgery (SSRF) flaw exploitable via DNS rebinding, allowing an authenticated attacker to trick the gateway into making requests to internal or restricted resources. This could expose sensitive internal network data, credentials, or metadata endpoints reachable only from the gateway's network position. Exploitation requires authentication but no user interaction, making it a meaningful risk for exposed MCP gateway deployments.

The OGX (formerly Llama Stack) server has an unauthenticated SSRF flaw in its MCP tool-definition handling: the server_url parameter passed to the /v1/responses endpoint is fetched server-side without the same private-address validation applied to other URLs. On default (no-auth) deployments, a remote attacker can force the server to reach internal hosts and cloud metadata services, potentially exfiltrating attacker-supplied headers/tokens or leaking cloud credentials.

MCPHub, a centralized management hub for MCP servers, has an incomplete SSRF guard that fails to block IPv6 transition addresses like NAT64, 6to4, and Teredo. An attacker who can supply a URL for an MCP server connection can embed a private IPv4 address inside one of these IPv6 formats to bypass the filter and reach internal infrastructure. This is a classic SSRF filter evasion issue, patched in version 1.0.32.

MCPHub, a management hub for MCP servers, allows any authenticated non-admin user to register a malicious MCP server pointing at arbitrary internal or external URLs, causing the hub to make server-side requests without egress filtering. This enables both reflected SSRF (attacker sees response data via the OpenAPI proxy) and blind SSRF (via SSE/streamable-http transport), potentially exposing internal services, cloud metadata endpoints, and loopback/RFC1918 resources.

The ash_ai library's MCP server implementation has a flawed origin validation check that can be bypassed using DNS rebinding, allowing a malicious website to issue cross-site requests to a user's locally running MCP server as that user's authenticated actor. Both values used in the trust decision (Host header and X-Forwarded-Proto header) are attacker-controlled from the browser, making the check ineffective by default. This affects versions 0.8.0 through before 1.0.0 and is fixed by defaulting to trusting only localhost origins.

pg-aiguide's MCP HTTP transport failed to enable a built-in DNS-rebinding protection option, allowing a malicious webpage to rebind a domain to the local server's address and issue unauthorized requests to the locally running MCP server via a victim's browser. This effectively bypasses the localhost trust boundary that MCP servers typically rely on for security. The issue was a configuration oversight rather than a missing SDK feature, and is fixed in version 0.5.1 by explicitly enabling the allow-list.

The mcp-use inspector's proxy middleware forwarded requests to any target supplied by the caller via a header or parameter, without validating whether that address pointed to internal, loopback, or link-local infrastructure. This allowed an attacker to force the server to make requests on its behalf to internal-only services and read the responses, a classic SSRF pattern applied to an MCP tooling component. The issue has been fixed by introducing host validation and redirect-following limits.

A vulnerability in GitLab's AI Gateway allowed an authenticated user with Duo Agent Platform access to redirect the AI Gateway's outbound model requests to an attacker-controlled endpoint by crafting a malicious inline flow configuration that overrides the HTTP Host header. This SSRF-style redirection could leak sensitive Google Cloud Vertex service credentials and private signing keys to the attacker's server, representing a serious confidentiality breach in the agent's model-calling infrastructure.

This is an academic security analysis (not an active exploit) of Google's Agent Payments Protocol v0.2, which is used by LLM-driven shopping agents to authorize payments. The researchers show that while signed Checkout and Payment Mandates protect transaction integrity after signing, the A2A and MCP interactions that shape the transaction beforehand are unprotected, enabling an agent to be manipulated into signing a mandate that does not reflect the user's true intent. The paper identifies 48 catalogued threats across five attack families, with eight rated High severity, and provides proof-of-concept demonstrations plus a deployment-aware scanner.

The genieacs-mcp MCP server, prior to version 0.3.2, exposes an unauthenticated HTTP listener on localhost by default and fails to validate Host/Origin headers, making it vulnerable to DNS rebinding attacks from malicious websites. An attacker who lures a victim to a malicious webpage can pivot through the victim's browser into the local MCP server and issue commands against the GenieACS TR-069 ACS backend, potentially rebooting devices, altering firmware tasks, or changing CPE configuration. This is a genuine, well-documented vulnerability with a clear exploitation path and meaningful impact on managed device fleets.

PraisonAI's local MCP HTTP Stream server uses a flawed startswith() check to validate the HTTP Origin header, allowing an attacker-controlled domain like 'localhost.evil.example' to pass as if it were 'localhost'. A malicious webpage visited by a victim can exploit this to send unauthenticated tools/call requests directly to the victim's local MCP server, invoking any exposed tool without an API key.

An MCP server component (mcp-rdf-explorer 1.0.0) contains a server-side request forgery vulnerability in its explore_url tool function, allowing a remote attacker to make the server issue arbitrary HTTP requests by manipulating the url argument. A public exploit exists and the vendor has not responded to disclosure, leaving the issue unpatched.

Researchers found that encrypted chain-of-thought blocks returned by major LLM providers (Anthropic, OpenAI, Google) are interchangeable across sessions, users, and models within the same provider, allowing a weaker model to be tricked into decrypting and outputting another model's private reasoning in plaintext. This enables extraction of proprietary reasoning, recovery of PII/credentials from publicly shared session logs, exposure of hazardous content hidden in reasoning, and invisible prompt injection into agentic pipelines. This is a genuine, disclosed architectural vulnerability with demonstrated real-world impact.

IBM Langflow's implementation of the MCP resources/read request fails to sanitize file paths, allowing an attacker to use URL-encoded path traversal sequences to read arbitrary files on the server. This exposes sensitive data including other users' uploaded documents, the JWT signing secret, the SQLite database, and environment variables, which could enable full account takeover or further compromise.

IBM Langflow versions 1.0.0 through 1.10.3 have an authentication bypass in the MCP composer endpoint that occurs when the default setting mcp_composer_enabled=true is combined with OAuth-based project authentication. This allows an attacker to circumvent intended access controls on MCP composer functionality, potentially gaining unauthorized access to project resources or agent workflows.

This is a large-scale academic security assessment (not an active exploit report) finding that thousands of publicly reachable Model Context Protocol (MCP) servers are deployed with weak or absent security controls. Researchers found high rates of missing authentication, exposed shell execution tools, SSRF against cloud metadata endpoints, SQL injection, and prompt template injection across hundreds of confirmed production servers. The findings represent systemic ecosystem-wide risk rather than a single vulnerability in one product.

better-auth's OIDC provider and MCP plugin fail to validate the URI scheme of registered OAuth redirect_uris, allowing an attacker to register a javascript: URI that gets echoed back to the consent page. If the consent UI navigates to this URI unsafely, attacker JavaScript executes in the authorization server's origin, potentially hijacking victim sessions. This is a classic web input-validation flaw made newly relevant because it affects the auth layer underlying MCP server deployments, extending its blast radius to agent tool-authorization flows.

The MCP Ruby SDK's StreamableHTTP transport failed to bind session IDs to the client/owner that created them, so anyone who obtains a valid session ID (via theft, leakage in logs/URLs, or interception) could issue tools/call requests that execute with the victim's authenticated session context. This allows an attacker to impersonate a legitimate user or agent and trigger tool actions on their behalf without needing credentials.

The MCP Ruby SDK's HTTP transport failed to validate Host or Origin headers before version 0.23.0, allowing a malicious website to use DNS rebinding to reach a locally running MCP server from a victim's browser. This lets an attacker invoke tools exposed by the local MCP server without authorization, effectively bypassing the same-origin trust boundary that localhost services normally rely on.

Network-AI's MCP SSE server ships with an empty default authentication secret, meaning every request is treated as authorized regardless of whether an Authorization header is present. Combined with a wildcard CORS policy on all responses, this lets a malicious webpage silently invoke any of the 22 exposed MCP tools on a victim's local server, including spawning agents and writing to shared blackboard state. This is a classic drive-by CSRF-style attack against a locally running privileged agent orchestrator.