In June 2025 GitGuardian researchers found that Smithery.ai, a registry that builds and hosts Model Context Protocol (MCP) servers for AI agents, would build a server from any directory on its build machine, not just the server's own repository. By pointing a server's build path one level up, they read the build user's Docker configuration file and obtained a live fly.io token. GitGuardian says the token controlled a fly.io organisation with more than 3,000 apps, most of them hosted MCP servers. With it, the researchers ran a command as root on a hosted server and captured a client's API key from its traffic. GitGuardian reported the flaw on 13 June 2025, Smithery rotated the token on 14 June and finished the fix on 15 June, and GitGuardian published on 22 October 2025. GitGuardian says no evidence of exploitation was found. Because researchers obtained and used a live credential, we list it as a confirmed NHI breach.
Key takeaways
- Smithery did not validate the
dockerBuildPathsetting in a server'ssmithery.yaml, so a build could use the builder's home directory as its context and copy files out of it. - The home directory held
.docker/config.jsonwith a fly.io token. GitGuardian says "there is a single type of credential for both the machines API and the Docker registry", so a registry login also controlled the machines. - GitGuardian used the token to list 3,243 apps in Smithery's fly.io organisation, run a command as root on a hosted MCP server and capture a Brave API key sent by one of that server's clients.
- Smithery rotated the token within a day of the report and fully fixed the flaw within two days. GitGuardian says "no evidence of exploitation was found."
- The identity lesson: a hosting platform's deployment token is a master key to every customer workload and every secret those workloads receive, so it must be scoped to one job and kept off build machines.
At a glance
| Organisations | Smithery.ai (MCP server registry and hosting); users and clients of more than 3,000 MCP servers hosted on its fly.io organisation |
|---|---|
| When | Found 10 June 2025; reported 13 June 2025; token rotated 14 June 2025; fixed 15 June 2025; published 22 October 2025 |
| Attacker | None known. Found and demonstrated by GitGuardian researchers under responsible disclosure |
| Entry point | Path traversal through the unvalidated dockerBuildPath setting in Smithery's build process |
| Identities abused | An over-privileged fly.io token in the build user's Docker configuration, valid for both the container registry and the machines API; client API keys passed to hosted MCP servers |
| Impact | Researchers gained control of Smithery's fly.io organisation, root command execution on a hosted MCP server and a captured client API key; no evidence of malicious exploitation |
| Category | NHI, Agentic AI and AI agents. Incident class: confirmed NHI breach (live hosting token obtained and used by researchers; no malicious use found) |
What happened
MCP servers are the connectors that let AI agents call external tools and data sources. Smithery.ai runs a registry of them and, for remote servers, a hosting service: a developer points Smithery at a GitHub repository with a smithery.yaml file, Smithery builds a Docker image and deploys it, and agents connect to the hosted server. Clients often pass the server their own API keys for the service it wraps. That makes the hosting platform a single place where thousands of servers, and the keys sent to them, meet.
GitGuardian researcher Gaetan Ferry found that the dockerBuildPath property in smithery.yaml accepted any path, including ones outside the repository. Setting it to .. made the builder's home directory the Docker build context. A crafted Dockerfile then listed the files there and sent the list to an external server. The list included .docker/config.json, and a second build read it. It held a fly.io authentication token for Smithery's container registry.
The token did far more than push images. GitGuardian explains that on fly.io "there is a single type of credential for both the machines API and the Docker registry". The researchers used it to list the apps in the "smithery" organisation, 3,243 of them, mostly hosted MCP servers and some of Smithery's own infrastructure. They ran a command on a hosted machine and got a root shell response. They then ran a packet capture on one server and recorded a client request carrying a Brave API key in its query string. GitGuardian says the same approach could have collected secrets from the other hosted servers, though it does not say it tried. As GitGuardian put it: "The compromised secret allowed access to a fly.io organization that contained more than 3000 apps."
Smithery's response was fast. According to GitGuardian's timeline, it acknowledged the report on 13 June 2025, deployed a partial fix and rotated the compromised key on 14 June, and completed the fix on 15 June. GitGuardian published its write-up on 22 October 2025, stating: "The vulnerability was quickly patched after responsible disclosure, and no evidence of exploitation was found." SC Media and Cyber Security News reported the findings the same week.
Timeline
| Date | Event |
|---|---|
| 10 June 2025 | GitGuardian discovers the path traversal in Smithery's build process. |
| 13 June 2025 | GitGuardian completes its proof of concept and reports it; Smithery acknowledges the report. |
| 14 June 2025 | Smithery deploys a partial fix and rotates the compromised fly.io token. |
| 15 June 2025 | Smithery deploys the complete fix. |
| 22 October 2025 | GitGuardian publishes its research; Cyber Security News reports it the same day. |
| 23 October 2025 | SC Media reports the fix and the exposure of more than 3,000 MCP servers. |
How it happened: the identity attack path
- Build input trusted. Smithery built servers from a user-supplied path without checking it stayed inside the repository.
- Secrets on the builder. The build user's home directory held a Docker configuration file with a fly.io token, readable by any build that could reach it.
- Token extracted. A crafted build copied the configuration file out, giving the researchers a live credential.
- One token, two powers. The fly.io token authenticated to the machines API as well as the registry, giving control over every app in Smithery's organisation.
- Downstream secrets in reach. Command execution on hosted MCP servers let the researchers capture API keys that clients sent to those servers.
Impact
- Confirmed (research): GitGuardian obtained a valid fly.io token, listed 3,243 apps, executed a command as root on a hosted MCP server and captured one client's Brave API key.
- Potential: takeover of more than 3,000 hosted MCP servers, interception of the API keys their clients send, and tampering with servers that AI agents trust, a supply chain risk for every agent using them.
- Malicious use: none found. GitGuardian says no evidence of exploitation was found, and SC Media reports no indication of exploitation in the wild.
- Response: the token was rotated within a day of the report and the flaw fully fixed within two days.
What this means for NHI and AI agent security
MCP hosting concentrates risk in a new way. Each hosted server holds or receives credentials for the service it connects an agent to, and the platform's deployment token sits above all of them. In Smithery's case, that token lived on a build machine that ran untrusted builds, and it carried more power than its job required. GitGuardian's point is that one over-privileged, long-lived token turned a build bug into potential control of thousands of agent tools. The same logic made the Salesloft Drift breach so damaging in SaaS.
For organisations using hosted MCP servers, the lesson is to treat every key you hand to a third-party server as shared with its host. Prefer servers that support OAuth with scoped, short-lived tokens over static API keys in query strings. For anyone running MCP infrastructure, keep deployment credentials out of build environments and scope them to the narrowest API. The malicious postmark-mcp server shows the other side of the same trust problem. Our MCP Security Guide and Secrets Management Guide cover both.
Recommendations
- Keep deployment tokens off build machines. Builds that run user-supplied Dockerfiles should never have access to platform credentials. Use isolated builders and inject only what each step needs. See our CI/CD Pipeline Identity Security Guide.
- Scope tokens to one capability. A registry push token should not control machines. Where a provider offers only broad tokens, wrap them in narrowly scoped automation. See our Secrets Management Guide.
- Validate build inputs. Reject paths that resolve outside the repository and treat every field in a user's build configuration as untrusted.
- Rotate keys sent to hosted MCP servers. If you passed API keys to a Smithery-hosted server before 15 June 2025, rotate them. See our Leaked Credential Response Playbook.
- Prefer OAuth over static keys for MCP. Choose MCP servers that accept scoped, short-lived OAuth tokens, and never put keys in URL query strings. See our MCP Security Guide.
- Inventory the MCP servers your agents use. Know which are hosted by third parties and what credentials each one receives. See our Shadow AI Discovery Guide.
Frequently asked questions
What was the Smithery.ai MCP vulnerability?
A path traversal flaw in Smithery's build process: the dockerBuildPath setting in smithery.yaml was not validated, so a malicious server could make the build read files from the build machine's home directory, including a Docker configuration file holding a fly.io token.
Was Smithery.ai breached?
GitGuardian researchers obtained and used a live fly.io token that controlled more than 3,000 hosted MCP servers, which we treat as a breach of a non-human identity. It was found under responsible disclosure, Smithery rotated the token on 14 June 2025, and GitGuardian says no evidence of malicious exploitation was found.
Should I rotate API keys used with Smithery-hosted MCP servers?
GitGuardian showed it could capture API keys sent by clients to a hosted server. No malicious use has been reported, but rotating keys that were passed to Smithery-hosted servers before the fix on 15 June 2025 is a low-cost precaution.
Related NHI Mgmt Group resources
postmark-mcp malicious MCP server 2025 · Sentry MCP Agentjacking 2026 · LiteLLM MCP auth bypass 2026 · MCP Security Guide · Secrets Management Guide
How NHI Mgmt Group can help
MCP servers and the platforms that host them are a fast-growing layer of non-human identity, with tokens and API keys passing through infrastructure many organisations do not control. We help teams map those credentials, scope them and decide which hosted tools to trust. See our NHI Foundation Level Training Course.
References
- GitGuardian: From Path Traversal to Supply Chain Compromise: Breaking MCP Server Hosting (22 October 2025)
- Cyber Security News: Critical Vulnerability in MCP Server Platform Exposes 3,000+ Servers and Thousands of API Keys (22 October 2025)
- SC Media: Smithery.ai fixes path traversal flaw that exposed 3,000 MCP servers (23 October 2025)