MCP Server Vulnerabilities: Why the Worst Ones Aren't AI Bugs (2026)

When people talk about MCP server vulnerabilities, they usually mean prompt injection and tool poisoning.

Those are real. But they are not where most of the damage is.

The worst MCP bugs of 2026 are the ones web developers fixed in 2006. Path traversal. Missing auth. Leaked secrets. SSRF.

A July scan of 414 live MCP servers found 91.8% without OAuth. August's CVEs were a file read, a token leak and a server-side request forgery.

If you ship an MCP server and only test it for AI-specific attacks, you are guarding the side door and leaving the front open.

I will go through the data, the four CVEs, and why MCP makes these old bugs worse, not better.

Then a short checklist you can run against your own server this afternoon.

Are MCP Servers Secure? What the "Exposed by Design" Study Found

Mostly not. In July 2026, 91.8% of the internet-facing MCP servers that researchers tested had no OAuth, and 68 reportable vulnerabilities were filed.

The study is "Exposed by Design" by Nicolás Padilla of CobaltoSec. It is the first large dynamic test of live MCP servers, not just a code review.

The 8.2% that did have auth mostly used static bearer tokens, API keys or basic auth. The paper notes many of those tokens were predictable or empty.

What kinds of bugs did it find?

The study counted affected servers per category. The top of the list, by count:

• Authentication gaps: 380 servers
• Protocol fuzzing failures: 52 (malformed requests the server mishandled)
• Tool poisoning: 47
• Command injection: 38
• Schema bypass: 31 (arguments the schema should have rejected)
• SSRF: 29
• Resource URI manipulation: 24
• Prompt injection: 22
• Token exposure: 18
• Supply chain: 14

Count the AI-specific rows: tool poisoning and prompt injection. Everything else is a bug class with a CWE number older than MCP itself.

One disclosed example: an SSRF that reached the AWS instance metadata service. The tell was timing: 11.9 seconds against a 0.3-second baseline.

The August 2026 MCP CVEs, One by One

Three MCP server CVEs landed in August 2026: path traversal, cleartext secret exposure and SSRF. A fourth, CSRF, was disclosed today.

CVE-2026-73498: path traversal in mcp-atlassian

What: confluence_upload_attachment passed its file_path argument straight to open() without the project's own validate_safe_path check.

• Affected: mcp-atlassian before 0.22.0. CWE-22. CVSS 7.7. Published 12 August 2026.
• Impact: read any file the server process can read, then upload it to Confluence as an attachment.
• The MCP twist: if an agent is steered by untrusted content, it can call the tool itself and leak environment secrets such as CONFLUENCE_API_TOKEN.

The helper existed. One tool forgot to call it. That is the most common way path traversal ships.

CVE-2026-67357: ArcadeDB's settings tool leaks the cluster token

What: the MCP get_server_settings tool returned arcadedb.ha.clusterToken in cleartext.

• Affected: ArcadeDB before 26.7.3. CVSS 7.5. Published 2 August 2026.
• Impact: with the token, the X-ArcadeDB-Cluster-Token and X-ArcadeDB-Forwarded-User headers let an attacker impersonate root.
• Fix: upgrade, then rotate cluster tokens and invalidate sessions. Patching alone leaves a stolen token valid.

A "read settings" tool is a secrets tool unless you redact it. And every tool result lands in the model's context, which is logged, cached and sometimes shared.

CVE-2026-19956: SSRF in facebook-ads-mcp-server

What: fetch_pagination_url in gomarble-ai's facebook-ads-mcp-server 0.1.0 fetched whatever URL it was given.

• Impact: an authenticated user can make the server send requests from its own network position: internal services, cloud metadata endpoints, admin panels.
• Severity: CVSS 5.3, fixed in a single commit.

Pagination URLs look harmless because the API normally supplies them. But the argument comes from the model, and the model can be told what to write.

CVE-2026-96524: CSRF in the MCP Server for WordPress plugin

Disclosed on 26 September 2026. Versions before 1.8.2 did not verify nonces on REST calls.

