MCP Security Vulnerabilities: What’s Still Unpatched

What Makes MCP Security Different From Ordinary API Security?

That inversion is the reason generic API security checklists fall short here. A REST API’s threat model assumes the server is a passive responder — validate the request, return data, done. An MCP server can act autonomously on the client’s behalf: fetching context, invoking tools, and feeding new instructions back into the model’s next decision, all inside a protocol the NSA describes as reversing a familiar client-server pattern.

MCP inverts the usual client-server request pattern, creating new, largely untraced attack paths.

That single design choice is why every attack in this article — from SDK-level command execution to session hijacking — traces back to the same root cause: the protocol trusts the server to act, and trusts the client to accept what comes back.

What Are the MCP Security Risks Everyone Already Knows About?

The MCP security risks everyone already knows about are tool poisoning, confused deputy attacks, prompt injection, and token passthrough: four categories that appear, in some form, across nearly every MCP security resource published since 2025. None of these are new by August 2026. They are, however, the baseline any reader needs before the less-covered material in this article makes sense.

• Tool poisoning — a malicious or compromised MCP server embeds hidden instructions inside a tool’s description or metadata; the model reads and follows them while the user only sees the benign-looking label. First documented by Invariant Labs in April 2025 and now ranked MCP03 in the OWASP MCP Top 10.
• Confused deputy — an MCP proxy server holding elevated privileges executes an action on a user’s behalf without verifying that the user should actually have access to it. Documented in detail, including full attack-flow diagrams, in the official MCP security best practices specification.
• Prompt injection — instructions hidden in external content get executed as if the user typed them directly, ranked MCP06 in the OWASP MCP Top 10.
• Token passthrough — an MCP server accepts a token issued for a different service and forwards it downstream without validating its audience; the spec calls this an anti-pattern explicitly forbidden by design. Same source: the MCP security best practices specification.

These four show up so consistently that The SaaS Library’s own breakdown of why every SaaS tool is racing to become MCP-compatible arrived at nearly the same shortlist — tool poisoning, rug pulls, prompt injection, and weak authentication — independent of the security-vendor coverage cited above.

That overlap is the point: the known taxonomy is well documented across the industry. What none of those resources cover is what happened at the protocol and SDK level in 2026 — starting with a flaw nobody patched.

How Does MCP’s Risk Profile Change Between Local and Remote Servers?

MCP’s risk profile changes between local and remote servers because the two run on fundamentally different trust boundaries: a local server executes code directly on a machine you control, while a remote server runs on infrastructure you don’t. Red Hat’s Principal Product Security Architect, Florencio Cano Gabarda, draws this line explicitly in the company’s own MCP security guidance: local servers “usually execute OS commands or custom code locally,” while remote servers “still have security risks… but since they are not executed locally, many common risks don’t apply” (Florencio Cano Gabarda, Red Hat, July 2025).

Local and remote MCP servers fail differently, not more or less safely.

That split maps cleanly onto where each of this article’s vulnerabilities actually lives:

Neither category is safer by default; they simply fail differently. A local server that never touches the network can still hand an attacker a shell if its startup command isn’t sanitized, and a remote server can be network-hardened and still leak every session it manages if it never checks who’s actually holding a given handle.

That frame matters going into the next section, because the single largest MCP story of 2026 lives entirely in the local half of this table — and it isn’t a misconfiguration. It’s a default nobody changed.

What Is the STDIO Vulnerability Nobody Patched?

The STDIO vulnerability nobody patched is a design flaw discovered in every official MCP SDK — Python, TypeScript, Java, and Rust — where the STDIO transport executes a passed-in command regardless of whether a legitimate MCP server ever initializes, and Anthropic classified the behavior as expected rather than shipping a fix. OX Security disclosed the flaw on April 15, 2026, in a report titled “The Mother of All AI Supply Chains,” following more than 30 responsible disclosures across the ecosystem it affected.

How the mechanism works

The mechanism is narrower than it sounds, and that’s what makes it dangerous. STDIO is meant to launch a local server process and communicate over standard input and output; OX’s researchers found that user input flowing into an SDK’s server-parameter object triggers command execution immediately — before the SDK ever checks whether what got launched was a real MCP server, and the resulting error only surfaces after the command has already run.

User input reaches command execution before the SDK ever verifies a real MCP server initialized.

The four exploitation patterns

• Unauthenticated UI injection — reaching the flaw through an exposed interface with no login required
• Hardening bypasses — Flowise had built an allowlist restricting execution to python, npm, and npx; OX bypassed it in a single step using npx’s -c flag
• Zero-click prompt injection in AI IDEs — Windsurf and Cursor were both reachable without any user action beyond opening a project
• Poisoned marketplace distribution — 9 of 11 MCP registries OX tested accepted a benign trial payload with no vetting

At least ten CVEs trace back to this single design pattern, and their patch status varies sharply by vendor:

What actually shipped

OX proposed three protocol-level fixes to Anthropic: manifest-only execution, a hard SDK-level command allowlist, or an equivalent mitigation baked into the spec itself. All three were declined. The only change that shipped was a documentation update — Anthropic added a line to its SECURITY.md recommending that STDIO adapters “should be used with caution.”

Pluto Security researcher Yotam Perkal, describing a related nginx-ui MCP vulnerability in March 2026, put the underlying pattern plainly: “When you bolt MCP onto an existing application, the MCP endpoints inherit the application’s full capabilities but not necessarily its security controls.”

That’s not a line about this flaw specifically — it’s from Pluto Security researcher Yotam Perkal describing a separate nginx-ui vulnerability — but it captures exactly why a documentation change was never going to close this gap: the SDK’s default behavior is inherited by every project built on top of it, whether that project’s developers ever read the security notes or not.

Where the dispute stands

Anthropic’s position is not indefensible. STDIO is, by design, a local subprocess transport, and whoever controls the configuration that launches it is arguably already authorized to run commands on that machine. OX’s counter is that expecting every one of roughly 200,000 affected deployments to independently sanitize their inputs correctly is a distributed failure mode the SDK maintainer is better positioned to prevent than each downstream developer is. Both arguments have merit, and the dispute is still open as of this writing.

What Is Agentjacking, and Why Do Guardrails Fail Against It?

Agentjacking is an attack where a public, write-only error-tracking key lets an attacker inject malicious instructions into an AI coding agent’s trusted diagnostic feed — and it defeated explicit anti-injection instructions in 85% of tested cases. Tenet Security researchers Ron Bobrov, Barak Sternberg, and Nevo Poran disclosed the technique after finding it against Sentry’s MCP integration, reporting it on June 3, 2026, before publishing publicly between June 12 and June 17.

How the DSN exposure works

The mechanism runs through a piece of infrastructure most developers treat as harmless: a write-only Sentry DSN, a key meant only to submit error events, embedded openly in frontend JavaScript and discoverable through a simple GitHub code search. An attacker who finds one doesn’t need to breach anything — they submit a crafted error event containing hidden instructions, and when a developer’s coding agent pulls that error through the Sentry MCP server for debugging, it treats the attacker’s payload as a legitimate diagnostic and acts on it with the developer’s own privileges.

A public write-only DSN is enough to inject instructions an agent treats as a trusted diagnostic.

What the scan found

• 2,388 organizations had injectable, publicly discoverable Sentry DSNs
• 71 of those sat inside the Tranco top 1 million most-visited domains
• 85% success rate across more than 100 tested organizations
• At least one captured test environment contained a live AWS secret access key, plus identifiers for other agents connected to the same workspace

Why the guardrail failed anyway

What makes this genuinely different from ordinary prompt injection is the guardrail-defeat rate. Tenet explicitly tested configurations where the system prompt told the agent, in plain language, to treat MCP tool output as untrusted — and the agent ran the payload anyway, 85% of the time. Tenet calls this the “Authorized Intent Chain”: the agent isn’t tricked into abandoning its instructions; it follows a plausible internal chain of reasoning that makes the attacker’s command look like a legitimate extension of the task it was already asked to do.

Sentry’s response split the difference between acknowledgment and ownership. The company confirmed the finding but declined to fix the underlying issue, telling researchers it was “technically not defensible” to close. Sentry instead activated a global content filter blocking one specific payload string and pointed to model-side middleware as the correct place to solve this. Tenet open-sourced a hardening configuration, agent-jackstop, as a stopgap in the meantime.

