MCP Server Security: A Practical Guide for 2026

MCP servers connect your AI assistant to external tools and data. That connection is powerful — and risky. Every MCP server you install becomes a bridge between an AI model and your systems: your databases, your files, your cloud infrastructure.

We’ve reviewed 19 MCP servers across every major category. Along the way, we found SQL injection vulnerabilities, SSRF bugs, prompt injection attacks, and servers that store credentials in plaintext. Meanwhile, the vulnerability count keeps climbing: the first quarter of 2026 alone saw critical CVEs in Atlassian MCP (unauthenticated RCE), AWS MCP (command injection), and FastMCP (SSRF/path traversal). This guide distills what we’ve learned into practical security advice.

Why MCP Security Matters More Than You Think

When you install a traditional CLI tool, it does what you tell it. When you install an MCP server, an AI model decides what it does. The model interprets natural language, picks tools, and constructs arguments — all without you specifying exact commands.

This creates a new threat surface:

The AI can be tricked. Prompt injection can cause an agent to call tools in unintended ways.
Permissions compound. If your agent has access to both a file system server and a web server, a prompt injection in fetched web content could lead to file operations.
Servers trust their callers. Most MCP servers assume the client is well-behaved. There’s no built-in mechanism to verify that a tool call reflects genuine user intent.

OWASP recognized these risks by publishing a dedicated MCP Top 10 and two practical guides: one for using third-party servers and one for building secure servers.

The Three Security Questions

Before installing any MCP server, ask:

What can it access? A database server can read your data. A file system server can read your code. A web fetch server can reach internal network addresses. Know the blast radius.
Who authenticates? Is it using OAuth with scoped tokens, or a long-lived API key pasted into a JSON config file? How are credentials stored?
What happens if the AI makes a mistake? If the model hallucinates a tool argument or gets prompt-injected, what’s the worst-case outcome? Can it delete data? Send messages? Execute arbitrary SQL?

Authentication: The Shift to OAuth 2.1

The MCP ecosystem is in the middle of a major authentication transition. The June 2025 spec revision formalized MCP servers as OAuth 2.1 Resource Servers, separating them from authorization servers entirely. The November 2025 revision made PKCE mandatory for all clients.

What this means in practice:

Remote servers (the new standard) — hosted by the vendor, authenticate via OAuth in the browser. No tokens on disk, short-lived sessions, revocable access. Examples from our reviews: Sentry (at mcp.sentry.dev), Neon (at mcp.neon.tech), Supabase (at mcp.supabase.com), Slack (at mcp.slack.com), Vercel (at mcp.vercel.com).

Local servers (legacy pattern) — run as a subprocess on your machine, often configured with API keys or tokens in claude_desktop_config.json or similar files. These tokens are long-lived, stored in plaintext, and often over-scoped. Examples: GitHub MCP (Personal Access Token), Brave Search (API key), EverArt (API key).

The transition isn’t complete. Some servers like Notion offer both: a local server with integration tokens (being sunset) and a remote OAuth server. Others like Filesystem MCP and Memory MCP are inherently local and don’t need external auth — but lack other controls.

What Good Authentication Looks Like

Feature	Good	Bad
Token lifetime	Short-lived, auto-refreshing	Long-lived, never expires
Storage	In-memory or secure keychain	Plaintext in JSON config
Scope	Minimal — only what’s needed	Full account access
Revocation	One-click in provider dashboard	Requires token regeneration
Rotation	Automatic	Manual

The best example we reviewed: Supabase MCP uses OAuth 2.1 at mcp.supabase.com, requires no PAT, and provides a real PostgreSQL read-only role (not just client-side filtering). The worst: PostgreSQL MCP (archived) accepted raw connection strings with no access controls at all.

Real Vulnerabilities We Found

These aren’t theoretical. We discovered these while reviewing production MCP servers:

SQL Injection — PostgreSQL MCP Server

The PostgreSQL MCP server claimed read-only protection by wrapping queries in a transaction. But multi-statement SQL bypasses this entirely:

SELECT 1; COMMIT; DROP SCHEMA public CASCADE; --

The server executes the COMMIT, ending the read-only transaction, then runs the destructive command. This server was archived in May 2025 with no patch — yet it still gets 21,000 weekly npm downloads.

Lesson: Client-side SQL safety is not real safety. Use database-level roles with restricted permissions, like Supabase’s read-only PostgreSQL role.

SSRF — Fetch MCP Server

