Security researchers at CloudSEK say a single unprotected AI tool server, left exposed to the internet with no login required, gave attackers a clear path to steal live Amazon Web Services (AWS) credentials and potentially take over a company's entire cloud environment. The server ran the Model Context Protocol (MCP), an emerging standard that lets AI agents discover and call external tools on their own, and it published its full list of available tools to anyone who asked. CloudSEK detailed the findings in a case study drawn from its AIVigil attack-surface platform, describing the affected system as an MCP endpoint built into a Spring Boot application that powered a customer's AI-driven voice and messaging service.
What's affected
The problem is not a flaw in one product but a configuration and design failure that CloudSEK warns is widespread. Because MCP is meant to let AI agents find and run tools dynamically, many deployments ship with no authentication at the protocol layer and no input checks on the tools themselves. In its broader research, CloudSEK found that roughly 82% of exposed MCP tooling performs file-system operations prone to path traversal (a weakness tracked as CWE-22), and about 67% expose programming interfaces tied to code injection (CWE-94). The pattern matches a growing list of MCP problems, including the CVE-2025-68143, CVE-2025-68144, and CVE-2025-68145 remote-code-execution chain in a reference MCP Git server, and the CVE-2025-54136 "MCPoison" issue in the Cursor code editor. IntelFusions has covered the same class of exposure in its reporting on MCP server security and a zero-click attack in Cursor IDE.
How the attack works
CloudSEK traced a four-step chain. First, the server answered standard protocol commands (initialize, tools/list, and tools/call) with no credentials, so any outsider could list every tool, resource, and prompt it offered. Second, one of those tools, an audio downloader, accepted any web address without checking it. Pointing it at the AWS internal metadata service at 169.254.169.254 returned a working proxy into that endpoint, a classic server-side request forgery (SSRF), where a server is tricked into making requests on the attacker's behalf. Third, the same proxy also accepted the file:// scheme, turning SSRF into local file inclusion (reading files off the server). The researchers pulled /proc/self/environ and recovered plaintext database passwords stored as environment variables. Finally, querying the metadata service through the proxy returned live, temporary AWS IAM credentials, which CloudSEK assesses could enable full compromise of the cloud environment and movement across connected resources. The same unauthenticated tools also exposed telephony functions that could be abused at scale for spam, phishing, and premium-rate fraud, and leaked phone numbers, call records, and message metadata. No CVE was assigned to this specific deployment, which CloudSEK anonymized.
What you should do
CloudSEK recommends enforcing authentication on every MCP endpoint at the protocol layer, using API keys or bearer tokens. Any proxy or fetch tool should be limited to an explicit list of allowed domains, with the file://, dict://, and gopher:// schemes blocked along with internal ranges such as 169.254.0.0/16. On AWS, requiring IMDSv2 on EC2 forces metadata requests to carry a session token, closing the SSRF path used here. Organizations that may have been exposed should rotate affected credentials right away, review CloudTrail logs for unusual metadata or API access, and put newly deployed AI components under continuous attack-surface monitoring. The takeaway, CloudSEK argues, is to treat an MCP endpoint as a privileged, internet-facing API rather than an internal convenience. The same caution applies to browser-based AI tooling, where over-broad permissions create a similar exposure.
This briefing is provided by IntelFusions for informational and defensive purposes only. It is based on sources assessed to be reliable at the time of writing, and analytic judgments carry the confidence levels indicated. IntelFusions is not affiliated with the organizations named and makes no warranty as to completeness or accuracy.