A logged-in admin who visits a crafted page can be made to create a new administrator account. CWE-352. The fix is 1.8.2.

Four CVEs, four OWASP web categories. Not one needed a model to exploit.

Why Classic Bugs Make MCP Server Vulnerabilities Worse

MCP turns every tool argument into input an attacker can influence without ever touching your server. That changes who can exploit an old bug.

In a normal web app, the attacker sends the malicious request. In an MCP server, the agent sends it for them.

That is a confused deputy: a trusted component tricked into misusing its own authority.

The attacker writes a Jira ticket, a web page or a GitHub issue. Your agent reads it. Your agent calls confluence_upload_attachment with ../../.env.

So "authenticated user only" is weaker than it sounds. The authenticated user is your agent, and your agent reads untrusted text all day.

Three more ways MCP amplifies the damage

• Results go into context. A leaked token is not just returned. It is sent to a model provider, logged and possibly cached.
• Tools come in bundles. A file read plus a web fetch is an exfiltration path, even if each tool is safe alone.
• Servers churn. With 41.6% of servers gone in three days, many run for days without anyone patching them.

Mid-way through? Scan your MCP server → for missing auth, weak transport, injection risk and information disclosure. Free, in the browser, graded A to F.

How Do I Fix the Most Common MCP Server Vulnerabilities?

Treat every tool argument as hostile input, require real auth on every request, and redact secrets from every result. The rest is detail.

1. Put OAuth in front of every HTTP server

The study's first recommendation is OAuth 2.1 by default for HTTP transport. It is also what the MCP authorization spec expects.

Gate discovery too. tools/list leaks your capability map. The insufficient authentication page covers token binding and the other checks. My MCP OAuth guide has the setup.

2. Resolve and confine every path

Resolve the path, then check it is still inside the allowed root. Do it in one shared function every file tool must call.

import path from "node:path";

const ROOT = path.resolve(process.env.FILES_ROOT);

export function safePath(userPath) {
  const full = path.resolve(ROOT, userPath);
  if (full !== ROOT && !full.startsWith(ROOT + path.sep)) {
    throw new Error("Path outside allowed root");
  }
  return full;
}

Then add a test that lists every tool with a path-like parameter and fails if its handler skips safePath.

That is the check mcp-atlassian was missing. See command injection and execution for the full pattern.

3. Constrain what your fetchers can reach

Any tool that takes a URL needs an allowlist of hosts. For pagination, accept a cursor, not a URL, and build the URL yourself.

Block link-local and private ranges, including 169.254.169.254. The intent flow subversion page covers fetchers in detail.

4. Redact secrets from tool results

A settings or config tool should return an allowlist of safe keys, not a dump with a denylist. New secrets get added. Denylists do not update themselves.

The token mismanagement page explains why the context window counts as a published surface.

5. Fuzz the protocol, not just the tools

Protocol fuzzing was the second-largest category in the study, at 52 servers.

Send malformed JSON-RPC, wrong types and oversized payloads. The server should reject them cleanly, not crash or leak a stack trace.

MCP Server Vulnerabilities Checklist

The full map lives on the OWASP MCP Top 10 hub, with a page and fixes for each risk.

How MCP Playground Can Help

I start every server review in the MCP server tester: connect, list tools, and read every parameter. Any argument named path, url or command goes on my list.

Then the security scanner runs 35+ checks, including auth enforcement (does it return 401 without a token?), TLS, CORS, security headers and information disclosure.

It will not find every one of your MCP server vulnerabilities, such as a path traversal deep in a handler.

It will tell you in a minute whether you are in the 91.8%.

For deeper background, see my MCP server security guide, the post on the MCP stdio RCE vulnerability, and what the Model Context Protocol is if you are new.

Frequently Asked Questions

The Bottom Line

The MCP vulnerabilities doing real damage in 2026 are old web bugs with a new delivery route.

The agent is the new way in. The bug is still path traversal, a leaked secret or SSRF.

Add OAuth, confine paths, allowlist URLs and redact results. That covers most of the MCP server vulnerabilities the study and the CVEs found.