Research From Static Findings to Working Exploits: Runtime Validation of 6 High-Profile MCP Servers March 28, 2026 AgentSeal Research 14 min 0 Static analysis of MCP servers produces findings. It does not confirm whether those findings are exploitable. This report evaluates that gap. Across 6 high-adoption MCP servers (68K+ combined GitHub stars), we find a 100% confirmation rate for testable critical and high severity findings under controlled runtime conditions. Previous reports covered the ecosystem-wide scan of 1,808 servers and toxic data flow analysis across 5,121 servers . Both were based on static analysis. This report documents the next step: runtime exploitation using controlled lab environments with planted test data. All source code referenced is from public GitHub repositories. Exploit reports are published on the registry where maintainers can review detailed findings. Scope and definitions MCP servers expose tools to AI agents. Some tools are designed to execute code, access files, or call APIs. When these tools are reachable by an AI agent that processes untrusted input from other sources, the execution primitive becomes an attack vector, even though the tool itself works correctly. We define this as the Agent-Mediated Exploitation Model : Untrusted Input (tool response, document, message) | v LLM Agent (processes input as context) | v prompt injection / tool poisoning Tool Invocation (agent calls exposed MCP tool) | v Execution Primitive (exec / eval / shell / API) | v System Compromise (credential theft, RCE, data exfiltration) The vulnerability is not the execution primitive itself, but the agent-mediated path that makes it reachable by untrusted input. This distinction is critical. We classify findings into two types: Security defects: Missing authentication, hardcoded cryptographic material, SSRF without egress filtering, blocklist-based input validation. These are implementation flaws regardless of agent context. Capability-inherent risks: exec(), eval(), terminal execution. These are intended features that become dangerous when exposed to agent-controlled input. Trust scores reflect this distinction. A security defect scores lower than an equivalent capability-inherent risk. A finding is considered exploitable if: (1) it is reachable via a public interface (HTTP, WebSocket, MCP stdio), (2) it requires no source code modification to trigger, and (3) it results in unauthorized data access, arbitrary code execution, credential extraction, or network pivot. The current state of the registry As of late March 2026, the registry contains 8,013 published MCP servers with completed analysis. Trust Level Score Range Count % SAFE 80-100 3,580 44.7% REVIEW 50-79 1,901 23.7% RISKY 20-49 1,644 20.5% DANGEROUS 0-19 888 11.1% 1,261 servers have deep findings from source-level analysis. The total deep finding count across the registry is 4,513: 1,067 critical, 1,795 high, 1,240 medium, and 399 low. 738 servers have at least one toxic data flow finding. The most common critical deep finding categories are command injection (114 instances), output instruction injection (32), path traversal (5), SSRF via unvalidated connection URLs (4), and sandbox escape via tool bridge (4). Target selection The registry contains 20+ servers with over 1,000 GitHub stars that scored below 50 (RISKY or DANGEROUS). These are not obscure projects. They include official tools from major platforms, popular development frameworks, and widely-used utility servers. Server Stars Trust Score Trust Level Deep Findings server-github 82,224 35 RISKY 6 monorepo (Daytona) 70,855 19 DANGEROUS 7 MindsDB 38,783 19 DANGEROUS 5 chrome-devtools-mcp 31,754 19 DANGEROUS 4 Playwright 28,686 35 RISKY 13 claude-flow 26,976 25 DANGEROUS 11 Serena 21,352 35 RISKY 10 blender-mcp 18,065 35 RISKY 8 n8n-mcp 16,520 38 RISKY 5 archon 13,766 35 RISKY 6 pipedream 11,179 35 RISKY 6 From this pool, 6 servers were selected for runtime exploitation based on three criteria: (1) high GitHub star count indicating widespread adoption, (2) active development with recent commits, and (3) deep findings that suggested specific, testable attack vectors rather than generic capability warnings. The 6 selected servers have a combined 68,305 GitHub stars. Methodology Test environment Each server was tested in isolation using one or more of three approaches, from weakest to strongest evidence: Approach 1: Docker container. The server's source code was cloned from GitHub and built into a Docker image. Only external dependencies that could not run locally (databases, third-party APIs) were mocked. All server routes, authentication logic, encryption implementations, and API endpoints ran unmodified. Approach 2: Native execution. The server was installed and run directly on a local machine using its documented setup process. This eliminates any concern that Docker networking or container isolation affected the results. Approach 3: Source verification against GitHub. For servers...