The Fetch MCP server has no protection against Server-Side Request Forgery. An agent can fetch internal addresses:

http://169.254.169.254/latest/meta-data/  (AWS metadata)
http://localhost:8080/admin                (local services)
http://10.0.0.1/                           (internal network)

This was formally assigned CVE-2025-65513 (CVSS 9.3, Critical) in December 2025, confirming that the is_ip_private() function fails to properly validate private IP addresses. A fix (PR #3180) was proposed but still hasn’t been merged as of April 2026 — over a year after disclosure.

Lesson: Any tool that makes HTTP requests needs URL validation. Block private IP ranges, cloud metadata endpoints, and localhost by default.

Prompt Injection — Context7 MCP Server

Context7 had a “ContextCrush” vulnerability: anyone could register libraries on the platform with malicious instructions embedded in documentation. When an agent fetched those docs, the injected prompts could instruct it to read .env files, exfiltrate credentials, or delete files.

The vulnerability was patched within five days of disclosure (reported Feb 18, fixed Feb 23, 2026). But it illustrates an architectural risk: any centralized registry that feeds content to AI agents is a prompt injection target.

Lesson: Treat all external content as untrusted input. Centralized registries need content scanning and sandboxed execution.

MCPwnfluence — Atlassian MCP Server (April 2026)

The most impactful MCP vulnerability of 2026 so far. CVE-2026-27825 (CVSS 9.1) and CVE-2026-27826 (CVSS 8.2) form an unauthenticated SSRF-to-RCE chain in mcp-atlassian, the most widely used Atlassian MCP server (4+ million downloads). Researchers at Pluto Security demonstrated that anyone on the same local network could execute code as root by sending two HTTP requests — no authentication required.

The attack chain works because: (1) the server honors attacker-controlled X-Atlassian-Confluence-Url headers without validation (SSRF), and (2) the Confluence attachment downloader writes files to attacker-specified paths without restricting them to a safe base directory. Combined, an attacker redirects attachment requests to their own server and writes a malicious payload to ~/.bashrc or ~/.ssh/authorized_keys.

Fix: Upgrade to mcp-atlassian >= 0.17.0. Lesson: Never trust HTTP headers for routing decisions, and always validate file write paths against a safe base directory.

Command Injection — AWS MCP Server (April 2026)

CVE-2026-5058 (CVSS 9.8) is a critical command injection in aws-mcp-server, disclosed April 11, 2026. The flaw exists in the handling of the allowed commands list — a user-supplied string is passed directly to a system call without proper validation. No authentication is required for exploitation.

Lesson: Any MCP server that executes system commands must sanitize inputs. The 30+ CVEs filed in early 2026 showed that 43% of MCP vulnerabilities are shell injection — this remains the single most common MCP vulnerability class.

SSRF & Path Traversal — FastMCP (April 2026)

CVE-2026-32871 (CVSS 9.9) affects FastMCP’s OpenAPI Provider. Path parameters are substituted into URL templates without URL-encoding, allowing ../ directory traversal to escape the intended API prefix and reach arbitrary backend endpoints — with the authorization headers configured in the MCP provider. Fixed in FastMCP >= 3.2.0.

Lesson: URL construction in MCP servers must use proper encoding. When an MCP server proxies requests to backend APIs, a path traversal becomes an authenticated SSRF — the attacker inherits the server’s credentials.

Security Checklist for MCP Servers

Use this when evaluating any MCP server:

Authentication & Authorization

Uses OAuth 2.1 or scoped API tokens (not full-access keys)
Credentials are not stored in plaintext config files
Tokens are short-lived with automatic refresh
Permissions follow least-privilege principle
Access can be revoked without regenerating all credentials

Data Protection

Connections use TLS/HTTPS
Local data storage is encrypted (if applicable)
No sensitive data logged to stdout/stderr
Supports read-only modes for exploration

Input Validation

SQL queries use parameterized statements (for database servers)
URLs are validated against SSRF attacks (for web/fetch servers)
File paths are validated against directory traversal (for filesystem servers)
External content is treated as untrusted (for documentation/registry servers)

Operational Security

Rate limiting is documented and enforced
Error messages don’t leak sensitive information
Server is actively maintained (check last commit date, open issues)
Known vulnerabilities are patched promptly

Supply Chain

Server is from a known publisher (official vendor or established maintainer)
Package integrity can be verified (signed releases, checksums)
Dependencies are regularly updated
Server code is open source and auditable

How Our Reviewed Servers Stack Up

We rated the security posture of all 19 servers we’ve reviewed, from strongest to weakest:

Strong Security

Supabase MCP (4/5) — The best security model we reviewed. Real PostgreSQL read-only role, feature group filtering, OAuth 2.1, project-level scoping. Their approach to read-only mode sets the standard: it’s a database-level restriction, not client-side filtering.

Sentry MCP (4/5) — OAuth-first design, organization scoping, 748+ issues suggest thorough real-world testing. First-party remote server with enterprise compliance options.

Slack MCP (4/5) — Granular OAuth scopes, admin oversight, audit logging. The scope model lets you limit access to specific channels and operations.

Neon MCP (4/5) — OAuth remote server, project-level scoping, branch-based workflow means mistakes are isolated to branches. Deprecated their less-secure local API key approach.

Vercel MCP (3.5/5) — Client allowlisting prevents confused deputy attacks. OAuth at mcp.vercel.com with project-specific URLs.

Adequate Security

GitHub MCP (4/5) — Toolset-based enablement, active maintenance. But PAT scoping is confusing and tokens are long-lived in config files. Rate limiting is invisible to agents.

Brave Search MCP (4/5) — API key auth but well-scoped (search-only). Tool filtering via environment variables. Privacy-first: queries aren’t fed to ad models.

Filesystem MCP (4/5) — Directory allowlisting at startup is a clean model. But no per-agent segmentation and no encryption of accessed files.

Playwright MCP (4.5/5) — Zero-config with optional auth state persistence. Browser sandbox provides isolation. But saved auth state is plaintext JSON.

Notion MCP (3.5/5) — Transitioning to OAuth remote server. But tokens expire frequently (3+ times/week per Issue #225), and there’s no easy database-level scoping.

Figma Dev Mode MCP (3.5/5) — OAuth remote server with aggressive rate limiting (6 calls/month free tier). The rate limiting, while frustrating, provides a natural security boundary.

Weak Security

Memory MCP (3.5/5) — Plaintext JSONL file on disk with no encryption, no access controls, no isolation between contexts. Fine for personal use; dangerous for anything shared.

Fetch MCP (3/5) — Unpatched SSRF vulnerability. No URL allowlisting. Use the community alternative zcaceres/fetch-mcp for SSRF protection.

Context7 MCP (3.5/5) — ContextCrush patched, but centralized registry architecture is inherently a prompt injection target. Rate limits slashed 83% in January 2026.

SQLite MCP (3/5) — No parameterized queries, no encryption, development-only. Archived but still useful for local prototyping.

EverArt MCP (2.5/5) — Archived, API key auth, minimal documentation. Don’t use in production.

Dangerous

PostgreSQL MCP (2.5/5) — Do not use. Exploitable SQL injection vulnerability, archived with no patch. Switch to Postgres MCP Pro or use Supabase MCP or Neon MCP instead.

Best Practices for MCP Users

1. Prefer Remote OAuth Servers

When a vendor offers both a local server (with API keys) and a remote server (with OAuth), choose the remote server. It eliminates plaintext credentials, provides automatic token rotation, and gives the vendor visibility into usage patterns for abuse detection.

2. Scope Permissions Down

Don’t give a GitHub MCP server full repo access if you only need pull request management. Don’t connect Supabase MCP to your production project when you’re exploring. Use the narrowest permissions that let you do your work.

3. Isolate by Context

Run different MCP servers for different projects. Don’t use one Memory MCP instance across all your work. Don’t connect your production database server and your web browsing server to the same agent session — a prompt injection from the web could reach your database.

4. Use Read-Only Modes

Start with read-only access and escalate only when needed. Supabase’s read_only=true is the gold standard here — it’s enforced at the database level. For other servers, check if they offer equivalent restrictions.

5. Audit Regularly

Check which MCP servers are configured in your client (Claude Desktop, Cursor, etc.)
Review the scopes and permissions each server has
Remove servers you’re no longer using
Update servers that have security patches
Check that archived servers haven’t been replaced by safer alternatives

6. Watch for Red Flags

Be cautious of MCP servers that:

Haven’t been updated in 6+ months
Have open security issues with no response
Require full admin/root access to function
Store credentials in plaintext with no alternative
Are the only maintainer’s side project with no community review

The Shadow IT Problem

Qualys warned in March 2026 that MCP servers are becoming a new form of shadow IT in enterprises. Servers bind to localhost on random ports, started as experiments, and quietly became production dependencies — without formal security review or ownership.

The risks go beyond the servers themselves:

Reconnaissance exposure. Even a read-only MCP endpoint leaks internal system names, tool schemas, resource paths, and namespace structures. An attacker who discovers an MCP server gets a map of what it connects to.
Execution surface. If an agent can be prompt-injected, every tool the server exposes becomes an attack vector — opening tickets, triggering deployments, running queries, changing configurations.
Static credentials at scale. Qualys cites research showing 53% of servers rely on static secrets, creating systemic risk across downstream systems. The CVE pace confirms this: 30+ CVEs in the first 60 days of 2026, with critical RCE chains like MCPwnfluence (4M+ downloads affected) demonstrating real-world exploitation potential.
No inventory. Most organizations don’t know how many MCP servers are running, who started them, or what they connect to.

The MCP Dev Summit 2026 dedicated its largest track (23 sessions) to security and operations, reflecting how central this concern has become. Key sessions covered mix-up attacks, host-layer security, and real-world MCP server exploitation.

What Organizations Should Do

Qualys recommends a four-step operational playbook:

Clarify ownership. Distinguish production MCP deployments from experiments. Assign an owner to each.
Map exposure. Understand network accessibility and segmentation gaps — which servers are reachable from where?
Enforce authentication. Separate discovery privileges from invocation privileges. Don’t let unauthenticated clients call tools.
Implement observability. Log tool invocations, monitor for anomalous patterns, and alert on unexpected server launches.

Tool Poisoning: The Hidden Threat

Tool poisoning is a specialized form of prompt injection where malicious instructions hide inside MCP tool metadata — descriptions, parameter names, and even tool outputs. The AI model follows these instructions while the user sees nothing unusual. Researchers at Invariant Labs and CyberArk have demonstrated working attacks that exfiltrate SSH keys, redirect emails, and steal credentials from Claude Desktop and Cursor.

This is serious enough that OWASP lists it as MCP03 in their MCP Top 10. Invariant Labs (an ETH Zurich spin-off acquired by Snyk in June 2025) built mcp-scan — now rebranded as Snyk Agent Scan (v0.4.13, April 2026) — a dedicated scanner that detects tool poisoning, rug pulls, and cross-origin escalation. With 2,000+ GitHub stars, it remains the most widely adopted MCP security scanner.

We’ve written a full deep-dive: MCP Tool Poisoning Attacks: How They Work and How to Defend Against Them covers five attack vectors (description poisoning, tool shadowing, full-schema poisoning, output poisoning, and rug pulls), the research behind them, and a practical defense checklist.

What’s Next for MCP Security

The protocol is maturing rapidly. The November 2025 spec revision mandated PKCE for all clients and introduced Client ID Metadata Documents for standardized registration. OWASP’s MCP Top 10 gives the ecosystem a shared vocabulary for risks.

New Security Infrastructure (2026)

Several major developments are closing the gaps:

MCP maintainer team expanded (April 2026) — Den Delimarsky was promoted to Lead Maintainer alongside David Soria Parra, with Clare Liguori joining as Core Maintainer. Delimarsky co-authored the authorization specification and brought RFC 8707 Resource Indicators into the spec — his promotion signals that auth and security are now first-class priorities in MCP governance.

CoSAI MCP Security white paper (January 2026) — The Coalition for Secure AI, an OASIS Open project, released a comprehensive threat taxonomy: 12 core threat categories and nearly 40 individual threats, organized into three tiers (MCP-specific, MCP-contextualized, and conventional). This gives security teams a structured framework for MCP risk assessment.

Microsoft internal MCP governance — Microsoft Digital and its CISO team are enforcing MCP governance at enterprise scale: mandatory server inventory, drift monitoring, and the principle that “every server, regardless of where it’s running, must be accounted for.” Their Agent Governance Toolkit (open source, April 2026) provides seven packages for zero-trust identities and runtime isolation.

Remaining Gaps

Progress notwithstanding, there’s still no standard for:

Per-tool authorization — you can’t grant access to read_file but not write_file within the same server at the protocol level
Audit logging — no standard format for recording which tools were called, with what arguments, by which agent
Content integrity — no way to verify that a server’s responses haven’t been tampered with

Until these gaps close, the responsibility falls on users and server developers to implement security at the application level. The checklist above is a starting point. Our individual reviews go deeper on each server’s specific security posture.