Protocol Vulnerabilities

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.

Updated Sep 3, 2026

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.

Updated Sep 3, 2026

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.

Updated Sep 1, 2026

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.

Updated Sep 1, 2026 · CVSS 6.3

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.

Updated Sep 1, 2026

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.

Updated Sep 1, 2026 · CVSS 7.1

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.

Updated Aug 31, 2026

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.

Updated Aug 29, 2026 · CVSS 3.1

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.

Updated Aug 29, 2026 · CVSS 6.8

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.

Updated Aug 29, 2026 · CVSS 9.1

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.

Updated Aug 29, 2026 · CVSS 6.8

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.

Updated Aug 29, 2026 · CVSS 9.1

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.

Updated Aug 29, 2026 · CVSS 6.8

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.

Updated Aug 27, 2026 · CVSS 8.6

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.

Updated Aug 27, 2026 · CVSS 8.2

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.

Updated Aug 26, 2026

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.

Updated Aug 26, 2026

The Nextcloud MCP Server's webhook endpoint lacks authentication by default because a required secret defaults to None, letting any network attacker send forged requests. These forged requests can delete or force re-indexing of another user's semantic search embeddings in Qdrant, effectively destroying or manipulating the AI assistant's retrieval memory. This is a critical, unauthenticated remote vulnerability fixed in version 0.117.2.

Updated Aug 25, 2026 · CVSS 9.1

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.

Updated Aug 25, 2026 · CVSS 6.9

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.

Updated Aug 21, 2026 · CVSS 6.4