MCP Security 2026: Critical Vulnerabilities, Malicious Servers, and the New Attack Surface for AI Agents

The Model Context Protocol (MCP) has established itself as the standard plug-in for AI agents in 2026: once connected, Large Language Models can access internal APIs, databases, and workflows via MCP. However, while adoption in production is rising rapidly, autumn 2026 reveals a first serious security crisis. From the CISA-KEV list to critical privilege escalations to malicious servers that pass all common scanners – the headlines are piling up.

LiteLLM and the CISA-KEV List: First MCP Vulnerability on the Government Blacklist

In September 2026, the US agency CISA set a milestone: for the first time, an MCP-specific vulnerability landed on the Known Exploited Vulnerabilities (KEV) list. CVE-2026-59822 affects LiteLLM, a widely used open-source proxy that serves as a gateway between applications and LLM providers. The MCP Streamable HTTP endpoint accepted any arbitrary Bearer token as valid authentication – an improper authentication flaw (CVSS 8.8) that allowed attackers to establish full-fledged MCP sessions without valid credentials (Tech Insider).

The consequences are severe: a hijacked MCP access grants not only access to a single service but to all tools, databases, and workflows that the LiteLLM proxy accesses on behalf of AI agents. CISA set a deadline of three to seven days for federal agencies – an indicator of the urgency. This was not the first LiteLLM incident: already in June 2026, CVE-2026-42271 had appeared on the KEV list, a command execution via MCP stdio test endpoints (WZ-IT).

Vulnerabilities in the Protocol Ecosystem: From Session Spoofing to Privilege Escalation

But LiteLLM is only the tip of the iceberg. In October 2026, security research firm Adversa AI recorded 15 new MCP security resources in one month. Three examples illustrate the range:

Session Spoofing in the Grafana MCP Server: The Grafana MCP server validated session IDs only by format, not by issuer. Unauthorized callers could present any session ID and access Grafana instances using the server’s service account credentials (CVE-2026-19516). Additionally, a manipulable X-Grafana-URL header allowed full SSRF access (Adversa AI).

Privilege Escalation in LiteLLM (CVSS 9.9): Already at the end of September 2026, BerriAI published an advisory on GHSA-7hp6-4w63-5g45. The same LITELLM_SALT_KEY was used both for encrypting secrets and for creating session tokens. An authenticated user with the internal_user role could inject a manipulated admin key, which the proxy unknowingly signed – thereby gaining full proxy_admin control, including command execution on the host via the MCP stdio endpoint. GitHub rated the vulnerability as CVSS 9.9 (critical). A follow-up advisory (GHSA-g5ff-637f-6q2m, CVSS 8.1) showed that even the internal_user_viewer role could read arbitrary files of the proxy process (WZ-IT).

OAuth Fallback Without Issuer Validation: An attacker could configure an MCP server to return a 404 status on client requests. This caused the MCP Python SDK (versions before 1.30.0/2.2.0) to fall back to a legacy OAuth path that completely skipped issuer validation. Client secrets, authorization codes, and PKCE verifiers ended up on the attacker’s server (Adversa AI).

Blind Spots in Security Scanners: Two Malicious MCP Servers, Five Clean Scans

An alarming research result from Pluto Security (September 2026) shows how inadequate the current MCP scanning landscape is. The researchers built two functional malicious MCP servers: a credential thief that extracted SSH, AWS, and Kubernetes credentials and sent them to a collection server, and a remote code execution server that fetched and executed commands from a second server. Both disguised themselves as harmless weather tools.

Five public scanners were tested: Cisco mcp-scanner, Snyk agent-scan, Ventrova sentinel-scan-cli, mcp-shield, and NVIDIA SkillSpector. The result: All five scanners returned clean results (“SAFE”, “0 findings”, “Verified”) for at least one of the malicious servers. The reason: The scanners primarily checked tool metadata (names, descriptions, schemas), but not the actual handler code. Only SkillSpector’s LLM source code review detected both servers – but only at normal file size. Once the malicious code was hidden behind 16 MiB of harmless text, the LLM review skipped the file, and the scan reported “CAUTION / 0” with incomplete coverage (Pluto Security).

Conclusion

Autumn 2026 marks a turning point for MCP security. The protocol has left the experimental stage behind – and with it its naive security assumptions. The findings are sobering: authentication is often bypassable, privileges are insufficiently separated, and existing scanning tools do not reliably detect malicious MCP servers. The MCP community is reacting: CoSAI released version 2.0 of its MCP security model, and initiatives like the “Five Gates” before MCP tool production – identity, scope, limits, approval, and evidence – offer practical guidance. Anyone running MCP servers in production should apply patches immediately, not expose MCP endpoints unprotected to the network, and treat scans for what they are: a snapshot, not a free pass.

Sources

• Adversa AI: Top MCP Security Resources October 2026 — Monthly overview of MCP security incidents and research
• Tech Insider: CISA Flags First MCP Flaw: LiteLLM Hits CVSS 8.8 — Analysis of the first MCP-specific CISA-KEV entry
• WZ-IT: LiteLLM Vulnerability GHSA-7hp6-4w63-5g45 — Detailed analysis of the privilege escalation and patch management
• Pluto Security: Malicious Servers, Clean Scans — Research on MCP scanner gaps and malicious servers
• Jannik Reinhard: Five Gates Before an MCP Tool Reaches Production — Production checklist for MCP tools