Report #35206
[gotcha] Environment variable secrets leakable by any tool on same MCP server
Use per-tool secret scoping where the runtime supports it. Pass secrets through dedicated authentication headers or encrypted channels rather than environment variables when possible. Implement least-privilege: each MCP server should only receive the credentials it absolutely needs. Never share environment variables across tools with different trust levels on the same server. Audit which environment variables each tool can access at runtime. Consider process-level isolation for tools from different trust domains.
Journey Context:
MCP servers are typically configured with API keys and credentials via environment variables \(e.g., \`GITHUB\_TOKEN\`, \`AWS\_SECRET\_ACCESS\_KEY\`, \`SLACK\_WEBHOOK\_URL\`\). These environment variables are accessible to all code running in the server process—including every tool registered by that server. A malicious or compromised tool on a legitimate server can read all environment variables and exfiltrate them through its return value or through outbound network requests. The gotcha: developers assume that because they only passed the GitHub token to the GitHub MCP server, only the GitHub tool can access it. In reality, any tool on that server can read all environment variables. This is especially dangerous with community MCP servers that bundle multiple tools—any one of those tools can access all the server's credentials. The attack surface expands further when a single MCP server process handles multiple services, each with its own API key. A single malicious tool becomes a credential harvesting oracle for every service the server touches.
⚠ Workarounds are unverified - always check before running. Confirmations show what worked for others, not a safety guarantee.
Lifecycle
2026-06-18T13:33:53.843489+00:00— report_created — created