MCP Security: Network-Exposed Servers Are Backdoors to Your Private Data

By Alfredo Oliveira and David Fiser

Key Takeaways

• We found 492 MCP servers with no client authentication or traffic encryption.
• Successful attacks against these servers lead to data breaches, leaking sensitive information such as company proprietary information and customer details.
• Organizations that use MCP servers must not expose them on the network without an additional security layer (authentication/proxy).
• Recommendations for mitigating the risks include exposure management, with limited permissions for the MCP server.

Organizations should be proactive in their defense and watch for every possible crack in security. Our latest research looks specifically at security issues that may occur when deploying Model Context Protocol (MCP) servers. Companies should keep their eyes open for the security risks that arise when exposure management is not properly implemented.

The MCP architecture introduces a significant security issue when servers are exposed to the network without authentication. By default, the client is not required to use authentication to access the MCP server, as shown in the connection flow below:

Figure 1. MCP connection flow

No open authorization (OAuth) token delegation from clients means no Role-Based Access Control (RBAC). This configuration creates multiple attack vectors and violates fundamental security principles.

The most unsecure scenarios include:

• Data source credentials (API keys, database passwords, service tokens) are hardcoded in the server configuration
• MCP servers bound to (public-facing) network interfaces (e.g., 0.0.0.0:8080)
• All clients connecting to the server inherit the same privileged access
• No user-specific authorization or access control mechanisms exist

Additionally, the data source can be accessed by the server with a single provided credential; this exposes sensitive information. Through our probe, we discovered 492 MCP servers running without any client authentication or traffic encryption.

The exposed servers we uncovered collectively provide access to 1,402 MCP tools. More than 90% of them provide direct read access to the data source, making the data available to everyone using a natural language — that means one does not have to know how to code to exfiltrate private information.

Cloud Infrastructure Amplifies the Risk

Our research revealed an interesting pattern: the exposed MCP servers are cloud-centric. Approximately 74% of the uncovered servers are hosted on major cloud service providers (CSPs) like Amazon Web Services (AWS), Azure, Google Cloud Platform (GCP), and Oracle. These services can be deployed with broad network access, which has its benefits but also poses additional security concerns.

Cloud One™ Conformity warns about unwanted exposures, insecure cloud policies, and offers continuous security, compliance, and governance, while supporting teams in managing and helping resolve misconfigurations of cloud resources.

At least 8 of the 492 MCP servers directly manage CSP resources. The provided tools allow listing, creating, modifying, and deleting cloud resources. When left unprotected, the MCP servers provide attackers control over the linked cloud resources.

Each MCP server acts as an open door to its data source: databases, cloud services, internal APIs, or project management systems. Without authentication, sensitive data such as trade secrets and customer records becomes accessible to everyone.

Our research revealed an alarming number of open MCPs that provide access to databases, browser automation systems, developer tools, databases, finance-related systems, and cloud platforms.

Figure 2. Top categories of systems to which open MCPs provide access

MCP Deployment Security Risks

When deploying an MCP server, the administrators should be extra cautious about:

1. Credential Exposure

Credentials are exposed through the following:

• Unrotated Static Secrets: Hardcoded credentials turn into long-lived secrets that cannot be easily updated or changed. If compromised, they can be used indefinitely.
• Leaked Configuration: Credentials might be leaked through configuration files, environment variables, or source code.
• Vulnerable Process Memory: Credentials loaded into process memory that are exfiltrated after successful exploitation of a vulnerability.

Figure 3. Example of an MCP server configuration using system variable secrets to authenticate to the data source

Figure 4. Example of MCP server configuration using .env secrets to authenticate to the data source

Figure 5. Example of MCP client configuration without any authentication

2. Privilege Escalation

• Shared Access: All users connecting to the MCP server gain the same level of access to backend systems.
• No User Context: The server cannot differentiate between different users' permissions.
• Excessive Permissions: To provide the necessary functionality, the MCP server typically has broad access to accommodate all potential use cases.

3. Network Attack Surface

