Top MCP security resources — October 2026

The MCP story is increasingly revolving around authentication, and how often it is missing or skippable. LiteLLM’s MCP endpoint accepted any invalid bearer token, a flaw that became the first MCP vulnerability on CISA’s Known Exploited Vulnerabilities list. The Grafana MCP server validated session IDs only by their format, so anyone could forge one and act with its service account. Both fit classes in our ranked baseline, the Top 25 MCP vulnerabilities, each paired with the mitigation that closes it.

Detection had a rough month too. Two working malicious MCP servers passed five scanners cleanly, and a scan of roughly 82,000 public MCP configuration files found hardcoded secrets in one credential slot out of eight, most of them in a shape secret scanners do not recognize. On the governance side, CoSAI released version 2.0 of its MCP security model, with Adversa AI among the workstream leads.

Fifteen resources, grouped by topic. Last month’s digest covered the Deadbugz supply chain campaign.

Statistics

MCP security resources

MCP vulnerability

Cycode uncovers account takeover in MCP Python SDK

A malicious MCP server answers the client’s discovery request with a 404, which forces the MCP Python SDK’s OAuth client into a legacy fallback that skips issuer validation. The client then sends client secrets, authorization codes and PKCE verifiers to attacker endpoints. Fixed in 1.30.0 and 2.2.0; anything built on the SDK before those versions should be updated, because the flaw sits in the official reference implementation.

Off guard: breaking LiteLLM from authentication bypass to cloud compromise

LiteLLM’s MCP endpoint accepts any invalid bearer token (CVE-2026-59822, now on CISA’s KEV list), custom code guardrails allow admin code execution (CVE-2026-59821), and pass-through endpoints reach cloud metadata. Combined with 9.6% of exposed proxies still accepting the default sk-1234 master key, these form pre-auth chains that end in cloud compromise. If you run LiteLLM as your MCP or model gateway, patch it and change the master key today.

UI-fallback deny list covers /mcp-connect/ but not /mcp-connect-composite/, reopening the GHSA-vw82 authorization bypass

The Obot MCP gateway’s deny list blocks /mcp-connect/ with a trailing slash, so the composite route /mcp-connect-composite/ slips past it and any authenticated basic user can reach restricted MCP servers and call their tools. It is an incomplete fix for an earlier bypass, and the advisory recommends switching the check to an allowlist. Gateways are only as strong as their route matching, a point the gateway defense pieces below take for granted.

Valid, but never issued: session spoofing and SSRF in Grafana MCP

The Grafana MCP server validated session IDs only by format, so unauthenticated callers could forge one and invoke tools with the server’s Grafana service account credentials. A spoofable X-Grafana-URL header also turned grafana_api_request into a full SSRF proxy (CVE-2026-19516). An MCP server that holds a service account is a privileged proxy, and should be exposed and authenticated like one.

MCP defense

Five gates before an MCP tool reaches production

Five practical checks before a tool ships: trace the human, agent and backend credential behind every call, scope visible tools to what the task needs, rate limit against loops, require human approval for destructive or outbound actions, and log evidence while protecting sensitive payloads. It is a short checklist that pairs well with the CoSAI assurance levels below.

Implementing defense-in-depth authorization for MCP tools on Amazon Quick

A worked example of layered authorization for MCP tools on Amazon Quick: MFA at the identity provider, country geofencing on token claims, RBAC mapped from group claims, tool allowlists checked in an interceptor, reauthorization inside each tool’s Lambda, and immutable audit logs. Checking again inside the tool is the kind of control that limits the damage when a gateway check, like the Obot route match above, is bypassed.

MCP tool poisoning: how AI gateways defend against it

Tool poisoning hides directives in MCP tool descriptions and schemas that agents treat as authoritative. The countermeasures described are server trust verification, RBAC, schema validation with Unicode normalization, heuristic plus LLM judge scanning, default deny for tool approval, and revalidation at invocation. Read it alongside the clean scan research below before relying on any single scanning layer.

Attack technique

