Threat Library

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.

This is defensive academic research, not an active exploit or new vulnerability disclosure. The paper proposes ChainWatch, a detection framework using a kill-chain model and Hidden Markov Models to spot malicious sequences of otherwise-benign MCP tool calls that evade per-call security checks. It confirms a known class of risk (composable multi-step attacks in MCP agent systems) but the artifact itself is a defense, so severity is low from a threat-alert perspective.

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.

The WhatsApp MCP server's local bridge API (port 8080) had no authentication, no Host header validation, and allowed arbitrary file paths in message attachments. This let any local process, sibling MCP server, or even a malicious webpage (via DNS rebinding) send WhatsApp messages as the paired user and exfiltrate sensitive local files like SSH keys as WhatsApp attachments. It is fixed in v0.2.1 with bearer token auth, host allow-listing, and path confinement.

This is a defensive security research paper describing FlowGuard, a detection system that identifies real vulnerabilities (like command injection and file system access risks) in MCP servers by combining semantic analysis with runtime evidence verification. It is not an active exploit or attack technique, but rather a scanner designed to help defenders find genuine risks in the MCP ecosystem, which it did find in real-world servers (523 findings across 326 servers). The paper itself poses no direct threat; it highlights that underlying vulnerabilities in MCP tool implementations are prevalent enough to warrant sophisticated detection tooling.

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.

The MCP Python SDK's experimental task management feature failed to bind tasks to the session that created them, allowing any connected client to list, read, cancel, or consume messages for tasks belonging to other clients. This is a broken access control / IDOR-style flaw that breaks the trust boundary between concurrent MCP sessions on the same server. It is fixed in version 1.27.2.

The MCP Python SDK's SSE and stateful Streamable HTTP transports route messages to sessions based solely on a session ID, without checking that the requesting client is the same authenticated principal who created that session. Any bearer-token-authenticated client that learns or guesses a valid session ID can inject JSON-RPC messages into another user's active session, effectively hijacking it. This is a serious cross-tenant authorization flaw fixed in version 1.27.2.

PraisonAI versions before 4.6.78 default to running the MCP HTTP-stream server without any API key or authentication, meaning anyone who can reach the endpoint can list and invoke all exposed tools. The server also fails to validate tool-call arguments against the advertised schema, compounding the risk of malformed or malicious inputs reaching tool handlers. Exploitation requires the operator to have bound the server to a network-accessible address rather than the safe localhost default.

An unauthenticated attacker can abuse the Grafana MCP Server by injecting a crafted X-Grafana-URL header, tricking the server into acting as a proxy that leaks its own privileged Grafana service-account token. This same flaw allows server-side request forgery against internal networks and cloud metadata endpoints, giving attackers a path to full credential theft and internal reconnaissance without needing any prior authentication.

The AWS HealthLake MCP Server fails to validate that pagination URLs returned via the next_token parameter point back to the legitimate HealthLake endpoint, enabling an authenticated user to redirect the server's outbound requests to an attacker-controlled endpoint. This can leak AWS temporary security credentials used by the MCP server, giving an attacker a foothold to access AWS resources tied to those credentials. Fixed in version 0.0.14.

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.

The DeepSeek MCP Server fails to bind session IDs to authenticated users or transport sessions, allowing any caller to enumerate active sessions and hijack another user's conversation context. This lets an attacker read and continue a victim's private chat history, exposing sensitive data and enabling impersonation within the session. The flaw is patched in version 1.7.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.

Cline's local Hub dashboard server fails to validate the Origin header on its WebSocket /browser endpoint, allowing any malicious website visited by a user to connect and issue commands. When ROOM_SECRET is unset (the default for local binds), attackers can read workspace state, tamper with MCP and provider settings, and trigger arbitrary command execution if a model provider is configured. This is a critical, fully remotely exploitable vulnerability via drive-by browser interaction with no user awareness required.

LiteLLM's MCP Streamable HTTP endpoint prior to version 1.84.0 could be tricked into skipping key validation by sending a fabricated Authorization header, causing the server to fall back to an empty, effectively unauthenticated user context. This let attackers reach MCP tooling and any downstream tools/agents exposed through the proxy without holding a valid LiteLLM API key. The vulnerability is fixed in 1.84.0.

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.