Anthropic published the Model Context Protocol specification in November 2024, and within eighteen months it became the default way AI agents connect to external tools, databases, and APIs — with reference servers, thousands of community implementations on GitHub and npm, and native support in Claude Desktop, Cursor, Windsurf, and VS Code. Adoption outran security review. In June 2025, Oligo Security disclosed CVE-2025-49596, a 9.4-severity remote code execution flaw in Anthropic's own MCP Inspector tool. The following month, JFrog disclosed CVE-2025-6514, an OS command injection bug in mcp-remote, a proxy package with hundreds of thousands of downloads. Both bugs trace to the same root cause: MCP servers run with the same trust and file-system access as the agent or developer invoking them, and the protocol's early versions shipped without mandatory authentication. This piece breaks down where MCP servers actually fail in production, walks through the vulnerability classes security teams are seeing, and outlines what a defensible MCP security posture looks like in 2026.
What is MCP, and why does it expand an organization's attack surface?
MCP is an open protocol, introduced by Anthropic in November 2024, that lets LLM-based agents call external "tools" exposed by MCP servers over stdio or HTTP/SSE — and it expands attack surface because every connected server becomes a code-execution and data-access channel the agent trusts by default, with no sandboxing implied by the spec itself. The architecture has three parts: a host application (Claude Desktop, an IDE, a custom agent), a client embedded in that host, and a server that exposes tools, resources, and prompts. Popular reference and community servers cover filesystem access, GitHub, Slack, Postgres, and Google Drive. Local (stdio) servers run as a subprocess inheriting the full permissions of the user account that launched them — meaning a compromised or malicious npm package invoked via npx -y @some/mcp-server can read SSH keys, cloud credentials in ~/.aws, or browser cookie stores without any additional prompt. Remote (HTTP/SSE) servers add a second dimension: network exposure, which is exactly what turned the two 2025 CVEs from local bugs into remotely triggerable ones.
What are the most common vulnerabilities found in MCP servers?
Five vulnerability classes account for most real-world MCP findings: tool poisoning and "rug pull" description swaps, OS/command injection, missing or optional authentication on remote transports, path traversal in filesystem-style servers, and credential leakage through environment variables, logs, or verbose error messages. Invariant Labs' April 2025 research demonstrated tool poisoning against a live MCP deployment by hiding model-directed instructions inside a tool's description field rather than its code — the function itself did nothing malicious, but the text an LLM reads before calling it did. Separately, audits of MCP servers published to npm and PyPI through 2025 repeatedly found tool handlers that concatenate untrusted arguments (file paths, shell arguments, SQL fragments) directly into exec(), eval(), or subprocess calls, the same class of bug that produced CVE-2025-6514 in mcp-remote. Because MCP tool arguments are generated by an LLM rather than typed by a human, traditional input-validation assumptions about "who controls this string" no longer hold.
How did CVE-2025-49596 turn a testing tool into a remote-code-execution risk?
CVE-2025-49596 let a remote attacker execute arbitrary code on a developer's machine simply by getting them to load a malicious web page while MCP Inspector's local proxy was running, because Inspector bound its proxy to 0.0.0.0 without authentication and was vulnerable to DNS rebinding and cross-site request forgery. MCP Inspector is Anthropic's own visual debugging tool for testing MCP servers during development, and by default it opened an unauthenticated SSE endpoint on a local port. Oligo Security's June 2025 disclosure showed that any page opened in the same browser session — no phishing link required beyond a normal ad or compromised site — could script a request to that endpoint, rebind DNS to reach the local proxy, and chain into the underlying test server's shell-execution tool for a CVSS 9.4 RCE. Anthropic patched the flaw in version 0.14.1 by adding a session token and origin validation. The lesson generalizes: any MCP server or proxy that binds to all interfaces "for convenience" during local development is one browser tab away from remote exploitation.
What is tool poisoning, and why do rug-pull updates make it worse?
Tool poisoning is an attack where the description text an MCP server returns for a tool — not the tool's actual code — contains hidden instructions that manipulate the calling LLM into taking unintended actions, and rug-pull updates make it worse because a server can silently change that description after a user has already approved the tool, with no re-review triggered in most clients. In Invariant Labs' April 2025 proof of concept, a benign-looking "add two numbers" tool shipped a description containing invisible text instructing the model to also read ~/.ssh/id_rsa and pass its contents as an unused parameter on every call — the tool still added the numbers correctly, so the exfiltration went unnoticed in normal use. Because most MCP clients grant approval once per tool name and never diff description text on subsequent connections, a server operator (or anyone who compromises the server's supply chain) can push an updated description weeks after approval and the client will execute it without a new consent prompt. Researchers have also documented "tool shadowing," where one connected server's tool description instructs the model to alter how it calls a completely different, trusted server's tools — meaning the blast radius of one poisoned server extends to every other tool the agent has access to in that session.
How should security teams secure MCP deployments in 2026?
Security teams should treat every MCP server as a distinct, versioned software dependency — inventory it, pin it, sandbox it, and monitor its runtime calls — rather than trusting its self-reported manifest or tool descriptions. In practice that means five concrete controls. First, pin exact server versions and package hashes instead of the common npx -y @vendor/mcp-server pattern, which silently pulls whatever the latest published version is at connection time. Second, run stdio servers inside a locked-down container or seccomp/AppArmor profile with no outbound network access unless the server's function explicitly requires it, so a poisoned tool can't exfiltrate data even if it executes. Third, require OAuth 2.1 for remote/HTTP servers — added to the MCP specification in its 2025-06-18 revision — instead of long-lived static bearer tokens embedded in config files. Fourth, log every tool call, its arguments, and the description text presented to the model at call time, so a rug-pull description change is detectable in an audit trail even if it wasn't blocked in real time. Fifth, re-diff and re-review tool descriptions on every server update before allowing auto-approval to carry forward, since a byte-for-byte unchanged tool name can hide a materially different set of instructions.
How Safeguard Helps
Safeguard extends the same supply-chain rigor security teams apply to open-source dependencies to the MCP servers agents now depend on. Reachability analysis determines whether a vulnerable code path in a given MCP server package — like the injection pattern behind CVE-2025-6514 — is actually invoked by the tool definitions an agent can call, so teams triage the servers that matter instead of chasing every CVE in a dependency tree. Griffin AI correlates CVE data, tool-description changes, and package provenance to flag rug-pull-style updates and explain exploitability in plain language, tuned to how a specific MCP integration is deployed. Safeguard generates SBOMs for MCP servers and their transitive npm/PyPI dependencies, and ingests SBOMs from vendor-supplied servers, so version drift and unpinned npx -y installs show up before they ship. When a fix is available, Safeguard opens an auto-fix pull request pinning the server to the patched release, keeping the security team out of the loop on routine version bumps while preserving review for anything unusual.