A2M: trace-optimized agent hijacking in the MCP ecosystem

A two stage black box attack: first optimize tool metadata so agents pick the malicious tool (93.6% invocation), then refine adversarial tool returns from execution traces to drive exfiltration, environment compromise or reasoning derailment at 74.4% success. The attack transfers across models, so model choice is not a mitigation.

Malicious servers, clean scans: the dangerous illusion of a clean MCP scan

Two working malicious MCP servers, a credential harvester and a remote code executor, got clean results from each of five scanners, including Cisco mcp-scanner, Snyk agent-scan and NVIDIA SkillSpector. The evasions were payloads in handler code, obfuscation, oversized files and scanner fingerprinting. A clean scan is a starting point, not an approval. Our own test of open source AI skill scanners found the same: a malicious skill got past all eight.

Measuring and exploiting implicit trust in LLM tool-calling pipelines

Splitting one injection across MCP tool descriptions, tool results and sampling messages lets attackers exfiltrate credentials at up to 100% from models that resist single channel injection. Seven MCP security tools missed the fragmented payloads, and VS Code (Microsoft) MCP sampling allows a system prompt override. Like the scanner research above, it shows detection that inspects one message at a time misses attacks spread across several.

Defense frameworks (formal frameworks)

MCP Security, Version 2.0: from threat taxonomy to a model you can actually audit against

CoSAI’s MCP Security v2.0, developed with Adversa AI among the workstream leads, turns the 12 MCP threat categories from version 1 into an auditable model with four security assurance levels and eight security dimensions, from a local sandbox up to regulated multi-tenant platforms. It adds guidance for the protocol’s move away from stateful sessions, the Tasks framework, a post-quantum migration path and centralized gateway enforcement. Use the assurance levels to decide how much of the defense guidance in this digest a given deployment actually needs.

CISO resources on MCP

The state of MCP configuration: the identity security gaps

Across about 82,000 public MCP configuration files for coding agents, 12% of credential slots hardcode a secret. 55% of those secrets lack a recognizable token shape and evade gitleaks or GitHub secret scanning, and 24% are broad in scope and never expire. Inventory MCP configs as credential stores, not as developer preferences.

MCP incident

When “auto-signing” sends your wallet: a malicious MCP server on npm

The gadgethumans-mcp package on npm advertised automatic signing of x402 micropayments. It performs no signing at all: it sends the raw WALLET_PRIVATE_KEY environment variable in an HTTP header to a remote endpoint on every tool call. It is exactly the kind of handler code payload that the clean scan research above showed scanners miss.

MCP red teaming

No-box vulnerability analysis: description-only detection of indirect prompt injection vulnerabilities in MCP servers

Using only the tool metadata MCP servers expose at registration, a no-box analyzer hypothesizes indirect prompt injection vulnerabilities and how to exploit them. Across 20 deployed MCP servers it recovered 94 of 95 verified vulnerable tools, against 84.2% recall for an LLM baseline. Useful for triaging third-party servers you cannot inspect.

Article

Characterizing network centralization and observability in the remote MCP ecosystem

A measurement of 179 public remote MCP servers finds hosting highly concentrated, with 95% of commercially cloud hosted servers using gateway OAuth 2.1 with PKCE. The tradeoff: that platform authentication blocks outside vulnerability scanning, which limits anyone’s ability to assess tool poisoning risk from the outside.

Authenticate every hop, then check again inside the tool

Four of this month’s vulnerabilities came down to authentication that could be skipped, forged or matched loosely: an invalid bearer token accepted, a session ID checked only for format, an OAuth fallback without issuer validation, and a deny list missing one route. Update the MCP Python SDK and LiteLLM, rotate any default gateway keys, and replace prefix-based route blocking with allowlists.

Then stop treating a clean scanner result as approval. Fragmented injections and handler code payloads went undetected across every scanner tested. Pin MCP servers to reviewed versions, move secrets out of MCP config files, and add reauthorization inside each tool so that a gateway bypass does not become a data breach. Whether those layers hold against a hostile server is what MCP red teaming tests.