Background: MCP and the Expanding AI Attack Surface

The Model Context Protocol (MCP), introduced by Anthropic in November 2024, provides a standardized interface for AI assistants to interact with external tools, data sources, and APIs. It is now the de facto integration layer for connecting LLM-based agents to databases, version control systems, cloud infrastructure, and enterprise business-logic tools. Adoption has been rapid: over 13,000 MCP server implementations were created on GitHub in 2025 alone [1], with the protocol adopted across every major IDE, AI assistant, and automation platform by early 2026.

This rapid growth has outpaced security maturity by a significant margin. An analysis of 2,614 MCP implementations found that 82% use file system operations prone to path traversal (CWE-22), 67% use APIs related to code injection (CWE-94), and 34% are susceptible to command injection (CWE-78) [2]. Internet-wide scans have identified over 8,000 MCP servers exposed to the public internet [3]. Knostic independently mapped 1,862 exposed MCP servers via Shodan and found all 119 manually verified servers granted unauthenticated access to internal tool listings [5]. BlueRock Security analyzed over 7,000 MCP servers and found 36.7% vulnerable to SSRF [6].

Between January and February 2026 alone, over 30 CVEs targeting MCP servers, clients, and infrastructure were filed [7]. Notable disclosures include a CVSS 9.6 remote code execution flaw in mcp-remote (downloaded nearly half a million times), the Anthropic mcp-server-git three-CVE RCE chain (CVE-2025-68143, CVE-2025-68144, CVE-2025-68145), the postmark-mcp npm package backdoor (the first confirmed in-the-wild malicious MCP server, September 2025), and MCPoison persistent code execution in Cursor IDE (CVE-2025-54136). MCP is no longer experimental infrastructure. It is the connective tissue of enterprise AI, and it is a serious target.

Google Threat Intelligence Group (GTIG) confirmed in early 2026 that adversaries, including nation-state actors from China, Iran, and North Korea, have operationalized LLMs and MCP infrastructure as force multipliers for reconnaissance, initial access, and credential theft [8].

The finding described in this case study is a real-world instance of this attack pattern, discovered through CloudSEK AIVigil’s continuous AI attack surface monitoring across our customer dataset. All identifying details have been masked.

The New Blind Spot in Enterprise Security

Enterprises are deploying MCP servers, AI agents, and LLM-integrated workflows at scale. The security controls that cover traditional web applications and APIs are not keeping pace with this new layer. The result is a growing class of AI-native attack surfaces that are publicly reachable, functionally powerful, and almost entirely invisible to conventional security tooling.

CloudSEK’s AIVigil is built precisely for this gap. As part of ongoing AI attack surface monitoring across our customer dataset, AIVigil identified a critical-severity finding in one customer’s environment: a fully unauthenticated MCP server with exposed internal tools that chained into SSRF, LFI, and the exfiltration of live AWS IAM credentials and database secrets. All details identifying the customer, their assets, and associated infrastructure have been masked. This is one of several such findings being surfaced in the weeks leading up to AIVigil’s general availability.

The AI Tech Stack: What Was Running and Why It Was Targeted

The MCP server was deployed as part of a Spring Boot application integrating AI-driven voice and messaging capabilities into a customer-facing communications platform. The exposed toolset reveals the underlying AI architecture clearly.

The server registered tools for voice call management, SMS dispatch, audio content processing, number metadata retrieval, and call callback handling. This is consistent with a telephony or communications platform augmented with LLM-powered automation, a stack that is common in fintech, SaaS, and enterprise telecommunications verticals. The audio download utility was almost certainly designed for AI-driven media processing pipelines where models need to fetch, transcribe, or analyze remote audio content.

This class of AI deployment is a high-value target for two reasons. First, telephony and communications platforms hold significant PII (call records, phone numbers, message metadata) that has direct value for fraud, phishing infrastructure, and identity theft operations. Second, the cloud IAM credentials associated with such platforms typically carry broad permissions across messaging, storage, and compute services, making them attractive for cloud-pivot attacks.

The deployment pattern also points to a common architectural vulnerability in AI-augmented applications: developer teams integrate MCP tooling to accelerate LLM capabilities without applying the same authentication discipline required for traditional API endpoints. The MCP server’s tool definitions followed standard JSON-RPC patterns but lacked any authentication middleware, OAuth scoping, or rate limiting at the protocol layer. This is consistent with the Endor Labs finding that 38 to 41% of surveyed MCP implementations had no authentication mechanism at all [2].

The Discovery

