Notifications
Clear all
Topic starter
02/08/2026 11:44 am
TL;DR: Researchers found a critical vulnerability in Anthropic's MCP SDK affecting Python, TypeScript, Java, and Rust, with 7,000+ public servers and 150 million downloads in scope, enabling remote code execution and access to databases, API keys, and chat histories according to Salt's source article. The real problem is that agentic systems inherit trust in MCP layers that many security teams still do not monitor.
NHIMG editorial — based on content published by Salt: LLMjacking and MCP server security failures in agentic environments
By the numbers:
- Over 7,000 publicly accessible servers were in scope, and more than 150 million downloads were affected across the ecosystem.
Questions worth separating out
Q: How should security teams design MCP server access for AI agents?
A: Security teams should design MCP access around a small set of agent goals, not a mirrored list of REST endpoints.
Q: Why do MCP servers create a bigger risk than model prompts alone?
A: Because the dangerous outcome is not a bad model response, it is the trust bridge from prompt input to tool execution and enterprise access.
Q: What breaks when an agent middleware layer is not monitored as an identity?
A: Teams lose visibility into who or what can reach internal systems, which means access reviews, secret governance, and incident response all start too late.
Practitioner guidance
- Inventory every MCP-linked non-human identity Build a complete list of MCP servers, the agents that use them, and the internal systems each one can reach.
- Scope tool permissions by business function and host reach Limit each MCP server to the smallest set of tools, APIs, and host actions required for its role.
- Separate prompt handling from execution authority Do not let untrusted prompt content influence operating system commands, configuration changes, or credential retrieval.
What's in the full article
Salt's full analysis covers the operational detail this post intentionally leaves for the source:
- The article's step-by-step explanation of how the vulnerable MCP path can reach arbitrary OS command execution.
- The specific languages, libraries, and downstream projects affected by the SDK issue.
- The article's view of which internal systems become reachable once an MCP server inherits real authority.
- The source article's recommended questions for teams trying to locate MCP servers and their permissions.
👉 Read Salt's analysis of MCP server security failures and agentic execution risk →
MCP server security gaps: what IAM and security teams need to know?
Explore further
02/08/2026 12:55 pm
MCP server security is now identity security, not just application security. The article shows that the exposed layer is neither the model nor the downstream database alone, but the non-human identity path that binds them together. When an MCP server can execute actions and reach internal systems, it becomes a privileged identity subject with governance requirements that look much closer to PAM and NHI control than to standard app review. Practitioners should treat every MCP deployment as a governed identity surface.
A few things that frame the scale:
- 24,008 unique secrets were exposed in MCP configuration files in 2025 alone, according to The State of MCP Server Security 2025.
- 53% of MCP servers expose credentials through hard-coded values in configuration files, which is why configuration hygiene is now an access-control issue as much as a deployment issue.
A question worth separating out:
Q: Who is accountable when an agent leaks data through an MCP server?
A: Accountability sits with the teams that defined the trust boundary and the controls that failed to enforce it, usually identity, platform, and security owners together. If tool authorization, context validation, or monitoring was missing, the breach is a governance failure, not just a runtime incident. Shared ownership must be explicit before deployment.
👉 Read our full editorial: MCP server security failures expose a hidden agentic attack surface
