Field Report: Real MCP Servers and the Most Common Critical Vulnerabilities

Overview

This field report summarizes an active scan of 539 production MCP servers performed over three months to quantify how many live endpoints expose the top vulnerabilities identified in recent MCP security taxonomies. The goal is to move the discussion from theoretical rankings to observable real-world risk and provide practical mitigations for operators, developers, and security teams.

Scope and methodology

Scans targeted publicly reachable MCP endpoints only. Probes focused on authentication behavior, tool surface exposures that accept external input, and simple behavioral monitoring to detect dynamic changes. This is not an exhaustive penetration test of every server. It is a representative field observation of live MCP deployments and their most common failure modes.

Key finding 1 – Unauthenticated Access is widespread

201 out of 539 servers or 37.4 percent required no MCP-level authentication. These are live production endpoints reachable from the public internet and responding to MCP messages.

Observed patterns include:

• No auth (37.4 percent): startups, research projects, and internal tools accidentally exposed.
• API-layer auth only: MCP transport is open but underlying APIs return 401. This enables free enumeration of tools and endpoints and creates attack paths where credentials can later be phished or reused.
• Full MCP-layer auth: enterprise deployments that implement token or OAuth-style authentication at the transport layer.

Case note: one high-profile incident fits the API-layer-auth-only pattern. The MCP transport allowed enumeration and invocation of a large set of tools, even though subsequent API calls returned 401. Enumeration alone provides attackers reconnaissance and the potential to chain into credential theft.

Key finding 2 – Command injection and SSRF are present

Tool endpoints that accept arbitrary input create severe server-side risk. The scanner probed common risky tool primitives and observed exploitable patterns in development and some production targets.

• fetch_api(url, method, headers, body) can act as an open HTTP proxy and enable SSRF.
• scrape(url) triggers a browser fetch and can reach internal networks.
• exec(command) and run_script(code) provide direct command or script execution on some servers, mostly in development or misconfigured deployments.

These issues are not protocol vulnerabilities. They are insecure tool implementations exposed through MCP, often without sandboxing or input validation.

Key finding 3 – Rug pull and behavioral changes are hard to detect

Rug pull threats occur when a server changes tool behavior after initial review. Static scans cannot reliably detect these. Behavioral monitoring over time found cases of changing tool descriptions and capabilities that would evade a one-time scan. Continuous monitoring and provenance checks are required to detect this class of risk.

Context from recent industry reports and incidents

Multiple public disclosures and industry reports reinforce these observations. Vendors and researchers have reported real-world MCP-related incidents including repository vulnerabilities in open-source MCP implementations, automated scanners built to find MCP misconfigurations, and client-side code injection CVEs. Responsible operators should assume that both server-side tool flaws and client-side bugs exist in the ecosystem and that attackers are actively scanning for them.

Immediate mitigations

• Enable MCP transport authentication for all public endpoints. Token or OAuth at the transport layer prevents bulk enumeration.
• Harden tool inputs with strict validation, allowlist networking controls, and origin checks to prevent SSRF.
• Sandbox tools that execute code or shell commands. Use process isolation, runtime limits, and strict filesystem restrictions.
• Monitor behavior over time for tool description changes and unusual invocation patterns.

Medium and long term recommendations

• Adopt least privilege for tools that access credentials or internal systems. Limit tokens and scopes.
• Implement provenance and signing for tool manifests so clients can detect unauthorized changes.
• Patch management and disclosure processes: track CVEs and public disclosures for MCP implementations and client libraries, and respond quickly.
• Threat modeling for each exposed tool to identify SSRF, command injection, and data exfiltration risks before exposure.

Conclusion and action checklist

Real-world scans show that many of the top MCP vulnerabilities prioritized by industry taxonomies are present in the wild. The most immediate and impactful controls are to enforce authentication at the MCP transport, restrict tool inputs and capabilities, sandbox any code execution, and enable continuous monitoring for behavioral changes. Operators should assume active scanning and adopt multiple layers of defense including input allowlisting, network egress controls, and rapid patching procedures.

Action checklist

• Require transport-layer authentication on all public MCP endpoints.
• Audit every exposed tool for SSRF and command execution vectors.
• Sandbox or remove tools that execute arbitrary code or shell commands.
• Enable continuous behavioral monitoring for rug pull detection.
• Subscribe to vulnerability feeds and apply patches to MCP implementations promptly.

These practical controls reduce the most immediate risks observed across the 539-server dataset and align with recommendations from recent industry research and public disclosures.