This is the same governance gap showing up in a new place: The SaaS Library’s own reporting found that 96% of companies running AI agents can control only 21% of them — agentjacking is what that control gap looks like in practice, at the exact moment an agent decides a malicious instruction is worth acting on.

Sentry’s refusal and Anthropic’s refusal, from the previous section, aren’t the same failure — but they raise the identical question, and it deserves its own section rather than a footnote in each.

Who’s Responsible When the Protocol Owner Declines to Fix a Flaw?

Responsibility falls on whoever controls the layer where the fix would actually have to happen — and in both cases covered so far, that party looked at the fix and declined it. Anthropic classified the STDIO command-execution default as expected behavior rather than a bug; Sentry called the agentjacking vector “technically not defensible” to patch without breaking the feature it depends on. Two different companies, two unrelated vulnerabilities, and the same governance shape underneath both.

The two cases line up cleanly once placed side by side:

Two unrelated 2026 disclosures, resolved the identical way: acknowledged, then handed to someone else.

Analyst View

Responsibility falls on whoever controls the layer where the fix would actually have to happen — and in both cases, that party looked at the fix and declined it.

Daniel Voss — Technology Writer & Analyst, The SaaS Library

Neither company is wrong on the technical merits, and that’s exactly what makes this a governance problem rather than a case of corporate negligence: Anthropic’s argument — that whoever controls a STDIO launch command is already authorized to run commands on that machine — is defensible in isolation, and so is Sentry’s, that a write-only key doing exactly what write-only keys are built to do isn’t a bug.

What both arguments share is where they land: on the user. OX’s counter-argument to Anthropic applies just as cleanly to Sentry; expecting thousands of independent developers to correctly reason through a security tradeoff that a single upstream vendor could close once is a distributed failure mode, not a distributed responsibility. The NSA’s own May 2026 guidance on MCP makes a version of the same point at the protocol-design level, warning that a trusted server can change its capability or data access “without triggering any review”; the review step, in other words, is missing by default, and nobody upstream has volunteered to add it back.

This governance shape isn’t unique to MCP, either. The SaaS Library’s own reporting on broken AI containment found the identical pattern one layer up the stack: control mechanisms that exist on paper get quietly declined in practice once enforcing them costs the vendor holding the fix.

That “handed to someone else” pattern is exactly why the next section — the authentication gap — matters more than a bare percentage suggests: it’s the same abdication, measured across an entire deployment base instead of two companies.

How Many MCP Servers Actually Run Without Authentication?

Roughly 38% of scanned MCP servers run without any authentication, according to Wiz Research’s sample of 500-plus servers — and two independent scans, run by different companies with different sample sets, land within a percentage point of that same figure. That convergence matters: three separate measurement efforts, using three separate methodologies, arrived at essentially the same answer.

Three independent 2026 scans converge on the same ~38–40% unauthenticated figure.

Wiz’s own findings add a layer the raw percentage doesn’t capture on its own: MCP now shows up in 80% of the cloud environments Wiz scanned, and roughly 1 in 6 of those exposes at least one MCP server publicly. Nearly all of the servers Wiz found still negotiate the original 2024-11-05 protocol version — the version that predates the March 2025 spec update that added authentication in the first place.

That last detail explains the gap better than negligence does. A server built before March 2025 wasn’t skipping a security control that existed; it was built to a version of the protocol that hadn’t defined one yet, and nobody has gone back to upgrade it. The NSA’s May 2026 guidance frames this precisely: “associating a session to an identity is not defined by the protocol,” and MCP “currently lacks support for exchanging Role Based Access Control (RBAC) permissions at instantiation” — meaning even a server that wants to authenticate has no protocol-native way to also enforce what an authenticated caller is allowed to do.

Bloomberry’s CORS finding sharpens the exposure further: a server with no authentication and wide-open cross-origin policy isn’t just reachable — it’s reachable from any website a victim happens to have open in another tab. Censys’s growth curve is the sharpest signal of all: exposure nearly doubled in nine days, which means this isn’t a static backlog of old, unpatched servers; it’s an actively growing surface.