AIVigil’s continuous AI asset discovery engine flagged an exposed MCP server endpoint during routine scanning of the customer’s external AI attack surface. The endpoint was active, responding to standard MCP protocol requests, and required no authentication whatsoever: no API keys, no session tokens, no bearer credentials.

What made this finding particularly dangerous was not just the absence of authentication. It was what the server exposed once inside: a full listing of internal tools, resources, and prompts built into the AI workflow. Among the tools available was a utility designed to fetch and proxy audio content, a seemingly innocuous capability that became the foundation for a critical exploit chain.

The Exploit Chain: A Technical Walkthrough

Step 1: Unauthenticated Tool Enumeration

With no authentication barrier, any external actor interacting with the MCP endpoint could enumerate every available tool, resource definition, and prompt registered with the server. Standard MCP protocol methods (initialize, tools/list, tools/call) all responded without requiring any credentials. This level of exposure gives an attacker a complete operational picture of the AI system’s capabilities before a single malicious request is made.

Tools listed on the unauthenticated MCP server, accessible with no credentials

Tool execution response confirmed without any authentication

Step 2: SSRF via Unvalidated Audio Proxy

The audio download utility accepted an arbitrary URL as input and returned a proxied response, by design, for fetching remote media. What it lacked was any form of input validation or domain allowlisting. When probed with an AWS Instance Metadata Service (IMDS) address (http://169.254.169.254/), the utility responded normally, returning a JSON payload that included a direct proxy link back through the server.

Following that link caused the server to make an outbound request to the IMDS endpoint on the attacker’s behalf, confirming full Server-Side Request Forgery. The SSRF yielded live AWS IAM role credentials associated with the server’s cloud identity.

This pattern maps directly to documented exploitation campaigns. F5 Labs tracked an active SSRF-to-IMDS campaign targeting EC2-hosted applications throughout March 2025 [9]. CVE-2025-51591 is a dedicated SSRF-to-IMDS CVE that explicitly identifies this as a critical cloud attack vector [10]. Most recently, CVE-2026-33626 in LMDeploy’s AI inference module demonstrated the identical pattern, with in-the-wild exploitation observed within 13 hours of disclosure [11]. The MCP attack surface makes this well-understood vector significantly more accessible: an attacker no longer needs to find a traditional SSRF bug in application code. An unauthenticated AI tool with an unvalidated URL parameter is sufficient.

AWS metadata URL sent as argument to the audio download tool, confirming the SSRF vector

Live AWS IAM credentials returned via the proxy endpoint

Step 3: Escalation to Local File Inclusion

The same proxy endpoint that enabled SSRF also accepted the file:// protocol without restriction. By modifying the URL parameter to reference internal filesystem paths, for example url=file:///proc/self/environ, an attacker could force the server to read and return local files from the host system.

Through this LFI path, the process environment file was successfully retrieved, containing plaintext database credentials stored as environment variables. The file:// vector turned a misconfigured audio tool into a direct window into the server’s internal state. This is consistent with the Datadog security audit finding that identified 12,000 API keys and passwords exposed through insecure MCP credential handling across surveyed deployments [12].

Local File Inclusion via file:// protocol: /etc/passwd contents exposed

Plaintext database credentials and internal configuration leaked via /proc/self/environ

Step 4: Compounding the Impact

The combination of unauthenticated access, unrestricted SSRF, and file:// LFI creates a compound attack path that extends well beyond the initial MCP server:

• IAM credentials retrieved via SSRF can be used to authenticate to AWS APIs, pivot to other cloud resources, and potentially assume broader permissions within the cloud environment.
• Database credentials exfiltrated via LFI, combined with separately exposed internal console access, create conditions for full read/write database access and, in some configurations, remote code execution on the host.
• Unauthenticated access to telephony and communication tools registered on the same server creates additional risk of platform abuse: spam, phishing, and toll fraud at the customer’s cost.

‍

Threat Actor Landscape: Who Is Targeting MCP Infrastructure

MCP servers have moved from a theoretical attack surface to an actively targeted one within 18 months of the protocol’s introduction. The five entries below represent the most directly relevant adversarial activity: confirmed actors and campaigns where MCP infrastructure was either the primary attack surface, the orchestration layer used to execute the intrusion, or the distribution vector for malicious tooling.

Why Traditional Security Tools Missed This

The finding was on an MCP server, a protocol tier that sits above traditional HTTP APIs and below the AI model layer. Conventional attack surface management platforms scan for exposed web applications and APIs. CSPM tools monitor cloud configuration drift. Neither category is designed to discover MCP servers, enumerate their tool registries, or assess whether those tools introduce exploitable proxy or file-read behaviors.

This is the visibility gap AIVigil was built to close. The AI attack surface is not an extension of the traditional attack surface. It is a distinct layer with its own exposure patterns, trust boundaries, and class of initial access vectors, all of which require dedicated discovery and assessment tooling. AIVigil identifies AI-layer initial access vectors and feeds them into CloudSEK Nexus AI, which correlates them with external threat signals, dark web activity, and third-party ecosystem risks to produce validated attack paths showing how an attacker would actually move from the MCP server through to cloud infrastructure.

What AIVigil Detected

• Asset discovery: AIVigil identified the publicly reachable MCP server endpoint as part of continuous external AI asset scanning, including enumeration of registered tools, resources, and prompts.
• Authentication assessment: The server was flagged as fully unauthenticated, with all standard MCP protocol methods accessible without credentials.
• Tool behavior analysis: The audio proxy utility was assessed for input validation gaps and flagged for its unrestricted URL scheme acceptance.
• SSRF and LFI probing: AIVigil’s active assessment engine confirmed SSRF reachability to the AWS IMDS endpoint and validated LFI via the file:// protocol path.
• Blast radius contextualization: The finding was enriched with impact context (exposed IAM roles, accessible telephony tools, and database credential exposure) to support prioritized remediation.

Impact Summary

Remediation Guidance

Enforce Authentication on All MCP Endpoints

Every MCP endpoint, including initialize, tools/list, and tools/call, must require authentication. Implement strict API key or Bearer token validation and reject all unauthenticated requests at the protocol layer, not just at the application layer. The MCP authorization specification provides a reference implementation for OAuth-based authentication [16].

Restrict and Validate Proxy Tool Inputs

Any tool that fetches or proxies remote content must enforce a strict allowlist of permitted domains and protocols. The file://, dict://, gopher://, and all non-HTTP schemes must be explicitly blocked. Internal IP ranges, including the link-local range used by AWS IMDS (169.254.169.254), must be excluded from reachable targets.

Enforce IMDSv2 on Cloud Instances

Upgrade EC2 instance configuration to require IMDSv2 strictly. IMDSv2 requires a PUT request with a session token before metadata can be retrieved, which neutralizes GET-based SSRF attacks targeting the metadata service. AWS confirmed this control blocked a September 2025 Pandoc-based IMDS exploitation campaign [9].

Rotate All Exposed Credentials Immediately

IAM credentials and any database credentials present in environment variables should be treated as compromised. Rotate and revoke immediately, and audit CloudTrail logs for any access that may have occurred during the exposure window.

Implement Continuous AI Attack Surface Monitoring

Point-in-time assessments will not catch newly deployed AI assets, updated tool registries, or incremental misconfigurations introduced during development cycles. CloudSEK AIVigil continuously monitors MCP servers, AI gateways, agentic workflows, and AI APIs, identifying AI-layer initial access vectors before they can be chained into executable attack paths.

Frequently Asked Questions

What is an unauthenticated MCP server?

An unauthenticated MCP server is a Model Context Protocol endpoint that responds to requests (including tool enumeration and tool execution) without requiring any credentials: no API keys, no session tokens, and no bearer authentication. All 119 MCP servers manually verified by Knostic in late 2025 granted unauthenticated access to internal tool listings. An unauthenticated MCP server gives any external actor a complete view of an AI system’s capabilities and the ability to call any registered tool before a single security control is applied.

What is SSRF in the context of MCP security?

Server-Side Request Forgery (SSRF) in an MCP context occurs when an AI tool accepts an arbitrary URL as input and makes an outbound request on behalf of the attacker without validating whether the destination is permitted. In this case study, an audio download utility accepted the AWS IMDS address as a valid URL input, causing the server to retrieve and return live AWS IAM credentials to the attacker. SSRF is present in 36.7% of analyzed MCP server deployments.

What is Local File Inclusion in an MCP exploit chain?

Local File Inclusion (LFI) in an MCP context occurs when a tool that proxies or fetches content also accepts the file:// protocol, allowing an attacker to read files directly from the server’s filesystem. In this case study, the same audio proxy tool that enabled SSRF also accepted file:// paths without restriction. This allowed retrieval of /proc/self/environ, which contained plaintext database credentials stored as environment variables on the host.

How does AIVigil detect unauthenticated MCP servers?

AIVigil’s continuous AI asset discovery engine scans for exposed MCP server endpoints as part of external AI attack surface monitoring. For each identified endpoint, AIVigil assesses authentication state, enumerates registered tools and resources, analyzes tool behavior for input validation gaps, and probes for SSRF and LFI exploitability. Findings are enriched with blast radius context (exposed IAM roles, credential access, data exposure) and fed into CloudSEK Nexus AI for attack path correlation.

Why do traditional security tools miss exposed MCP servers?

Traditional attack surface management and cloud security posture management tools were built for web applications, APIs, and cloud configurations. MCP servers operate at a distinct protocol layer that sits above traditional HTTP APIs and below the AI model. ASM tools do not enumerate MCP tool registries. CSPM tools do not assess whether an AI tool’s URL input validation creates an SSRF vector. Purpose-built AI attack surface monitoring is required to detect this class of exposure.

What should organizations do immediately if they have an exposed MCP server?

Organizations with exposed MCP servers should take five immediate steps: (1) enforce authentication on all MCP endpoints at the protocol layer; (2) restrict proxy tool inputs to an explicit allowlist of permitted domains and block all internal IP ranges; (3) require IMDSv2 on all EC2 instances to block SSRF-to-IMDS attacks; (4) rotate any IAM credentials and environment-variable secrets that may have been accessible; and (5) implement continuous AI attack surface monitoring to catch new exposures as the AI environment changes.

Conclusion

The vulnerability chain described here (unauthenticated MCP server, unrestricted proxy tool, SSRF to IMDS, LFI to credential exfiltration) is not a sophisticated zero-day attack. It is a straightforward exploitation of basic misconfiguration in a new class of infrastructure that most security programs have not yet caught up with.

As enterprises integrate AI agents, MCP servers, and autonomous workflows into their core operations, the AI attack surface will only expand. Each new tool registration, each new model integration, and each new agentic workflow is a potential new initial access vector. Nation-state actors and financially motivated eCrime groups have already operationalized AI infrastructure as both an attack tool and a target. The organizations that build AI fastest without securing the AI attack surface will be the ones that discover this the hardest way.

CloudSEK’s AIVigil continuously discovers, assesses, and triages AI-layer initial access vectors before they can be chained into infrastructure-wide compromise. AIVigil identifies attack paths across AI systems, AI-enabled applications, and model-serving APIs, and uses CloudSEK Nexus AI to correlate these signals with external threats, threat actor activity, and supply chain risks into validated attack graphs. This finding is one of many being surfaced across our customer dataset ahead of AIVigil’s general availability.

‍

References

[1] InstaTunnel, “Securing MCP Servers: The 2026 Guide to AI Tool Tunneling,” March 2026.

[2] Endor Labs, “Classic Vulnerabilities Meet AI Infrastructure: Why MCP Needs AppSec,” January 2026.

[3] r/cybersecurity community scan; Trend Micro, “MCP Security: Network-Exposed Servers Are Backdoors to Your Private Data,” 2026.

[4] OWASP Top 10 for LLM Applications, 2025.

[5] Knostic, “Exposing the Unseen: Mapping MCP Servers Across the Internet,” December 2025.

[6] BlueRock Security / Security Boulevard, “Anthropic, Microsoft MCP Server Flaws Shine a Light on AI Security Risks,” 2026.

[7] PipeLab, “The State of MCP Security 2026: Incidents, Attack Patterns, and Defense Coverage,” April 2026.

[8] Google Threat Intelligence Group (GTIG), “Adversaries Leverage AI for Vulnerability Exploitation, Augmented Operations, and Initial Access,” May 2026.

[9] F5 Labs, “Campaign Targets Amazon EC2 Instance Metadata via SSRF,” April 2025.

[10] CVE-2025-51591: SSRF Exploit Targeting AWS Instance Metadata Service, September 2025.

[11] CVE-2026-33626: LMDeploy SSRF in vision-language module, exploited in-the-wild within 13 hours of disclosure, April 2026.

[12] Datadog Security Research, credential exposure audit findings cited in DataStealth MCP Security Guide, 2026.

[13] CrowdStrike, “2026 Financial Services Threat Landscape Report,” May 2026.

[14] Darktrace, “Annual Threat Report 2026,” February 2026.

[15] Trend Micro, “Nation-Aligned APTs in 2025: AI-Fueled Threats and the Shifting Global Cyber Balance,” May 2026.

[16] MCP Authorization Specification: modelcontextprotocol.io/docs/tutorials/security/authorization.

[17] CloudSEK, “What is an AI Attack Surface?” cloudsek.com/knowledge-base/ai-attack-surface.

[18] CloudSEK, “AI Attack Surface Monitoring,” cloudsek.com/knowledge-base/ai-attack-surface-monitoring.