MCP 安全缺口擴大 AI 開發工具的攻擊面

MCP went from "clever plumbing" to "the most exploited attack surface in developer tooling" in under a year. Here's the full damage report.

The Hook

A developer opens a GitHub repo in Cursor. Their AI assistant loads the project config. A SessionStart hook fires. Before they finish their coffee, their cloud credentials, SSH keys, and .env files are sitting in an attacker's GitHub repo under the name "Miasma: The Spreading Blight."

No phishing email. No malicious download. No "click here" link. Just a repo, an IDE, and a protocol that was designed to make AI tools convenient — and shipped with the security posture of a screen door in a hurricane.

That's the Model Context Protocol (MCP) in 2026. And it's not one bug. It's a design philosophy problem that's now producing CVEs at a rate that should make every platform team uncomfortable.

The Miasma Worm: When Your AI Tool Is the Payload

What happened: In June 2026, the threat group TeamPCP (tracked by Google as UNC6780) released a self-propagating credential-harvesting worm called Miasma. It operates on two fronts simultaneously:

• It compromises npm packages (the initial wave hit 32 @redhat-cloud-services packages via a trusted-publishing branch bypass).
• It injects itself into the SessionStart hooks of 13 AI coding tools, including Claude Code, GitHub Copilot, and Gemini CLI.

The worm uses GitHub itself as its C2 channel — no dedicated infrastructure, no domain to sinkhole. It spreads by committing poisoned config files back to repos.

Why it matters: This is the first confirmed worm that treats AI coding assistants as both the infection vector and the execution environment. Your developer's laptop isn't a victim machine anymore. It's a node in the propagation chain.

What to do:

1. Audit SessionStart hooks and .mcp.json / .cursor/mcp.json files in every repo your team touches. If you didn't write it, don't trust it.
2. Block network egress from CI runners during package install. Miasma phones home at install time.
3. Pin npm package versions with integrity hashes. The trusted-publishing bypass only works if you accept unsigned installs.

The STDIO Flaw: "By Design" Is Not a Security Posture

What happened: On April 15, 2026, OX Security published a report titled "The Mother of All AI Supply Chains." The finding: Anthropic's official MCP SDKs — Python, TypeScript, Java, and Rust — all pass configuration values directly into OS command execution via the STDIO transport. No sanitization. No allowlist. No validation.

Anthropic's response: it's working as intended.

The blast radius: 7,000+ publicly reachable servers, 150 million+ package downloads, and an estimated 200,000 total MCP server instances affected. Downstream CVEs have since been filed against LiteLLM, LangChain, LangFlow, Flowise, and others that inherit the pattern.

Why it matters: This isn't a bug in one product. It's a protocol-level architectural decision that propagated into every language SDK and every server that uses the STDIO transport (which is most of them). The attack model is trivial: control any config source that feeds into the STDIO launch command, and you have arbitrary code execution on the host.

What to do:

1. If you're running MCP servers via STDIO, review every command and args field in your config. Treat them as untrusted input.
2. Prefer HTTP/SSE transport over STDIO for anything that isn't a single-user local tool.
3. Run MCP servers in containers with minimal filesystem access. The "execute first, validate never" model means your container is your security boundary.

The Exposed Server Problem: 1,467 and Counting

What happened: Trend Micro's April 2026 follow-up scan found 1,467 MCP servers exposed to the open internet — nearly triple the 492 they found in their initial scan months earlier. Of those, many had zero client authentication and zero traffic encryption.

The Trend Micro report also documented CVSS 9.8 command-injection flaws in unofficial AWS and Azure MCP servers (CVE-2026-5059, CVE-2026-5058), showing that the exposure isn't just "your data is readable" — it's "an attacker can take over the cloud account the MCP server is connected to."

Why it matters: MCP servers are the new S3 buckets. They hold privileged tokens, connect to databases, and sit on the internet with the default security of "I hope nobody finds this port." The tripling in nine months tracks the adoption curve perfectly: everyone is wiring up AI tools, and nobody is thinking about network exposure.

What to do:

1. Scan your environment for MCP server ports (common defaults: 3000, 8080, 8443) that are internet-reachable.
2. If you must expose an MCP server, put it behind OAuth 2.0 + mTLS. "API key in a header" is not a security model.
3. Review the tokens your MCP servers hold. If one connects to your production AWS account with admin perms, you have a problem that predates MCP.

The Trust Model Is Broken: One Click, Full RCE

What happened: Multiple CVEs and research disclosures in 2025–2026 have confirmed that the major AI coding IDEs — Cursor, Claude Code, Gemini CLI, GitHub Copilot — auto-execute project-defined MCP servers with the developer's full OS privileges and no process isolation.

The specific trust failures:

• Cursor (CVE-2025-54135, CVSS 8.6 / "CurXecute"): Approval is bound to the MCP server's name, not its contents. A teammate commits a change to .cursor/mcp.json that swaps the command. The next developer pulls, opens the repo, and the malicious command executes under the previously-approved name. No new prompt. No warning.
• Cursor (CVE-2025-54136, CVSS 7.2 / "MCPoison"): Same root cause, framed as a persistence mechanism. Once approved, the entry is trusted forever until manually removed.
• Claude Code (CVE-2025-59536, CVSS 8.7): MCP servers executed before the trust dialog rendered. Patched, but the underlying "trust the folder" model remains.
• Amazon Q (CVE-2026-12957, CVSS 8.5): A malicious .amazonq/mcp.json in a repo = arbitrary code execution + cloud credential theft.
• "TrustFall" (May 2026, no CVE assigned): A one-click RCE pattern affecting Claude Code, Gemini CLI, Cursor CLI, and GitHub Copilot CLI simultaneously. Anthropic declined to patch, classifying the behavior as design intent.

Why it matters: The trust model assumes a single developer on a single machine with a single repo. It does not survive the moment you have a team, a shared repo, or a fork. The "trust this folder" dialog is a security boundary that's only as strong as the git history.

What to do:

1. Treat .mcp.json, .cursor/mcp.json, .amazonq/mcp.json, and equivalent files as executable code in your code review process. They should get the same scrutiny as a postinstall script.
2. Disable auto-run/auto-approve for MCP servers in team environments. Require explicit, per-command approval.
3. If you're a platform team, build a pre-commit hook or CI check that flags new or modified MCP config files.

The Fresh One: Splunk's MCP Server Gets a 9.1

What happened: On August 19, 2026, Splunk published advisory SVD-2026-0808 covering 17 vulnerabilities across its app ecosystem. The headline: CVE-2026-76404, a CVSS 9.1 critical RCE in the Splunk MCP Server app (versions below 1.2.1). The flaw: unsafe deserialization (CWE-502) in the credential management component. An authenticated admin-role user could execute arbitrary commands on the underlying OS.

Patched in 1.2.1. But the point isn't the patch. The point is that Splunk — a company whose entire business is security observability — shipped an MCP server with a critical deserialization flaw in its credential handler.

Why it matters: If the vendors building security tools are getting MCP servers wrong, the long tail of "I built an MCP server for our internal tool in a weekend" is going to be significantly worse.

What to do:

1. If you're running the Splunk MCP Server app, verify you're on 1.2.1+.
2. More broadly: audit every MCP server you run for deserialization of user-controlled data. It's the same class of bug that's been killing Java and .NET apps for a decade. It's not going to be different just because the protocol is new.

The Structural Problem

Here's the thing that ties all five of these together. MCP was designed to solve a real problem: how do you let an AI model call tools, query databases, and interact with APIs in a standardized way? The answer was "a JSON protocol with a few transport options." The security model was... an afterthought.

There is:

• No native authentication framework (you roll your own, or don't).
• No capability attestation (a server declares what it can do; nothing verifies it).
• No isolation between servers (they run as your user, with your permissions).
• No integrity checking on config files (they're just JSON in a folder).
• No standard for logging or auditing what a server actually did.

The protocol spec is 200 pages of "here's how to send a JSON message." The security spec is "good luck."

It's like giving every intern a master key to the building and calling it "convenience."

What This Means for You

If you're running any MCP server — and in 2026, if you have an AI-assisted dev shop, you are — you have a new attack surface that your existing security tooling does not cover. Your WAF doesn't inspect MCP traffic. Your SIEM doesn't parse MCP logs. Your vulnerability scanner doesn't know what an MCP server is. Your CSP doesn't apply. Your network segmentation was designed for HTTP and gRPC, not for a local process that reads .env files and calls child_process.exec().

The good news: the fix list is concrete. Containers. OAuth. Config-as-code review. Egress filtering. The bad news: most of these require someone to decide to do them, and right now the default path is "it works, ship it."

The next cascade is already being scheduled.

Discussion

1. Anthropic called the STDIO execution behavior "by design" and declined to add validation at the protocol level. Do you think that's a defensible position (the SDK is a transport, not a security boundary) or a catastrophic abdication of responsibility? Where should the fix live — in the spec, the SDK, or the server implementations?

2. The TrustFall finding (one-click RCE across four major coding agents, no CVE assigned) suggests the industry's CVE process isn't built for "this is how the product works" findings. Should we have a separate tracking mechanism for design-level security issues that don't get a CVE? What would that look like?

3. You're a platform engineer and your team just told you they need to "spin up an MCP server for the internal knowledge base by Friday." What's your minimum viable security checklist before you say yes? (Be specific. "Add auth" is not a checklist.)

Sources:

• OX Security, "The Mother of All AI Supply Chains" (April 15, 2026); VentureBeat; SecurityWeek; CSA Research Note (May 2026)
• Trend Micro, "Update on Exposed MCP Servers: The Threat Widens to the Cloud" (April 28, 2026)
• Phoenix Security, "Miasma: The Worm That Lives Inside Your AI Tools" (June 2026); HeroDevs; CSA Research Note on Miasma (June 2026)
• Check Point Research, "Cursor MCPoison" (CVE-2025-54136); Adversa.ai, "TrustFall" (May 2026); CSA Research Note on MCP Auto-Execution (July 2026)
• Splunk Advisory SVD-2026-0808 (August 19, 2026); SentinelOne; The Hacker Wire
• LiteLLM Security Update (CVE-2026-30623); Forkast News (October 2026)

#MCP #AIsecurity #supplychain #devsecops #zeroday