Three converging numbers, one missing protocol default, and a surface that’s expanding rather than shrinking is not a story about careless developers. It’s a story about a spec that added authentication over a year after adoption had already outrun it.

Why Is MCP Session Hijacking Now an SDK-Level Bug?

MCP session hijacking is now an SDK-level bug because the flaw sits inside the official SDK code itself, not inside how a developer configured or deployed it — meaning the same mistake ships automatically into every project that imports the vulnerable version. Two separate 2026 CVEs make this concrete, and both trace back to the same root cause: a session identifier that was never bound to the identity that owns it.

Two different SDKs, two different mechanisms, one shared root cause: no identity binding.

The Ruby SDK’s flaw is the clearer of the two. CVE-2026-67431, alongside a related SSE-hijack issue tracked as CVE-2026-33946, affected the transport layer’s handling of streamable HTTP and server-sent-events connections: the SDK accepted a session ID and used it to authorize tools/call requests without checking that the caller presenting it was the same party the session was originally issued to. Anthropic’s maintainers patched this in Ruby SDK version 0.23.0.

The TypeScript SDK’s flaw, tracked as CVE-2026-25536 and carrying a CVSS score of 7.1, worked differently but landed in the same place: when a single server instance reused one transport object across multiple clients, responses could route to the wrong client entirely, leaking one user’s data into another user’s session. It affected versions 1.10.0 through 1.25.3 and was fixed in 1.26.0, published February 4, 2026.

Both CVEs point at the same design gap the NSA’s May 2026 guidance already named at the protocol level: “associating a session to an identity is not defined by the protocol.” That the same session-binding gap surfaced independently in two SDKs, built by different contributors, is the strongest evidence the flaw is architectural rather than coincidental — the CVEs make the case without needing the protocol’s own documentation to restate it.

That distinction is the reason this section exists separately from the authentication gap covered above. A server can require authentication correctly and still be vulnerable to session hijacking, because authenticating who someone is at connection time says nothing about whether every subsequent request in that session is still verified as coming from that same someone. The two protections are not the same control.

If session identity is this fragile at the transport layer, the next question is what happens once an attacker doesn’t need to hijack a session at all — because the thing being attacked is the model’s own memory of what it’s already done.

What Is Context Poisoning, and How Is It Different From Tool Poisoning?

Context poisoning is an attack that targets an AI agent’s running memory during an active session, rather than the tool description it read before the session even started — and that timing difference is the entire distinction from tool poisoning. Tool poisoning corrupts what the model sees when it first decides whether to trust a tool; context poisoning corrupts what the model believes it already knows, after trust has already been granted.

Tool poisoning and context poisoning differ by when the corruption happens, not just how.

The mechanism works because of how agents handle their own accumulated state. An MCP resource, a tool result, or a running summary gets written into the session’s persisted context; if that content contains an instruction, the model doesn’t re-evaluate it as new input on the next turn — it reads the poisoned content back as though it were the model’s own prior reasoning.

Key Insight

The model doesn’t re-evaluate poisoned content as new input — it reads it back as though it were its own prior reasoning.

Daniel Voss — Technology Writer & Analyst, The SaaS Library

OWASP has formalized this as its own risk category rather than treating it as a variant of prompt injection: ASI06 in the OWASP Top 10 for Agentic Applications, classified as high-persistence and very-high detection difficulty. High persistence, in practice, means the poisoned instruction doesn’t need to be repeated — once it’s written into memory, it can influence every subsequent turn of the session.

Two documented cases show the mechanism isn’t theoretical:

• A read-only MCP server can act as a delivery channel for attacker instructions even when it exposes nothing but narrow, seemingly harmless tools — a technique researchers named “ContextCrush,” disclosed in March 2026.
• Coding agents that treat MCP tool results as persistent, unfiltered context compound the risk further: security researchers at Enkrypt AI describe this pattern in Claude Code specifically as memory with “no compression, no decay, no guardrails.”

That distinction — corrupting what’s trusted at the start versus corrupting what’s remembered later — means the two attacks need different defenses entirely. Filtering tool descriptions before installation does nothing to stop a resource that poisons memory mid-session.

Everything covered so far attacks the server side of MCP: the tool, the session, the memory the server feeds back to the client. The client side has its own gap, and it’s one almost nobody outside academic research has actually measured.