• Open Endpoints: Network-exposed MCP servers present attack targets for unauthorized access.
• Lateral Movement: Compromised MCP servers provide access to backend data sources using hardcoded credentials.
• Man-in-the-Middle(MITM)Attacks: Unencrypted network traffic between clients and servers can be intercepted and modified, exposing sensitive data and altering the tool output and agentic workflows based on that. This risk is more prevalent in on-premise deployments.

4. Audit and Compliance Issues

• Attribution Loss: Once the system is infiltrated, even an attacker’s actions will appear to originate from the trusted service account.
• Compliance Violations: The configuration does not meet the requirements for user-specific access logging.
• Forensic Challenges: Difficulty with tracing malicious activities back to specific users.

Risk Assessment Matrix

Taking into account these risks, we assessed the gravity of each risk and compared side-by-side how the hardcoded method would fare versus the recommended OAuth standard.

Table 1. MCP servers risk assessment matrix

Many MCP servers are based on the FastMCP library. We performed an analysis based on GitHub Awesome MCP servers. Although the library offers an authentication mechanism, very few of them implement it.

Recommendations

For mitigating the risks associated with exposed MCP servers, there are several suggested main approaches. First, broader exposure is not recommended. Even if authentication is implemented, since public-facing assets will soon or later be subject to abuse attempts, no one can exclude the potential risk. The client should delegate an authentication token for the data source, so the server will not provide excessive access to the resource server will not provide excessive access to the resource.

Token delegation

Token delegation enhances server security for several reasons. It grants user-specific access, wherein each request operates within the user's permission scope. Token refresh reduces the credential exposure window. Easier revocation, tokens can be immediately revoked if a compromise is detected. Lastly, it enables an audit trail, meaning all operations are attributable to specific users.

The following pattern shows how this process is carried out:

OAuth Token Delegation Pattern

Client-Side Token Management

• Clients obtain OAuth tokens directly from identity providers
• Tokens configured to represent specific user identities and permission
• Short-lived tokens with automatic refresh capabilities might also be used
• Client-side conducts secure token storage (keychain, credential managers)

Server-Side Token Validation

Client Request Flow:

• Client authenticates with an OAuth provider
• Client includes a bearer token in MCP requests
• The MCP server validates the token with the approved OAuth provider
• The server uses a validated token for downstream API calls
• All operations maintain the user context

Using internet-exposed MCP servers with single-token privileged data source access poses significant security risks. Organizations should immediately shield their deployments from the public and transition to OAuth token delegation patterns to ensure proper user authentication, authorization, and audit capabilities. This transition not only improves security but also enables compliance with modern security frameworks and regulations.

Proper implementation

Proper implementation and fundamental security measures remain crucial in safeguarding systems.

Immediate actions

• Network Security Boost
  • Consider whether network exposure is necessary for your use case (use stdio if it’s not)
  • Implement TLS encryption for all network communications
  • Use reverse proxies with proper authentication or OAuth delegation for network exposure
• Removal of Any Hardcoded Credentials
  • Audit all MCP server configurations for embedded secrets
  • Implement secure credential management systems
• Token validation
  • Prefer OAuth token credentials from the client requesting access to the data source
  • Verify token signatures and expiration

Long-term enhancements

• Zero-Trust Architecture
  • Add request-level authorization checks
  • Monitor and log all MCP operations
• Credential Management
  • Deploy secure secret management solutions such as vaults and keychains
  • Implement credential rotation policies
  • Use short-lived, scoped access tokens
• Monitoring and Alerting
  • Log all authentication and authorization events
  • Implement anomaly detection for unusual access pattern
  • Set up alerts for failed authentication attempts
• Exposure management
  • Limit permissions for the MCP server
  • Enable read permission instead of write, when applicable
  • Use shadow copies to avoid data corruption

The recommended implementation maintains the flexibility of MCP while implementing security best practices that scale with organizational growth and regulatory requirements.

Conclusion

MCP servers are vulnerable to attacks. Like most systems, these servers shouldn’t be assumed as inherently and adequately secure by default and then left without appropriate safeguards.

Therefore, organizations must not take any component for granted, as even the tiniest crack can let malicious activities seep through. Consistent and sustained efforts towards strengthening the servers’ security posture are recommended.