Threat Library

Rowboat versions through 0.9.1 let authenticated users register arbitrary MCP server and webhook URLs without validating the destination, enabling server-side request forgery. An attacker can abuse this to reach internal-only services or cloud instance metadata endpoints, potentially exposing credentials or internal network topology. This is a classic insecure agent-tool-configuration flaw rather than a novel agentic attack technique.

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.

This is an academic research paper proposing a new protocol-layer defense (Skill-as-API) rather than a report of an active exploit. It identifies a legitimate design weakness in current agent coordination protocols like MCP and A2A: they expose full skill descriptions, schemas, and potentially system prompts to all peers, and offer no mechanism to hide skill existence or narrow the prompt-injection surface structurally. Severity is low because this is a proactive mitigation proposal, not evidence of exploitation in the wild.

This is a defensive research paper, not an active exploit, that identifies a structural weakness in OAuth-secured remote MCP tool use: a tool endpoint can remain 'authorized' even after the underlying workload executing the call has been substituted, is running stale attestation state, or reuses authority meant for a different sender. The authors propose ACLE-MCP, an invocation-scoped capability-lease architecture that binds authorization to fresh, workload-specific execution state, and demonstrate it closes these gaps with a manageable latency cost.

This is an academic research paper proposing a defensive attestation scheme to help verify which deployer produced given output bytes and whether cross-agent delegation edges were properly authorized in multi-agent AI systems. It is not describing an active exploit or vulnerability being exploited in the wild; rather it presents cryptographic designs (signed linked list, Merkle-chain, co-signed DAG) to detect unauthorized delegation claims, including after child-key compromise. The severity is low because the content is a proposed mitigation/verification framework, not a threat report.

The sdcb 'chats' application (up to v1.12.0) contains a server-side request forgery (SSRF) vulnerability in its MCP-related fetch-tools endpoint, allowing a remote attacker to make the server issue arbitrary HTTP requests. A public exploit exists and the vendor has not responded to disclosure, so this remains unpatched. Severity is moderate given the network-based attack vector but no confirmed data exfiltration or code execution in the description.

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.

The Dash MCP server bound its network listener to loopback but failed to validate the Host header of incoming requests, allowing DNS rebinding attacks from a malicious webpage to reach the local server. An attacker-controlled page in a victim's browser could rebind a domain to 127.0.0.1 and invoke the server's tools using the victim's stored Dropbox credentials. The issue is limited to the network transport mode and was fixed by adding host-checking transport security.

tiger-slack's MCP HTTP transport failed to enable the SDK's built-in host allow-list/DNS-rebinding protection, allowing a malicious webpage visited by a user on the same machine to rebind a DNS name to the local MCP server's address and issue requests to it. This lets an attacker's browser-based script drive the locally running Slack MCP server on behalf of the victim, potentially reading or sending Slack data without authorization. The fix requires explicitly enabling the allow-list option, not just updating the dependency.

The Telnyx MCP server listened on all network interfaces without enforcing caller authentication, allowing any network-reachable client to invoke tools without credentials. Because the server forwarded its own stored Telnyx API key, client secret, and code-execution key to upstream services on every dispatch, an unauthenticated attacker could execute privileged actions and code as if they were a legitimate caller. This is a critical, unauthenticated remote compromise of an AI tool-serving component.

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-router CLI's serve command bound to all network interfaces by default and only enforced authentication if an operator explicitly requested it, meaning a standard invocation exposed the MCP aggregator and every downstream MCP server it fronts to anyone who could reach the port. This is a straightforward insecure-default configuration flaw rather than a novel attack technique, but its impact is severe because it grants unauthenticated network access to an aggregation point for multiple MCP tool servers. Version 0.6.3 fixes this by defaulting to loopback binding and refusing non-loopback starts without a token.

mcp-go's HTTP transports failed to validate the Host header on loopback-bound requests, allowing a malicious webpage in a user's browser to use DNS rebinding to reach a local MCP server and invoke its tools or read its resources. This breaks the security assumption that only trusted local software can talk to a loopback-bound MCP server. The issue is fixed in 0.56.0 via strict host validation.

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.