MCP Security at Plexara

What the research found

MCP's STDIO transport launches a local server by running an operating system command, and the official SDKs run that command before confirming the server actually started. Anything that can influence the command, through UI injection, a poisoned configuration file, or a prompt-injected agent, gets silent code execution on the host. OX assigned more than ten CVEs across local IDEs and self-hosted agent frameworks. Anthropic deemed the behavior by design.

How Plexara addresses it

Plexara's MCP servers run as long-lived authenticated HTTPS services. No subprocess is spawned per request, the StdioServerParameters code path is not in the request path, and the servers are written in Go using libraries we control rather than the SDKs the research targets. The exploit primitive does not exist in this deployment model.

What the research found

The hardest class of attack is not a malicious tool, it is malicious data. Instructions hidden inside content the agent reads, a database row, a stored document, an API response, can steer the agent into chaining its legitimate tools to exfiltrate other data. Invariant Labs demonstrated this against the official GitHub MCP server: a poisoned public issue drove an agent into leaking private repositories. The root cause was an over-scoped token that let the agent reach data the user could not see directly.

How Plexara addresses it

This is a shared responsibility between the platform and the calling agent, and we are candid about that. Plexara bounds the blast radius where it can: every tool call is authorized server-side, per request, against a fail-closed persona, so an agent can never exceed the calling user's own access. That removes the over-scope condition behind the GitHub exfiltration. Tools are read-oriented, SQL runs read-only with row and time limits, and every call is audited. What Plexara cannot do is stop a model from being persuaded by poisoned content, so a least-privilege user identity and defense-in-depth at the agent remain essential.

What the research found

An LLM reads a tool's description before calling it. A malicious MCP server can hide instructions in that description that tell the agent to read files or exfiltrate secrets while returning a normal-looking response. The attack depends on connecting untrusted, third-party tool descriptions into the agent.

How Plexara addresses it

Plexara's default tool surface is fixed, reviewed, and versioned by our team; there are no third-party tool descriptions in that path. Where operators add gateway connections to external MCP or REST upstreams, those connections are curated through the admin portal with encrypted credentials, persona allowlists, and audit, not pulled from a public registry at runtime. Operators decide what enters the surface.

What the research found

Two related tricks target the trust placed in an approved tool. In a rug pull, a server silently changes a tool definition after it was approved; MCP has no built-in re-approval when definitions change. In tool shadowing, a malicious server registers a tool whose description manipulates how the agent uses a different, trusted tool.

How Plexara addresses it

Plexara's native tool surface is fixed, reviewed, and versioned in source control, so there is nothing to rug-pull. Where operators connect third-party MCP or REST upstreams through the gateway, those connections are curated through the admin portal rather than pulled from a public registry, proxied tools are namespaced as connection__tool so they cannot shadow native tools, and every definition and call is audited. Operators decide what enters the surface and see when it changes.

What the research found

A gateway that proxies to third-party APIs can be turned into a confused deputy. If it forwards the client's inbound token to upstreams, the token-passthrough anti-pattern the MCP specification explicitly forbids, a stolen or misdirected token lets an attacker ride the gateway's trust into systems the user never authorized. The spec also documents consent-skipping attacks against static-client-ID OAuth proxies.

How Plexara addresses it

Plexara does not forward client tokens to upstreams by default. Each gateway connection authenticates to its upstream with separate, operator-configured, encrypted credentials: bearer, API key, or OAuth 2.1 client_credentials or authorization_code. Token passthrough exists only as an explicit opt-in and is mutually exclusive with stored credentials, so the confused-deputy condition cannot arise unless an operator deliberately enables it.

What the research found

A malicious npm package with a postinstall hook rewrites a developer's local ~/.claude.json so a sessionStart hook reroutes MCP server URLs through an attacker proxy, capturing OAuth bearer tokens as they pass, and reasserting itself after token rotation. This is a compromise of the developer's workstation and the client trust model, not of any MCP server. Anthropic classified it out of scope.

How Plexara addresses it

Nothing Plexara ships can be the vector: it is a Go service, not an npm package, with no install lifecycle hooks. As a destination, a token stolen from a compromised workstation is constrained by design. OAuth 2.1 with PKCE keeps access tokens short-lived, persona allow and deny rules scope what any token can do, and every tool call is audited. The persistent, broadly scoped, unlogged access the research warns about is exactly what the managed model limits. The real fix lives on the workstation: audit npm post-install hooks and watch the client config for unexpected URL changes.

What the research found

On the Streamable HTTP and SSE transports, predictable or unbound session IDs let an attacker replay a session ID to impersonate a client or inject events into their stream. Real implementations shipped this: oatpp-mcp used a memory pointer as the session ID (CVE-2025-6515), and the MCP Ruby SDK allowed SSE stream hijacking via session-ID replay (CVE-2026-33946).

How Plexara addresses it

Plexara generates 128-bit session IDs from a cryptographic random source, binds each session to a hash of the authenticating token, and revalidates that token on every request, including SSE streams. Sessions are never used as the authentication mechanism, which is exactly what the MCP specification requires. A session ID on its own is useless to an attacker.

What the research found

Gateways that ingest OpenAPI specs or fetch OAuth metadata by URL can be coerced into requesting internal addresses, cloud metadata endpoints (169.254.169.254), or localhost services. FastMCP's OpenAPI provider carried exactly this flaw, CVE-2026-32871, rated CVSS 10.0.

How Plexara addresses it

Plexara's spec ingestion is HTTPS-only and runs a three-layer SSRF guard: a preflight DNS check, a dial-time re-check of the resolved IP that defeats DNS rebinding, and disabled redirect following. It blocks loopback, link-local and metadata ranges, private ranges, and carrier-grade NAT.

What the research found

Several disclosed exploit families rely on end users pulling MCP servers from public registries, where a typosquatted or poisoned package can register a malicious server. The marketplace is the distribution channel for the attack.

How Plexara addresses it

Plexara users never install, add, or pull MCP servers. The set of tools is defined, built, deployed, and versioned by our team, with no user-facing marketplace and no runtime registry resolution. The distribution channel the attack needs is absent.