I run proof-of-value (POV) deployments every week with enterprise companies, and the same security risk comes up in nearly every POV: developers using shadow MCP servers. Whether the server is benign or harmful, most organizations won't find out until someone installs it and immediately (typically, within ten minutes) runs it.
Across those POVs, two types of risk continue to afflict organizations, regardless of which MCP server you're looking at:
- The vulnerable server: a well-intentioned server that has a vulnerability (CVE, GHSA, etc.) in the maintainer’s code, or inherited a vulnerability from one of its dependencies.
- The poisoned server: a server that looks legitimate at install time, but exfiltrates credentials, environment variables, or secrets on its first run. Or, perhaps, introduces a reverse shell or some other form of persistence. These malicious capabilities were either crafted maliciously, or introduced by a supply-chain compromise or account takeover of a benign open-source maintainer.
Each risk needs a mitigating control.
Type 1: The Vulnerable MCP Server
In June 2025, JFrog discovered CVE-2025-6514, a critical RCE vulnerability in mcp-remote, popularly used as a way to connect MCP clients (such as coding agents) to remote MCP servers, a frequent client limitation as of last year. mcp-remote is a widely used component in the MCP ecosystem, and its weekly download count has grown several-fold over the past year, into the hundreds of thousands.
This CVE was given a CVSS score of 9.6 since mcp-remote is "exposed to OS command injection when connecting to untrusted MCP servers due to crafted input from the authorization_endpoint response URL[.]" It allows attackers to inject a command that will be opened in a web browser, leading to the execution of other tools. JFrog makes an important call-out: "On Windows, we have proven that this vulnerability leads to arbitrary OS command execution (shell commands with full parameter control). On macOS and Linux, the vulnerability leads to execution of arbitrary executables with limited parameter control." This vulnerability was fixed in version 0.1.16. JFrog did an excellent write-up on this for those readers who are curious about the actual CVE.
The risk is clear: a critical severity CVE in a publicly-available, popular software package that could be executed within minutes of download. All the developer would need to do from there is find a malicious, remote MCP server that advertises some nifty utility, connect to it, and they could be compromised. By the time anyone notices, credentials in environment variables are gone.
Most MCP servers that mcp-remote could connect to are useful and well-intentioned. The problem is that the vulnerable ones look identical to the useful ones at invocation time (especially if they are remote; those will never be loaded onto the endpoint), and this malicious command will often be missed by an EDR tool (agents often open browsers, i.e., with the help of playwright).
What the program needs
Organizations need visibility into MCP servers in the environment, who installed them, version details, and the ability to block these vulnerable servers outright. Without these capabilities, this risk is silent until an outbound traffic anomaly or an unrelated investigation surfaces it.
Type 2: The Poisoned MCP Server
Postmark is an email delivery service. It's a legitimate company and software provider. However, a bad actor published postmark-mcp on npm, released over 15 benign versions to gain a following of users, and finally added a backdoor in version 1.0.16 of the MCP server. This version secretly sent emails to their intended recipients and an external attacker-owned location. The bad actor used a slow-roll approach of trusted releases and Postmark's good reputation to compromise users. For a deeper technical dive, check out Snyk's analysis.
Though it's impossible to say how many downloads this MCP server had (it was removed from npm that same month), email and messaging-related MCP servers have grown in popularity. Who doesn't want to remove their backlog of emails, Slacks, and other messages? Getting caught up on messages is enough of a pain that you might hook up the first messaging MCP server you find to start burning down your backlog.
What the program needs
Again, it's impossible to tell for most which servers are benign and which are harmful, regardless of their utility. Organizations need visibility into which MCP servers are hooked up to their workforce's agents, and the ability to enforce a block-by-default policy, only allowing known-good MCP servers.
What an MCP security program needs
Two patterns. Four things the security program has to have ready.
- Visibility at the install point. What MCP servers exist in the environment, who installed them, when, from which registry, with what permissions. This is shadow AI infrastructure inventory, not something the CASB sees. Without this, the vulnerable-server class stays silent.
- Posture inspection of installed servers. What each server is configured to do, and whether the actual toolset matches what was reviewed at install time. Drift is a signal. This closes the supply-chain gap the poisoned-server class exposes.
- Runtime inspection of agent calls. What the agent is actually doing with each server. This is a runtime detection question, not an inventory question. It catches abuse of a server that looked clean at install time.
- A path back to the developer for every signal. The finding has to land in a workflow the developer can act on. A beautiful MCP inventory dashboard nobody on the engineering side ever opens is shelfware.
Why this lives at the agent layer
The agent layer is the only place where the full composition of every MCP server an agent has installed, and every tool call the agent is making, is visible in one record. The registry does not see what the agent does after install. The CASB does not see the MCP subprocess. The DLP does not see the tool calls happening under the developer's identity. The control plane that watches the agent is where both patterns converge, and it is the only layer where the detection question and the response question can both be answered fast enough to matter. The protocol is not going to enforce what an agent should and should not do. The agent layer can.
If you want to see what MCP inventory, posture, and runtime visibility looks like in your environment, book a demo or architecture assessment with our team.
References
JFrog Security Research, "Critical RCE Vulnerability in mcp-remote: CVE-2025-6514 Threatens LLM Clients", published 2025-07-09, last-checked 2026-07-06. https://jfrog.com/blog/2025-6514-critical-mcp-remote-rce-vulnerability/
Postmark, "Security Alert: Malicious 'postmark-mcp' npm Package Impersonating Postmark”, published 2025-09-25, last-checked 2026-07-06. https://postmarkapp.com/blog/information-regarding-malicious-postmark-mcp-package
Snyk, "Malicious MCP Server on npm postmark-mcp Harvests Emails", published 2025-09-24, last-checked 2026-07-06. https://snyk.io/blog/malicious-mcp-server-on-npm-postmark-mcp-harvests-emails/