Why Is Client-Side MCP Security Still Unsolved?

Client-side MCP security remains unsolved because nearly all published research — vendor blogs, OWASP frameworks, and academic papers alike — focuses on the server, leaving the client half of the same connection almost entirely unmeasured by comparison. An MDPI-published study makes this gap explicit: MCP security research “has predominantly focused on server-side vulnerabilities,” leaving client developers without concrete guidance.

What the benchmarks show

One benchmark actually quantifies how lopsided that focus is in practice. MCPSecBench tested attacks against three MCP-connected platforms — Claude, OpenAI, and Cursor — and found client-side attacks succeeded far less often than protocol-side ones: Claude Desktop’s client-side attack-success rate measured 33.3%, because those attacks lean on prompt-injection tactics that current models increasingly refuse outright. Protocol-side attacks told the opposite story entirely: they hit a 100% attack-success rate across all three platforms tested.

Protocol-side attacks hit 100% success across all three tested platforms; client-side attacks hit 33.3%.

A separate seven-client comparison sharpens exactly where that weakness concentrates. Claude Desktop implements strong guardrails against cross-tool manipulation; Cursor, tested in the same study, proved highly susceptible to cross-tool poisoning, hidden-parameter exploitation, and unauthorized tool invocation.

The specific vectors

• Insecure credential storage — tokens kept in plaintext on the device rather than in a secured credential store
• Insufficient server validation — no certificate pinning or server attestation
• Client-side data leakage — sensitive content surfacing in local logs or caches
• Rendering exploits — a tool response containing a crafted image URL triggers the client’s own image-fetch behavior, exfiltrating whatever parameter got embedded in it

Two cases inside major clients

Amazon Q was found auto-loading MCP configuration files from workspace directories without asking for consent first — a flaw carrying a CVSS score of 8.5, patched in June 2026. Claude Code shipped a separate hook-execution flaw, CVE-2025-59536, CVSS 8.7, disclosed by Check Point in February 2026.

That MCPSecBench’s protocol-side attacks hit 100% while client-side attacks hit roughly a third tells you where the next wave of research and tooling needs to go — not toward filtering what a model says, but toward hardening the software that decides what to do with what it hears.

Have MCP Rug-Pull Attacks Actually Happened?

Yes, MCP rug-pull attacks have actually happened — the postmark-mcp incident is the first confirmed, in-the-wild case of a malicious MCP server, and it stayed undetected for fifteen versions before the malicious code activated. This moves the rug-pull scenario out of the theoretical column every other section of this taxonomy still lives in.

Fifteen clean versions preceded the malicious sixteenth — exactly the track record a review would treat as reassurance.

The package impersonated Postmark, a legitimate email-delivery service, and behaved exactly as advertised for its first fifteen released versions on npm. Version 1.0.16, released September 17, 2025, added a single line of code: every outgoing email the package handled was silently BCC’d to an external address the attacker controlled.

The package had accumulated roughly 1,500 weekly downloads and 1,643 total downloads before it was identified and removed; Postmark itself publicly disavowed any involvement once the incident became public.

That the malicious version was version sixteen, not version one, is the detail worth sitting with. A rug pull doesn’t need to fool anyone at install time; it only needs a maintainer willing to wait. Fifteen clean releases is exactly the kind of track record a security review would treat as reassurance, which is precisely why version pinning without integrity checking on every subsequent update doesn’t actually close this gap.

This is also the point where the article’s taxonomy closes the loop back to where it started: tool poisoning corrupts a description before installation, context poisoning corrupts memory mid-session, and rug pulls corrupt the software itself, after trust has already been earned the slow way.

What Is the SHIP Audit for Auditing MCP Security Today?

The SHIP Audit is a four-question framework — Server trust, Handle binding, Input execution, Provenance — that maps directly onto the four failure categories this article documented, rather than a generic checklist bolted on after the fact.

The SHIP Audit: four questions mapped directly to this article’s four documented failure categories.

What Does the SHIP Audit Actually Find When Applied to Real 2026 Incidents?

Running the SHIP Audit against this article’s own documented cases — rather than a hypothetical deployment — turns the framework from a checklist into a verification tool, since every input here is a real, cited incident rather than an assumption.

