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.

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.

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.

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.

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.

Lightdash's scheduled delivery feature lets a user-supplied webhook URL be posted to directly by the GoogleChat and MicrosoftTeams clients without applying the existing SSRF protection used for MCP server URLs. This allows an authenticated user to force the server to make requests to internal, loopback, or cloud metadata endpoints and infer reachability from logged error responses. It is a classic SSRF issue in a webhook delivery path rather than an attack on agent reasoning or an AI-specific exploit, though it touches the same URL-validation utility used to secure MCP server connections.

This is an academic survey (not an active exploit) analyzing how existing agent-security weaknesses become far more dangerous when AI agents use MCP tools and skills to sign and execute transactions on public blockchains. The authors argue that irreversibility, private-key signing authority, autonomous operation, and multi-step transaction composition turn normally recoverable agent failures into permanent financial loss, and find current defenses stop fewer than 30% of attacks. Since this is a research synthesis rather than a disclosed vulnerability or in-the-wild attack, severity is rated medium/informational for defenders rather than critical.

The CKAN MCP Server had a flaw where request parameters were serialized into cache keys using unescaped delimiter characters (&, =, |), allowing different logical queries to produce identical cache keys. An attacker could exploit this collision to poison the shared cache with attacker-controlled data that gets served back to a victim making a distinct, legitimate query.

An MCP server (mcp-dominican-layer) exposes a PDF-parsing tool that accepts a remote URL without adequate validation, allowing an attacker to force the server to make arbitrary outbound requests (SSRF). This could be used to probe internal networks, hit cloud metadata endpoints, or interact with internal services reachable from the MCP host. The vendor has not responded to the disclosure and a public exploit exists, increasing near-term risk for any deployment using this component.

A server-side request forgery (SSRF) vulnerability was found in MissionSquad mcp-api versions up to 1.11.9, specifically in the dynamic client registration handling code. A remote attacker can exploit this flaw to make the MCP server issue unauthorized requests to internal or arbitrary network destinations. The issue is fixed in version 1.11.10.

The alibabacloud-rds-openapi-mcp-server binds its MCP endpoint to all network interfaces by default, allowing any network-adjacent attacker to reach and invoke its exposed tools without proper access restriction. This is a configuration/deployment flaw rather than a novel exploit technique, but it can let unauthorized parties trigger RDS-related MCP tools if the server is reachable. Severity is moderate given the CVSS score of 5.8 and the dependency on network exposure and lack of authentication for actual exploitation.

A vulnerability in NanoClaw's MCP Server Approval component allows a local attacker to bypass authorization checks in the createChatSdkBridge.setup function, potentially approving or manipulating MCP server connections without proper consent. The flaw requires local access and has a public exploit available, but the vendor has not yet responded to the disclosure. Severity is moderate due to the local attack vector constraint, though the improper authorization could undermine trust in MCP server approval workflows.

Jan's local API server (through v0.8.4) mishandles trusted host configuration, replacing user-defined allowed origins with a wildcard that reflects any origin while still allowing credentials. This lets a network-adjacent or DNS-rebinding attacker reach the unauthenticated OpenAI-compatible API to run inference, enumerate models, invoke MCP tools, and read cross-origin responses. Fixed in commit 3e1c1e7; upgrade is the primary remediation.

The deprecated WebSocket transport in the MCP Python SDK accepted connections without validating Host or Origin headers, meaning any malicious webpage a victim's browser visits could open a WebSocket connection to a locally or network-exposed MCP server. This is a classic Cross-Site WebSocket Hijacking (CSWSH) pattern that could let an attacker-controlled origin interact with an MCP server's tools on behalf of an unwitting user. Severity is moderated because the affected transport is deprecated and impact depends on what the exposed server can do and whether it's reachable from a browser context.

This is an academic research paper, not an active exploit or attack. The authors built MCPZoo, a large dataset of runnable MCP servers, and found that existing MCP security scanners are unreliable: they flag ~97% of servers as risky, but fewer than half of sampled alerts are true positives, and different scanners disagree substantially with each other.

AstrBot's dashboard MCP connection test feature allows an attacker to supply an arbitrary URL that the server will fetch, resulting in server-side request forgery (SSRF). This could let an attacker probe internal networks, hit cloud metadata endpoints, or pivot against internal services from the AstrBot server. Exploit details are public and the vendor has not responded, increasing real-world risk.

The self-hosted HTTP transport of the DeepSeek MCP Server exposes the /mcp endpoint without any authentication, allowing any network-reachable client to initialize a session, enumerate tools, and invoke server-side functionality. This includes the deepseek_chat tool, which can consume the operator's own DEEPSEEK_API_KEY, leading to unauthorized API usage and potential cost/data exposure. The issue is patched in version 1.8.0.

This is a defensive research paper (not an active exploit) analyzing taint-style vulnerabilities in MCP server implementations, where untrusted input flows into dangerous sinks like command execution or file access. The authors propose SPELLSMITH, a mitigation that uses enhanced tool descriptions and LLM self-reflection to reduce exploitation risk without requiring code-level fixes. Severity is medium since it documents a real and underexplored class of vulnerabilities in deployed MCP servers, but the source itself is a proactive defense proposal rather than a disclosed active attack.

This is an academic research paper (not an active exploit) that identifies a structural weakness in MCP-style agent runtimes: security is typically enforced only at the connection layer (auth, session checks, approval dialogs) while execution-time actions lack consistent, testable invariants like principal binding and data-flow authorization. The authors demonstrate that naive and even 'practice-informed' mitigation baselines still permit most modeled attacks, and propose a reference runtime (HCP) that blocks all 10 benchmark attack cases by enforcing explicit execution-layer controls.