How MCP Server Flaws Escalate to Supply Chain Attacks

A significant security flaw within a widely used MCP server hosting platform recently exposed thousands of AI servers and their associated credentials, nearly triggering a major supply chain incident. This path traversal vulnerability in Smithery.ai’s infrastructure allowed unauthorized access to administrative credentials, which in turn compromised over 3,000 hosted AI servers. The breach could have led to the theft of API keys and secrets from numerous customers across hundreds of services. Following responsible disclosure, the vulnerability was promptly patched, and no evidence of actual exploitation was discovered. This event underscores how centralized AI infrastructure can become a high-value target, where a single weakness might jeopardize entire ecosystems.

The Model Context Protocol (MCP) allows AI applications to interface with external tools and data sources via specialized servers. These servers are generally categorized as local or remote. Local servers interact with resources like a device’s file system or command line, while remote servers connect to external databases or APIs. Remote servers can be self-hosted on a user’s own infrastructure or fully remote, meaning they are hosted directly by resource providers. Smithery.ai operates as an MCP server registry using a hybrid approach, hosting remote servers that users would otherwise manage themselves. While this simplifies deployment, it also raises the stakes for security, since an incident affecting the host can impact a large number of servers and the broad range of resources they serve.

During an investigation into Smithery’s hosted servers, researchers identified a critical flaw in the platform’s build process. The registry relies on GitHub repositories for server source code and uses Docker to build and host server images. Contributors provide a configuration file, `smithery.yaml`, which specifies the Docker build path and Dockerfile location. The vulnerability stemmed from inadequate validation of the `dockerBuildPath` parameter, which could be manipulated to reference locations outside the intended repository. This path traversal issue meant an attacker could direct the build process to any readable directory on the host system, exposing its contents through a malicious Dockerfile.

Several constraints limited the attack’s effectiveness. The Docker daemon needed read access to the specified directory, and the attacker’s Dockerfile had to reside within that location. By setting the build path to `../`, researchers accessed the build user’s home directory, which contained sensitive files not meant for exposure. A specially crafted Dockerfile exfiltrated file listings to an external endpoint, revealing critical assets like `.docker/config.json`. This file housed a Fly.io authentication token, which turned out to be overprivileged.

Fly.io is a compute platform offering hardware-virtualized containers and a Docker registry. The exposed token granted not only registry access but also full control over the machines API. This overprivileged credential provided entry to a Fly.io organization managing more than 3,000 applications, primarily MCP servers hosted by Smithery, along with parts of Smithery’s own infrastructure. With these permissions, an attacker could execute arbitrary code on any hosted server.

The compromise of Smithery’s MCP servers posed direct risks to users. A server with code execution capabilities becomes untrusted, opening the door to prompt injection attacks where malicious content could be fed to AI clients. Additionally, since these servers handle authentication for remote data sources and APIs, they store sensitive secrets. During testing, researchers intercepted network traffic from a Smithery-hosted server, capturing HTTP requests that included client credentials in query parameters. The same method could have been applied across all hosted servers, potentially exposing secrets for thousands of clients and hundreds of services.

This incident highlights the dangers of concentrated infrastructure and static credential use in MCP environments. Centralized hosting creates attractive targets, as seen in previous supply chain attacks like the one affecting Salesloft, where OAuth secrets were misused to compromise customer assets. Many MCP servers rely on static, long-term API keys instead of more secure, scoped authentication methods like OAuth, increasing both the attack surface and the potential damage from credential theft. Although OAuth isn’t a perfect defense, it can help limit the impact of such breaches when implemented correctly.

The Smithery team responded swiftly to the vulnerability report, deploying a fix within days and preventing any known exploitation. This case serves as a crucial reminder for organizations to evaluate hosting models carefully and adhere to security best practices, especially as AI and MCP adoption continues to grow.

(Source: ITWire Australia)