How to Trust an MCP Server Before You Connect It: Four Public Failures From This Autumn, What Went Wrong in Each, and the Checks That Would Have Caught Them
Before you connect an AI agent to an MCP server, check three things: who runs it, whether its sign-in step can be steered by the server itself, and whether it acts on a credential the caller never brought. Those three questions would have caught the four public failures below, all reported between August and October 2026. An MCP server is a program your agent trusts to describe tools and, often, to hold keys, so connecting one is closer to installing software than to opening a web page.
What is the MCP trust problem?
The Model Context Protocol lets an agent call tools hosted by another program. Two things make that risky. The server tells the agent things the agent then acts on: where to sign in, what tools exist, what to run. And the agent, or the server, usually holds a credential that can do real work. If either side believes something it should have checked, the credential does the attacker's work. In all four cases below the attacker brought no key of their own.
What went wrong in four real cases
OpenCode ran a hostile server's sign-in link. Eilon Cohen of Pillar Security reported it on August 29. When OpenCode connects to a remote MCP server that needs authorization, the server answers with the address of its login page. OpenCode passed that address, unchecked, to the npm package open (version 10.1.2) to launch a browser. On Windows and under WSL, that package built a PowerShell command around the address without escaping it, and PowerShell expands a command tucked inside a double-quoted string. So an ordinary-looking https address could run a command as the developer. Versions 1.0.137 through 1.18.32 were affected, and the fix shipped on September 28 in 1.18.33 as a refactor with no CVE and no security advisory. Pillar proposes a 9.8 score and calls it its own proposal. Nobody has reported exploitation. The package was downloaded 11,639,646 times between September 19 and October 18, according to npm's counter.
The official MCP Python SDK let a server name its own login service. Yuval Elbar of Cycode found it, published as GHSA-qx49-fqc8-xw99 on September 28. The SDK normally checks that the login service's identity matches what the resource expects. But if the server declined the first question with a 404, the SDK fell back to metadata the server supplied, and the expected identity was empty. An empty expectation matches anything. Per Cycode, the person approving the login still sees the real provider's page, while the client secret, the authorization code and the proof key leak. It is fixed, and nobody has reported exploitation. The package was pulled 219 million times in the prior month.
Grafana's MCP server accepted a session nobody issued. Ariel Fogel of Pillar Security reported two problems on August 2. The server checked that a session-ID header looked right, not that the server had issued it, so anyone who could reach it could invent one, list the tools and call them, and those calls ran on the Grafana service-account token in the server's environment. Grafana added optional bearer-token authentication in version 1.1.0 on August 10. The second problem got CVE-2026-19516, rated 9.1: a tool honored a caller-supplied header naming where the server should send its request, so the caller chose the destination. In a lab with canary credentials Pillar used it to walk a cloud metadata flow.
AWS AgentCore's own shell leaked its token. Niv Rabin of Unit 42 published it on September 18. A support ticket carried a hidden HTML comment telling the agent to download and run a script. The harness ships with a shell tool on by default, and in the test it ran as root with the same user ID as the harness process. The script read that process's memory, found a 1,034-byte token for the operator's service account and sent it out.
Which checks would have caught each?
Who runs it. Pin the exact server and version you reviewed, and read its dependency list. The OpenCode flaw lived in a dependency, not in OpenCode's own logic.
Can the server steer the sign-in? Treat every address, issuer and endpoint a server hands back as untrusted input. The Python SDK case and the OpenCode case are the same lesson: the server told the client where to go and the client believed it.
Does it act on a credential the caller never brought? If a server runs calls on its own stored token, anyone who can reach it inherits that token. Require the caller to authenticate, scope the server's token to the least it needs, and keep it off shells and process memory.
Does the agent have a shell it does not need? AgentCore's shell tool was on by default and ran as the harness's own user. Turn off tools you do not use and run the rest unprivileged.
Does your version checker work from advisories? OpenCode's fix had no CVE and no advisory, so a scanner that works from advisories had nothing to say. Read the vendor changelog for anything that touches sign-in, session handling or shell execution, and do not read "no known vulnerabilities" as "safe."
What should you do this week?
List every MCP server your agents connect to, including ones a developer added to a local config. Remove any you cannot name an owner for. Upgrade OpenCode to 1.18.33 or later and the official MCP Python SDK past the fixed release if you use either. If you run Grafana's MCP server, use 1.1.0 or later and turn on the bearer-token option. Turn off default-on shell tools in agent harnesses you operate. Then read each server's stored credentials and ask what happens if a stranger can reach it.
Limits
This summarizes four researchers' published findings. We did not reproduce any of them. We did not review the AgentCore harness beyond Unit 42's account. Nobody has reported exploitation of the OpenCode or Python SDK issues, and we say nothing about exploitation of the others beyond what the researchers report. The severity scores are theirs.
Five percent of this is wrong somewhere. It always is. A vendor advisory or a follow-up from the researchers could change a detail.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments