MCP Security News Tracker: The 2026 Timeline of Model Context Protocol Incidents and Disclosures

Between January and April 2026, researchers disclosed more than 40 CVEs against Model Context Protocol implementations, across the Python, TypeScript, Java, and Rust SDKs. The affected code spans an estimated 150 million downloads and more than 7,000 publicly accessible servers (CSA Labs).

Forty CVEs in four months against a protocol that reached broad adoption eighteen months earlier is not a run of bad luck in individual codebases. It is what happens when one design decision propagates into every implementation. This page tracks the disclosures, in reverse chronological order, with the mechanism and the operational consequence of each. I update it as new items land.

July 2026

July 8: Langflow CVE-2026-55255 exploited in the wild

Not an MCP CVE, and it belongs here because the same class of AI orchestration tool sits behind most MCP deployments. Help Net Security reported active exploitation of a CVSS 9.9 cross-tenant IDOR in Langflow that lets an attacker read other tenants' embedded secrets, including LLM provider keys, cloud credentials, and database secrets. CISA ordered federal civilian agencies to mitigate by July 10 (Help Net Security).

Operational consequence: any MCP server or agent host that keeps long-lived provider keys next to multi-tenant data turns an ordinary isolation bug into wholesale key theft. Audit what your MCP hosts store, before you audit what they execute.

July 1: Sysdig discloses JadePuffer

An LLM agent running an entire ransomware operation without a human in the loop: initial access through a Langflow RCE (CVE-2025-3248) and a Nacos auth bypass, then autonomous recon, credential theft, lateral movement, privilege escalation, and database extortion, with the agent self-correcting mid-attack (Sysdig).

Operational consequence: the tool surface an agent reaches is now an attacker's tool surface. Every MCP tool an agent can call is a capability an attacker inherits on compromise, which changes the scoping question from "what does this agent need" to "what does an adversary get if this agent is turned."

June 2026

June 2: NSA and CISA publish MCP security design guidance

The joint cybersecurity information sheet on Model Context Protocol security design (NSA) sets expectations for federal deployments: authenticate callers to MCP servers, authorize individual tool invocations, and treat the protocol's transports as security-relevant configuration.

Operational consequence: MCP authorization moved from a good idea to a documented federal expectation. Agencies and their contractors will be measured against it, and the enterprise market follows federal AI guidance on a lag of roughly two quarters.

April 2026

April 20: CSA and OX Security, "MCP by Design: RCE Across the AI Agent Ecosystem"

The research note that reframed the CVE count as one finding. The root cause traced to the STDIO interface, where configuration flows directly into command execution across every language implementation. As OX Security put it, one architectural decision, made once, propagated silently into every downstream library and every project that trusted the protocol to be what it appeared to be. The affected supply chain: an estimated 150 million downloads, more than 7,000 publicly accessible servers, up to 200,000 vulnerable instances, and 9 of 11 MCP marketplaces (The Hacker News).

Operational consequence: treating this as a patching exercise misreads it. A configuration file that reaches an MCP host is a command that reaches a shell. The control is the trust boundary around what may write MCP configuration, plus the removal of STDIO transports from any host that processes untrusted input.

Individual critical CVEs in the same window

• CVE-2026-33032, nginx-ui MCP, CVSS 9.8. The MCP message endpoint performed no authentication on command-execution requests. An unauthenticated caller reaching the endpoint ran commands on the host.
• CVE-2026-0755, gemini-mcp-tool, CVSS 9.8. Command injection in an open-source MCP tool, disclosed as a zero-day.
• CVE-2026-35394, Mobile MCP. Remote code execution through arbitrary Android intent execution from unvalidated URLs.

Operational consequence: the common thread is missing authorization on an execution primitive. An MCP server is an RPC endpoint that runs code. It inherits every requirement that any other RPC endpoint that runs code has ever had, and the ecosystem shipped for a year as though it did not.

2025: the design debt that produced 2026

Two items from before the CVE wave explain it.

Tool poisoning. Invariant Labs demonstrated in 2025 that an MCP tool description is text the model reads, so a malicious description can carry instructions that change model behavior without changing a line of the client's code. The tool never has to be called for the attack to work. Details in MCP tool poisoning prevention.

Authorization arriving late. The protocol's authorization model matured after adoption did, which left a large installed base of servers built when authentication was optional. The confused-deputy problem that follows is covered in the MCP confused deputy attack.

The three structural defects behind every entry above

1. Configuration is trusted. STDIO transports treat the config file as a trusted input, and a trusted input that becomes a command line is an execution primitive with no authorization step.
2. Tool descriptions are model-visible text. They are content and code at once, and the ecosystem's review processes treat them as neither.
3. Servers hold credentials. An MCP server that brokers access to a database, a repository, or an LLM provider accumulates the credentials for all of them, which makes it the highest-value object in the deployment.

Where the HTTP boundary applies, precisely

MCP over STDIO is a local transport between processes on a host. It never crosses an HTTP boundary, and no proxy inspects it. That half of the problem is owned by host hardening, configuration integrity, and workload isolation, and I will keep saying so rather than implying otherwise.

MCP over streamable HTTP is a different object. It crosses the network, it carries an identity, and every tool invocation is a request that a policy point can authorize, refuse, and record. That is where identity-aware enforcement applies, and it is also where the agent's own model calls go, which means the calls a compromised agent makes to an LLM remain observable even when the tool transport is local. I set out the enforceable subset in MCP policy enforcement.

What to do this quarter

• Inventory every MCP server reachable in the environment, including the ones a developer started locally and forgot.
• Remove STDIO transports from any host that processes input from outside the host.
• Require authentication on every HTTP MCP endpoint, and authorize the individual tool invocation rather than the connection.
• Treat tool descriptions as untrusted content under change control.
• Pin MCP server versions and track them against the CVE feed, which is now producing weekly.
• Record every tool invocation with the identity that requested it and the policy that permitted it.

DeepInspect

This is where DeepInspect fits, stated at its real boundary. DeepInspect is a stateless proxy between authenticated users or agents and any HTTP-based LLM endpoint. It binds every model call to a verified identity, evaluates policy on the assembled prompt and the model being addressed, and permits, redacts, or denies inline with a fail-closed default.

For MCP deployments, that produces two things. Tool invocations carried over HTTP MCP are authorized per call against the identity that requested them rather than against a connection established once. And when an agent is compromised through a local transport that no proxy can see, the agent still has to reach a model to operate, so the calls it makes are evaluated against policy and recorded in a signed, per-decision store that the compromised host never had custody of.

If your agents are calling MCP servers you have never inventoried, book an AI readiness assessment.