NHI Forum
Read full article here: https://blog.gitguardian.com/breaking-mcp-server-hosting/?utm_source=nhimg
A recent security research report unveiled a critical vulnerability in Smithery.ai, a registry and hosting platform for Model Context Protocol (MCP) servers — that exposed over 3,000 MCP-hosted servers and put thousands of API keys at risk. The flaw stemmed from a path-traversal bug in the Docker build configuration process, and underscores how centralised AI server hosting introduces systemic supply-chain risk.
Key Facts & Attack Flow
- The platform’s build pipeline accepted a dockerBuildPath value that was insufficiently validated, allowing attackers to specify a context outside the intended repository.
- Researchers demonstrated the vulnerability by submitting a malicious smithery.yaml and Dockerfile, which exfiltrated the host builder’s filesystem, including .docker/config.json and other sensitive files.
- The extracted Docker configuration revealed a token for Fly.io (a container hosting platform used by Smithery) that granted over-privileged access, not just registry access but execution control of 3,000+ applications.
- With those credentials, an attacker could execute arbitrary code on any of the hosted MCP servers, intercept API traffic, and harvest client-sent secrets (e.g., API keys in query parameters).
- The vulnerability was responsibly disclosed on June 13, 2025, and Smithery deployed a complete fix and key rotation by June 15, 2025. There is no public evidence of malicious exploitation before the fix.
Why This Matters
- High-impact supply chain risk: A single flaw in a registry/hosting layer created lateral exposure across thousands of servers and clients.
- Over-privileged credentials magnified the risk: The Fly.io token doubled as both registry access and machine-API control, illustrating the danger of “one token, many rights.”
- Static secrets still dominate MCP servers: Many remote MCP servers use long-lived API keys rather than delegated protocols like OAuth, increasing the window of exposure.
- Centralisation increases blast radius: When a platform hosts many user-submitted servers under one account, a compromise affects many clients.
- Emerging risk in AI tooling ecosystems: MCP infrastructure is part of the fast-growing AI agent/toolchain ecosystem. Weak links here enable novel attacks such as prompt injection, data exfiltration, and lateral movement.
Lessons & Best Practices
- Validate build contexts strictly: Ensure build pipelines only allow trusted directories and prevent path-traversal of build contexts.
- Limit credential scope: Avoid tokens that combine registry and machine control. Adopt least-privilege tokens and segregate functions.
- Rotate and restrict secrets: Use short-lived credentials, vault secrets, and avoid static keys that remain valid for long periods.
- Isolate hosted services: Hosted MCP servers should be compartmentalised so that a compromise affects only a narrow subset of clients.
- Audit outgoing and incoming traffic: Monitor API calls and credential uploads to detect unusual patterns, e.g., large numbers of keys transmitted to new endpoints.
- Adopt OAuth or equivalent delegation where possible: Although not a silver bullet, delegated and scoped tokens reduce standing privilege and blast radius.
- Consider hosting model risk: Choosing a third-party MCP server hosting provider means inheriting their security posture and risk surface.