Notifications
Clear all
Topic starter
11/08/2026 3:19 pm
TL;DR: Hostile MCP servers can silently exfiltrate local credentials, emails, and wallet keys the moment they run, and Bishop Fox pairs the otto-support selfpwn demonstration with the postmark-mcp and ClawHub compromises to show how package trust can fail after review. The real control gap is not detection after execution, but verified provenance, version pinning, and egress restriction before a tool ever reaches a developer machine.
NHIMG editorial — based on content published by Bishop Fox: Supply chain risk in MCP servers and what selfpwn reveals
By the numbers:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions.
- 53% of MCP servers expose credentials through hard-coded values in configuration files.
Questions worth separating out
Q: How should security teams govern MCP servers in production?
A: Treat each MCP server as a governed access boundary, not just a utility.
Q: Why do MCP servers create a bigger secrets risk than ordinary package installs?
A: Because the threat is not only code on disk, but code that executes inside a real user context and can read live credentials immediately.
Q: What breaks when organisations trust MCP package review alone?
A: Review alone breaks when the reviewed package is later updated, repackaged, or modified in a way that keeps its interface intact but changes its behaviour.
Practitioner guidance
- Treat community MCP servers as untrusted until approved Require internal review, signed artefacts, and explicit approval before developers can run third-party MCP servers on managed endpoints.
- Pin every approved MCP server version Use lockfiles, checksums, and dependency verification so updates cannot land without a fresh security review and documented change control.
- Restrict MCP execution to dedicated environments Run approved tools in isolated workspaces or containers with no direct access to a developer's full local profile.
What's in the full article
Bishop Fox's full analysis covers the operational detail this post intentionally leaves for the source:
- The exact selfpwn workflow used to quantify what a hostile MCP server can read from a developer machine.
- Step-by-step mitigation guidance for internal registries, version pinning, checksum verification, and dependency control.
- Runtime and egress monitoring approaches for spotting suspicious outbound connections during MCP tool execution.
- Case-specific discussion of the postmark-mcp and ClawHub compromises as supply chain patterns, not just examples.
👉 Read Bishop Fox's analysis of MCP server supply chain risk and local credential exposure →
MCP server supply chain risk: are your controls keeping up?
Explore further
11/08/2026 3:30 pm
Supply chain trust in MCP is an identity problem, not just a software integrity problem. The central failure is that organisations often treat a local MCP server as an approved tool once it passes review, when in reality it inherits the user's working identity and everything that identity can touch. That means the tool becomes an extension of NHI exposure, not a separate software event. Practitioners should stop framing MCP governance as package hygiene alone and treat it as controlled execution of a credential-bearing identity.
A few things that frame the scale:
- Only 18% of MCP server deployments implement any form of access scoping for tool permissions, according to The State of MCP Server Security 2025.
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
A question worth separating out:
Q: Who is accountable when a hostile MCP server steals developer secrets?
A: Accountability usually sits with the organisation that allowed the tool to run without sufficient provenance, isolation, and egress controls. In regulated environments, teams should also map the incident to secrets management, privileged access, and software supply chain control obligations.
👉 Read our full editorial: Supply chain risk in MCP servers: why trust breaks at install time