Every one of the four questions fails against at least one real, named 2026 incident — which is the honest argument for running this audit now rather than treating it as precautionary. This isn’t a hypothetical framework tested against imagined threats; it’s a framework built directly from confirmed failures, checked against those same failures, and failing in exactly the places the article already documented.

How Do You Actually Mitigate These MCP Vulnerabilities Today?

You mitigate these MCP vulnerabilities today by working through the SHIP Audit in priority order — Server trust and Input execution first, since both trace back to unpatched defaults covered earlier, followed by Handle binding and Provenance once the immediate exposure is closed.

This week — close what’s already exploitable

• Update to the patched SDK versions named earlier: TypeScript SDK 1.26.0+, Ruby SDK 0.23.0+, and MCP Inspector 0.14.1+.
• Require authentication on every remote MCP endpoint; the 38–40% exposure figures describe servers that skipped this step entirely.
• Block public-IP exposure of any MCP-connected service that has no business being internet-reachable.
• If your stack uses the Sentry MCP integration with a coding agent, rotate the DSN and apply Tenet Security’s agent-jackstop hardening configuration.

Within 30 days — close what a scan will catch

• Sandbox all local tool execution using seccomp, AppArmor, SELinux, or platform-equivalent containment.
• Treat any user input that reaches a STDIO configuration as untrusted by default; allow only pre-approved commands.
• Add message signing and replay protection per the OWASP Application Security Verification Standard’s cryptographic-verification requirements.
• Deploy tool-description scanning in your CI pipeline, re-running it on every server update — this is the specific control that would have caught the postmark-mcp rug pull.

Strategic — fixes that require redesign, not patching

• Adopt signed, versioned tool definitions with policy-based access control, following the approach ETDI (Enhanced Tool Definition Interface) proposes.
• Require server attestation or certificate pinning for every remote MCP connection your client makes.
• Bind every session to a verified identity server-side — the Handle-binding half of SHIP.
• Centralize MCP telemetry into a SIEM — MCP carries no mandatory logging requirement by default.

None of this is a one-time project. This is the same audit discipline The SaaS Library covers in its guide to auditing a SaaS stack for shadow AI — the difference here is that the thing you’re auditing is a sanctioned protocol whose own maintainers have already declined to fix two of the flaws covered in this article.

The SHIP Audit gives you the four questions. It doesn’t tell you which answer changes first if Anthropic or Sentry reverses course — and that’s exactly where this article closes.

Where Is MCP Security Headed Next?

MCP security is headed toward a spec that finally mandates what it’s spent two years leaving optional — but the July 28, 2026 revision that does the most structural work still stops short of requiring authentication outright. The revision removes the Mcp-Session-Id header, the initialize handshake, and resumable streams entirely, addressing the session-binding weaknesses covered earlier at the protocol level.

That’s a meaningfully different fix than anything covered in the mitigations above: every mitigation there works around a default the spec still permits; this is the first change that removes the vulnerable default itself, for anyone who adopts the new spec version.

Whether that adoption happens quickly is a separate question from whether the fix is good, and the STDIO story earlier in this article is the reason for that caution: Anthropic had a clear, proposed fix for a confirmed, actively-exploited flaw in April 2026 and still chose a documentation update over a protocol change.

One more development is worth naming precisely because of what it could become in the wrong hands. VIPER-MCP, an automated vulnerability-auditing framework, found 106 confirmed zero-day vulnerabilities across 39,884 real-world MCP server repositories, with 67 CVEs assigned from that single research run. That’s a legitimate defensive tool — but a tool that can find 106 zero-days automatically across tens of thousands of repositories is also, functionally, a blueprint for anyone who wants to run the same scan with different intentions.

Conclusion

MCP security in 2026 isn’t a story about careless developers — it’s a story about two of the year’s biggest disclosures ending the same way: acknowledged, and handed to someone else to fix.

The SHIP Audit — Server trust, Handle binding, Input execution, Provenance — turns that taxonomy into four questions you can run against your own deployment this week, starting with Server trust and Input execution, since both trace directly to unpatched 2026 defaults covered in this article.

If you haven’t audited your MCP servers since before April 2026, that gap is where to start.