Update on Exposed MCP Servers: The Threat Widens to the Cloud

By Alfredo Oliveira (Senior Threat Researcher, TrendAI™ Research) and David Fiser (Senior Threat Researcher, TrendAI™ Research)

Key Takeaways

• As our research on exposed MCP servers deepens, we unearth concerning findings: the numbers surge to almost triple, attackers gain the ability to seize control of cloud services, and critical MCP server vulnerabilities emerge.
• Exposed MCP servers can leave the door wide open for vulnerability exploitation, credential theft, lateral movement, and in worst-case scenarios, full cloud compromise.
• As these servers act as bridges for artificial intelligence (AI) agents, organizations and individuals utilizing them should be wary of the unintended consequences of exposed MCP servers.
• To protect their systems, organizations must build a cloud-centric defense, beginning with treating MCP servers not only as experimental tools but as a critical part of the cloud infrastructure that requires proactive and robust security.

In our July 2025 publication, “MCP Security: Network-Exposed Servers Are Backdoors to Your Private Data,” we first raised the security risks of publicly exposed MCP servers. Our initial scan revealed 492 confirmed instances running without any basic security controls: no client authentication or traffic encryption. The behavior is alarming, since these servers are designed to act as universal connectors for AI agents, yet they have become open gateways to sensitive corporate data.

A few months later, the situation has not just worsened; it has evolved into a significant cloud security threat. Our latest research shows the number of exposed MCP servers has nearly tripled to 1,467. More alarmingly, these servers are becoming a powerful vector for direct attacks against cloud infrastructure. Attackers are no longer limited to merely accessing data linked to these MCP servers — they are now capable of compromising the cloud services that host them.

This article provides an update on our findings and explores a new frontier in MCP exploitation: the cloud. We explore our recently discovered vulnerabilities in cloud-specific MCP implementations, analyze real-world attack scenarios, and provide recommendations for organizations to defend against this escalating threat.

Key Findings: The Numbers Don't Lie

Our latest scan paints a grim picture of the MCP security landscape. The number of exposed servers has tripled, putting sensitive data and critical infrastructure at risk.

• 1,467 exposed MCP servers: An increase of nearly three times from our initial findings, indicating rapid and insecure adoption of MCP.
• 1,227 Legacy Server-Sent Events (SSE) servers: Most exposed servers are using the long-deprecated SSE transport, highlighting a widespread failure to adopt modern, more secure MCP implementations.
• Databases are at risk: We found the “execute_sql” tool on 70 hosts. The most prevalent tool that runs database queries turns MCP servers into open back doors to sensitive data.
• “Graphiti Agent Memory”: This agentic MCP server implementation, found on 39 hosts, is a prime target for attackers seeking to exfiltrate memory-resident data.
• Patient data is at risk: At least three MCP servers utilize the “progress_note” feature to access patients’ medical records. A breach of these would be a clear violation of privacy regulations and a stark reminder of the real-world consequences of insecure MCP deployments.

Figure 1. By the Numbers: Exposed MCP Servers

Compromising Cloud Infrastructure via MCP

Given the extreme popularity of MCP servers, it is no surprise to see various MCP servers designed to interact with cloud services. Our research uncovered several critical vulnerabilities in two non-official Azure and AWS MCP servers. These vulnerabilities have been disclosed to the affected vendor through the Zero Day Initiative (ZDI). The high-level information underscores the severity of the threat:

Table 1. Uncovered vulnerabilities in MCP servers

These vulnerabilities, all with a CVSS score of 9.8, allow attackers to bypass security controls and execute unauthorized commands within the cloud environment. In essence, a compromised MCP server is a launchpad for a full-scale cloud breach.

The Anatomy of a Cloud MCP Attack

How do these attacks work in practice? The attack chain is often surprisingly simple, yet devastatingly effective:

1. Discovery: Attackers scan the network for exposed MCP servers.
    1.1 Once discovered, an attacker would assess if the MCP server implements authentication or authorization.
    1.2 The next step is to assess the level of access. Remote MCP servers can implement granular permission, only granting access to specific data or services.
2. Exploitation: Attackers then exploit vulnerabilities, like the ones we've disclosed, to gain initial access to the server.
3. Credential theft: Once inside, attackers can often find hardcoded cloud credentials, Application Programming Interface (API) keys, and other secrets stored in plaintext configuration files.
4. Lateral movement: Armed with these credentials, attackers can then move laterally within the cloud environment, accessing other services, databases, and sensitive data.
5. Full cloud compromise: In the worst-case scenario, attackers can use their access to take complete control of the cloud account, leading to data breaches, financial loss, and reputational damage.

The vulnerabilities we've identified in cloud-specific MCP servers have moved beyond the theoretical, signaling a fundamental shift in how attackers can target and compromise cloud environments. Let's explore some of the specific attack vectors in more detail.

Abusing Hardcoded Cloud Credentials

One of the most common and dangerous security flaws we've observed is hardcoding cloud credentials directly into MCP server configuration files. Our analysis of over 19,000 MCP server source codes revealed that nearly half (48%) recommend storing secrets in insecure .env files or plaintext JSON configurations. This is the digital equivalent of leaving the keys to your kingdom under the doormat.

When an attacker gains access to an MCP server with hardcoded credentials, they have a direct line to the underlying cloud provider's API. This allows them to perform a wide range of malicious actions, including:

• Data exfiltration: Accessing and downloading sensitive data from cloud storage services like Amazon S3 or Azure Blob Storage.
• Resource hijacking: Spinning up expensive cloud resources for cryptocurrency mining or other malicious activities.
• Infrastructure sabotage: Deleting or modifying critical cloud infrastructure, such as virtual machines, databases, and network configurations.

Command Injection in the Cloud

The command injection vulnerabilities we've discovered in ‘aws-mcp-server’ and ‘azure-mcp-server’ are particularly dangerous. These flaws allow an attacker to execute arbitrary commands on the underlying host, which in a cloud environment is often a virtual machine or container with privileged access to the cloud provider's APIs. This can lead to a full container breakout or virtual machine (VM) escape, giving the attacker complete control over the host and any other resources it has access to.

The Dangers of Unrestricted Network Access

Tool Poisoning in the Cloud Context

Tool poisoning, where a malicious MCP server provides false tool descriptions or poisoned responses, takes on a new dimension in the cloud. An attacker could, for example, poison the ‘aws-cli’ or ‘az-cli’ tools to secretly exfiltrate data or execute malicious commands every time a legitimate user tries to interact with their cloud environment. This is a subtle and insidious attack that can be very difficult to detect.

What Organizations Must Do Now: A Cloud-Centric Defense

The shift of MCP exploitation to the cloud requires a corresponding pivot in our defensive strategies. The recommendations from our original article still stand, but they must be augmented with a new layer of cloud-specific security controls. Here’s what organizations must do now to protect themselves:

1. Treat MCP servers as critical cloud infrastructure
   MCP servers are no longer just experimental tools; they are a critical part of the cloud infrastructure and must be treated as such. This means subjecting them to the same rigorous security standards as any other production service:
   • Secure by design: Integrate security into the entire lifecycle of MCP deployments, from development to production
   • Change management: Implement formal change management processes for all MCP server configurations
   • Regular audits: Conduct regular security audits of MCP servers and their configurations
2. Eliminate hardcoded credentials with cloud-native secrets management
   The practice of hardcoding credentials in MCP server configurations is a ticking time bomb. Organizations must immediately move to a more secure secrets management strategy, leveraging the native capabilities of their cloud provider:
   • AWS: Use AWS Secrets Manager or AWS Systems Manager Parameter Store to store and manage secrets
   • Azure: Use Azure Key Vault to securely store and access secrets
   • Google Cloud Platform (GCP): Use Google Cloud Secret Manager to manage secrets and control access
   Using these services ensures that MCP servers never have direct access to plaintext credentials. Instead, they can be granted identity and access management (IAM) roles that allow them to retrieve secrets on demand, with full auditing and access control.
    
3. Enforce strict network segmentation and exposure management
   Publicly exposed MCP servers are an open invitation to attackers. Organizations must drastically reduce their MCP attack surface by implementing strict network segmentation and exposure management controls:
   • Private by default: Deploy MCP servers in private subnets by default, with no public IP addresses
   • Least-privilege network access: Use security groups and network access control lists (ACLs) to restrict inbound and outbound traffic to only what is necessary
   • Reverse proxies and API gateways: Use a reverse proxy or API gateway that can provide an additional layer of authentication, authorization, and logging for MCP servers exposed to the internet
4. Implement robust authentication, authorization, and auditing
   The default-open nature of many MCP servers is a major security risk. Organizations must enforce strong authentication, authorization, and auditing for all MCP interfaces:
   • OAuth 2.0: Implement OAuth 2.0 for all MCP client authentication, ensuring that all access is tied to a specific user identity
   • Role-Based Access Control (RBAC): Define granular roles and permissions for MCP tools, ensuring that users only have access to the tools and data they need to do their jobs.
   • Comprehensive Auditing: Log all MCP tool invocations, including the user, the tool, the parameters, and the result — this is essential for detecting and investigating suspicious activity
5. Containerize and Isolate MCP Servers
   Running MCP servers in isolated containers is an effective way to limit their blast radius in the event of a compromise. By containerizing MCP servers, the following can be done:
   • Limit Filesystem Access: Restrict the server's access to the host filesystem, preventing it from accessing sensitive files
   • Restrict Network Access: Use container networking policies to control which network resources the server can access
   • Enforce Resource Limits: Limit the server's CPU and memory usage to prevent it from impacting other services on the host
   Docker's MCP Toolkit and other similar solutions provide a good starting point for building a secure, containerized MCP architecture.

Conclusion: The Cloud is the New Battlefield for MCP Security

The rapid, insecure proliferation of MCP servers has created a new and dangerous attack surface for organizations. What began as a concern about data exposure has now escalated into a full-blown threat to cloud infrastructure. Our research shows a nearly threefold increase in exposed servers, with attackers now actively targeting cloud-specific MCP implementations to gain control of critical resources.

The convenience of MCP has lulled many organizations into a false sense of security. The reality is that without proper safeguards, these servers are not just backdoors to data; they are gateways to the entire cloud environment. The vulnerabilities we have discovered in AWS and Azure MCP servers, combined with the widespread practice of hardcoding credentials, create a perfect storm for catastrophic breaches.

Organizations must act now to secure their MCP deployments. This requires a fundamental shift in mindset, treating MCP servers as critical cloud infrastructure and applying the same rigorous security standards as any other production service. By embracing cloud-native secret management, enforcing strict network controls, implementing robust authentication and authorization, and containerizing MCP servers, organizations can begin to close this dangerous security gap. The threat is real, the stakes are high, and the time to act is now.
 

Appendix

This appendix describes the various cloud attack vectors in more technical detail.

Hardcoded Credentials: A Case Study

Consider a scenario where a developer has configured an MCP server to access a production database on Amazon RDS. Following common but insecure practice, they've placed the database credentials directly in the MCP server's configuration file:

 {
  "mcp_server": {
  "tools": [
   {
    "name": "production_db_query",
    "description": "Query the production database",
    "type": "sql",
    "connection_string": "postgresql://user:password@prod-rds-instance.random-chars.us-east-1.rds.amazonaws.com:5432/production_db"
   }
  ]
 }
}

An attacker who discovers this exposed MCP server can now not only query the database using natural language, but they can also extract the full connection string, including the username and password. With these credentials, they can connect to the RDS instance from anywhere in the world, bypassing any application-level security controls. They can dump the entire database, modify or delete records, and cause untold damage. This is not a sophisticated attack; it's a simple case of credential theft enabled by insecure defaults.

Command Injection: From Cloud Server to Cloud Account

The command injection vulnerabilities we've discovered in ‘aws-mcp-server’ and ‘azure-mcp-server’ are particularly insidious. Let's imagine an ‘aws-mcp-server’ running on an EC2 instance with an IAM role attached that grants it broad permissions to manage other AWS resources. An attacker who exploits a command injection flaw in this server can now execute commands as the EC2 instance. This means they can:

Steal IAM credentials: The attacker can query the EC2 metadata service (‘http://169.254.169.254/latest/meta-data/iam/security-credentials/’) to steal the temporary credentials associated with the IAM role.

Access other AWS services: With these credentials, the attacker can now use the AWS CLI or API to interact with any other AWS service to which the IAM role has access. This could include S3, DynamoDB, Lambda, and more.

Achieve persistence: The attacker can create new IAM users, modify security groups, or launch new EC2 instances to maintain a foothold in the environment.

In this scenario, a single vulnerability in an MCP server has escalated into a full-blown cloud account compromise. The MCP server has become a pivot point, enabling the attacker to move laterally and take control of the entire cloud environment.

Tool Poisoning: A Subtle Betrayal

Tool poisoning in the cloud can be a very subtle and effective attack. Imagine an MCP server that provides a tool for managing Kubernetes clusters. A legitimate user might ask the AI agent to “deploy the latest version of our web application to the production cluster.” The AI agent, in turn, would use the “kubectl” tool provided by the MCP server to execute the deployment.

However, a malicious MCP server could poison this tool. When the AI agent calls the kubectl tool, the MCP server could secretly add a malicious sidecar container to the deployment. This sidecar could then be used to exfiltrate data, attack other services in the cluster, or even launch a denial-of-service attack. The user would be completely unaware that their legitimate request has been hijacked to carry out a malicious action. This is the danger of tool poisoning: it turns your own tools against you.