By-design RCE, sleeper backdoors, and a supply-chain threat bleeding into Web3 wallets

Table of Contents

  1. Executive Summary (TL;DR)
  2. Introduction — When "Working As Intended" Becomes the Most Dangerous Thing
  3. The Structural Flaw — When Design Intent Is the Vulnerability
  4. Sleeper MCP — Trigger-Based Doomsday Attacks
  5. The Web3 Problem — Wallets on a Single Machine
  6. A Recurring MCP Audit Program
  7. The Quieter Attack — Bias Injection and Behavioral Drift
  8. Conclusions and Recommendations
  9. References

Executive Summary (TL;DR)

The Model Context Protocol (MCP), which Anthropic released in November 2024, has effectively become the industry standard for connecting AI agents to external tools. In April 2026, however, OX Security published findings showing that a design-level flaw in MCP's STDIO transport enables remote command execution (RCE) across every implementation built on Anthropic's official SDKs. Anthropic has refused to issue a root-level patch, calling the behavior "expected."

This report reframes the incident not as a single vulnerability but as a structural problem across three layers:

  1. MCP is an ideal substrate for sleeper-style attacks — components that behave normally for months and then branch into malicious paths only when a specific trigger is met.
  2. When combined with the single-machine, single-operator reality of Web3 wallet usage, MCP amplifies the attack surface dramatically, collapsing multi-sig security into a single point of failure.
  3. Even without RCE, an automated MCP can bias search results and long-term decision-making, producing a slow decision drift in both individuals and organizations.

The practical conclusion is simple. MCP is a convenient standard, but on the current architecture the notion of a "trusted MCP server" is largely an illusion. Enterprises — Web3 or otherwise — need to isolate bulk assets in external escrows that MCP cannot reach, and submit every deployed MCP to a recurring audit program covering SBOM, runtime behavior, and sleeper-trigger detection.

Key Judgments

# Judgment Confidence
KJ-1 The MCP STDIO command-injection flaw is not a coding mistake but an architectural design decision, and with Anthropic declining a root patch it will persist as a long-tail supply-chain riskacross the ecosystem. High
KJ-2 The Sleeper MCP— a component that looks benign for months and then branches malicious on a trigger — will be the most consequential future attack pattern. It is a race between discovery andtrigger, not discovery and patch. High
KJ-3 The 2026-03-31 Axios NPM compromiseattributed to North Korea-nexus UNC1069 (Sapphire Sleet) demonstrates that every technique needed for a Sleeper MCP scenario — registry takeover, post-install hooks, cross-platform payload delivery — is already battle-hardened by DPRK operators. High
KJ-4 Most Web3 multi-sig deployments concentrate all real signing keys on a single host OS; one compromised MCP on that host collapses multi-sig into a single point of failure. Medium-High
KJ-5 MCP-mediated bias injectioncan shift individual and organizational decisions irreversibly over months to years — without ever triggering an RCE alert. Medium

1. Introduction — When "Working As Intended" Becomes the Most Dangerous Thing

Traditional vulnerabilities are mostly about badly written code: buffer overflows, SQL injection, authentication bypasses. They are implementation flaws, and patching plus education can drive them down over time.

MCP's situation is different. OX Security's April 2026 report, "The Mother of All AI Supply Chains", shows that command injection through STDIO is possible at the architectural level in Anthropic's official SDKs across Python, TypeScript, Java, and Rust. This single design choice sits underneath more than 7,000 publicly accessible servers, up to 200,000 vulnerable instances, and more than 150 million downloads [2][4].

Anthropic's position makes it worse. After repeated disclosures urging a protocol-level fix, Anthropic replied that the behavior is "expected" and does not qualify as a valid security vulnerability because the user is given an opportunity to approve or deny file changes [6]. The security burden is pushed onto downstream developers, which is exactly how systemic supply-chain risk is born.

This column reads the incident at three depths: the protocol flaw itself, its combination with sleeper-agent techniques, and the second- and third-order effects on Web3 wallets, AI-mediated search, and human cognition.

2. The Structural Flaw — When Design Intent Is the Vulnerability

2.1 The Gap Between STDIO Configuration and Command Execution

MCP is a universal adapter between LLM-driven agents and external systems. When an MCP client spins up a local server over STDIO, it passes an OS command string, which is executed as a subprocess on the host [7].

The core flaw is this: the MCP runtime checks whether the launched process completes an MCP handshake, but the OS command itself has already executed before that check happens. The user is shown a friendly "failed to start MCP server" error, while the attacker's arbitrary command has already run on the host. By default there is no sandbox, no input sanitization, and no allowlist [5].

"Pass in a malicious command, receive an error — and the command still runs. No sanitization warnings. No red flags in the developer toolchain. Nothing." — OX Security, 2026 [2]

2.2 Four Attack Families

OX Security enumerates four distinct exploitation families built on the same root cause [2][8]:

# Attack Family Affected Projects
① Authenticated / unauthenticated command injection AI frameworks with public UIs — IBM LangFlow, GPT Researcher, etc.
② Hardening bypass Flowise, Upsonic — even after extra protections applied
③ Zero-click prompt injection AI IDEs — Cursor, VS Code, Windsurf, Claude Code, Gemini-CLI (CVE-2026-30615)
④ Marketplace poisoning 9 of 11 MCP marketplaces published a PoC payload with no review (LobeHub, Cursor Directory)

2.3 Scale and Related CVEs

OX Security successfully executed commands on six live production platforms with paying customers, coordinated more than 30 disclosures, and drove more than 10 Critical/High CVE patches [3]. Related CVEs rooted in the same issue include:

CVE Target Note
CVE-2025-49596 MCP Inspector
CVE-2025-54136 Cursor
CVE-2025-54994 @akoskm/create-mcp-server-stdio
CVE-2026-22252 LibreChat
CVE-2026-22688 WeKnora
CVE-2026-30615 Windsurf zero-click

Affected server projects include LiteLLM, LangChain, LangFlow, Flowise, LettaAI, and LangBot. A Korean Daum/Boannews report covering the same story framed it bluntly: "Under Anthropic's inaction, the threat is spreading exponentially." [1]

3. Sleeper MCP — Trigger-Based Doomsday Attacks

3.1 Theoretical Background — Anthropic's Own Research

Ironically, the most systematic early description of a "looks-benign-until-a-trigger-fires" model was published by Anthropic itself. The 2024 paper "Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training" (arXiv:2401.05566) demonstrated that models trained to emit vulnerable code only when a specific trigger appears (e.g., the year string "2024") retain this backdoor behavior through standard safety training, including SFT, RL, and adversarial training. Adversarial training can even teach a model to hide its trigger better [9].

In February 2026, Microsoft published "The Trigger in the Haystack," which identifies signatures of poisoned models — in particular a "Double Triangle" attention pattern and output-distribution collapse — as a basis for architectural auditing [10]. A subsequent paper on semantic-drift detection using Sentence-BERT and canary prompts reports real-time detection accuracy of 92.5% with 100% precision on a known sleeper-agent model [11].

3.2 The Sleeper MCP Scenario

Combine the two threads and the most probable class of future attack becomes the sleeper MCP:

  1. A legitimate-looking MCP server — say a scheduling assistant, a translation tool, or an on-chain data lookup — is published to a marketplace. The code is open-source; for months it behaves perfectly.
  2. After trust accumulates, the publisher pushes a subtle dependency update. The update branches into a malicious path only when a trigger is satisfied: date past 2026-Q4, a specific environment variable, or keywords such as transfer, withdraw, approve in recent conversation.
  3. Once triggered, the MCP either exploits the STDIO injection flaw to run arbitrary commands on the host, or manipulates the LLM prompt to swap recipient addresses and allowances at the final signing step.
  4. From the victim's perspective, there was "just one error that one time." Even after-the-fact log review is hard, because the malicious branch looks almost identical to the normal one.

The defining property of this threat is temporal non-determinism. Traditional vulnerabilities are a race between discovery and patching. A sleeper MCP is a race between discovery and trigger. Among millions of deployed instances, even a single successful trigger can fan out through a supply chain that was itself a single point of origin — which is precisely what doomsday attack means in this context, an attack framed around the assumption of inter-state total warfare.

3.3 North Korea's Supply-Chain Poisoning and the Sleeper MCP Scenario

Within the sleeper MCP threat model, the most acute problem facing South Korea is precisely the sleeper MCP weaponized by North Korea for social destabilization. DPRK operators already use ChatGPT and a range of LLMs as operational tooling, and the widely reported pattern of DPRK agents impersonating Chinese nationals to secure remote engineering jobs at Silicon Valley Big Tech and AI startups continues to expand the access surface available to them.

Recent North Korean activity can be summarized in two strands: cryptocurrency theft and software supply-chain attacks. The March 31, 2026 Axios NPM supply-chain compromiseis the clearest exemplar of the latter. Google Threat Intelligence Group (GTIG) and Microsoft Threat Intelligence both attributed the incident to the North Korea-nexus actorUNC1069(Microsoft'sSapphire Sleet). The attackers injected a malicious dependency named plain-crypto-js into the axios package — which averages over 100 million weekly downloads — to distribute the cross-platform WAVESHAPER.V2 RAT on Windows, macOS, and Linux [21][22]. The malicious versions were only on the registry for approximately three hours, yet roughly 3% of the entire axios userbase fell within the exposure window [23][24].

The implication for the MCP threat model is direct. DPRK operators have already industrialized every technique a sleeper MCP operation would require:

  1. Takeover of the trust chain of legitimate registries (NPM, PyPI).
  2. Abuse of package-manager auto-execution paths such as postinstall hooks.
  3. Multi-platform payload dispatch across Windows, macOS, and Linux.
  4. Post-install self-destruction artifacts to frustrate forensics [23].

MCP servers are themselves distributed as npm/pip packages or GitHub repositories, and they share the same supply-chain surface: STDIO defects, post-install hooks, and configuration files that get edited automatically. In the short term, DPRK-aligned actors are therefore likely to iterate targeted MCP poisoning experiments against South Korea and other priority states. In the medium to long term, the design objective is unlikely to remain single-incident financial theft; it will shift toward perception manipulation, policy distortion, and ultimately the "doomsday attack" scenariosdescribed in §3.2. This is why MCP sleeper risk deserves to be treated not as a mere security bug but as anational-security matter.

4. The Web3 Problem — Wallets on a Single Machine

4.1 The "But We Use Multi-Sig" Illusion

Most Web3 projects will tell you they protect treasury with multi-sig (Gnosis Safe et al.). In practice, two or three signers very often share a single host: the same Chrome/Arc profile, the same MetaMask / Phantom / Rabby extension stack, the same macOS or Windows account.

Layer on top of that Cursor, VS Code, Windsurf, Claude Code, and any MCP servers you installed, and the net effect is that every real signing key in your multi-sig lives on a single host OS. One MCP with an RCE flaw, or one sleeper MCP, and multi-sig degrades to a single point of failure.

4.2 The Current MCP–Wallet Integration Pattern

Google Cloud's December 2025 analysis notes that the vast majority of cryptocurrency MCP servers are designed around "give the agent a private key" on a self-hosted setup [14]. Even the upstream wallet-agent repository prints the warning "this software has not been audited … use only on testnets or local development environments" — a warning that real users cheerfully ignore.

Reports on the 2026 OpenClaw / ClawJacked incidents, where a single malicious-website visit gave attackers the same privilege level as the AI agent itself — files, credentials, wallets — show that this is not a theoretical risk. Security coverage converged on one point: "Most crypto MCP implementations still take the dangerous 'give the agent your private key' approach — exactly the scenario ClawHavoc attackers were counting on." [15]

4.3 Recommended Architecture — External Escrow + MCP Isolation

Minimum design principles — applicable to Web3 and general startups alike:

  1. Keep bulk assets in an external escrow MCP cannot reach — custodial accounts, cold wallets, HSM-backed multi-sig. Operational hot wallets should never carry more than one day's throughput.
  2. Perform signing only on dedicated signing hardware— air-gapped devices or minimally provisioned Mac minis / Ledger Stax. Donot install MCP, AI extensions, or dev tools on these machines.
  3. On dev/analysis machines, run MCP servers bound to 127.0.0.1 only, inside a sandbox (Docker, Firecracker, separate OS user), and never trust externally supplied MCP configuration input [13][16].
  4. Keep browser wallets out of signing machines, or at minimum in a dedicated browser profile. No profile should simultaneously host a wallet, AI agents, MCP bridges, and research bookmarks.
  5. Multi-sig signers must be separated by physical hardware, network, and location. "Three laptops in the same office" is not decentralization.

5. A Recurring MCP Audit Program

5.1 Minimum Checklist

MCP is not a set-and-forget component. Every organization should run the following checks at least quarterly — monthly in high-stakes environments:

  • SBOM — maintain an internal registry of every MCP server in use, with version, hash, and origin (marketplace URL, GitHub commit).
  • Provenance vetting — treat MCPs from non-GitHub marketplaces as higher risk. OX's test showed 9 of 11 marketplaces accepted a malicious upload without review [7].
  • STDIO configuration review — identify any inputs in MCP server config that accept arbitrary OS command strings, and whether those inputs can be modified over the network (LangFlow / Flowise-style UI checks).
  • Runtime monitoring — pipe MCP tool-call logs into SIEM, alert on new tool registration, privilege expansion, and unusual egress domains.
  • Patch state — include the full MCP-related CVE list in monthly vulnerability scans.

5.2 Sleeper-Trigger Pre-Detection

Sleeper MCPs do not show up in classical vulnerability scanners. Pragmatic mitigations today:

  1. Semantic-drift monitoring — embed tool-call patterns with Sentence-BERT and watch how they change over time. Canary-prompt inconsistency is a strong signal [11].
  2. Schema-conformance auditing — compare MCP tool outputs against their declared schema. A translation MCP that suddenly starts returning URLs or wallet addresses is drifting out of contract.
  3. Differential sandboxing — run the same MCP in multiple regions, time zones, and prompt contexts; compare branches.
  4. Supply-chain signing — require cryptographic signatures and reproducible builds for model weights, MCP bundles, and dependency packages whenever possible.

6. The Quieter Attack — Bias Injection and Behavioral Drift

6.1 "Attacks Without RCE"

MCP does not need to reach code execution to be dangerous. An automated MCP mediating a human's search and decision pipeline is itself a new attack surface, because MCP controls the sources that make up the LLM's context — files, pages, databases, internal documents.

Cognitive-bias susceptibility in LLMs is now well-established. Knipper et al. (2025) report average susceptibility rates of 17.8–57.3% across major models [17]. A PNAS 2025 paper shows that LLMs do not merely reproduce human biases in moral decision-making — they can amplify them [18]. Other work demonstrates that cognitive biases can be embedded into product descriptions as adversarial attacks on LLM-based recommenders [19].

6.2 Learning-Bias Injection Scenarios

A subtler sleeper MCP does not even need to own the host. It can:

  • Consistently skew search results on a specific social phenomenon, policy, company, or individual. The LLM summarizes and reinforces the skew.
  • Preferentially surface evidence that confirms what the user already believes (confirmation bias), exploiting the "LLM effect" documented by Chen et al. (2024) [20].
  • Re-anchor decisions about a token, stock, or property by repeatedly presenting a particular price point or time window.
  • Micro-adjust framing to shift the user's vocabulary over time, producing second-order bias in what the user writes to others.

6.3 Long-Term Harm — Decision Drift in People and Organizations

This is not a one-shot incident but a months-to-years-long decision drift. Victims cannot point to a single moment when their judgment changed. Organizations discover, too late, that the tone and framing of their strategy memos and meeting notes has moved in a consistent direction.

Because detection usually arrives after the damage is irreversible, this class of attack can be arguably worse than RCE. MCP audits therefore must include information-diversity metrics — a measure of where and from how varied a set of perspectives the organization's AI-mediated knowledge is actually drawn.

7. Conclusions and Recommendations

MCP's problem is not one vendor's mistake. It is the first settlement of the structural trade-off the AI agent ecosystem accepted in exchange for speed. Since Anthropic has declined to patch the protocol, participants must treat MCP under the following assumptions:

  1. All MCP servers are untrusted by default. Do not put them in production without signing, sandboxing, and allowlists.
  2. Keep assets off the same OS as your MCP. Isolate bulk value in external escrow, cold wallets, or HSM-backed multi-sig. Do not install MCP on signing hardware.
  3. Multi-sig must be distributed across machines, networks, and physical locations. Multi-sig on a single host is not multi-sig.
  4. MCP is a recurring-audit object. At least quarterly, review SBOM, CVEs, semantic drift, canary responses, and information diversity.
  5. Monitor MCP-mediated bias, not just MCP-mediated code execution. Track tone, framing, and source diversity inside your own documents.

Security is not the opposite of speed — it is the design that keeps speed sustainable. The MCP ecosystem is in the middle of its explosive-adoption phase, and structural flaws tolerated now will compound. The right question today is not whether to use MCP, but which isolation, verification, and audit layers must be installed alongside it.

References

[1] Won Byeong-cheol, "Under Anthropic's Inaction, the 'MCP' Supply-Chain Security Threat Is Spreading Exponentially," Boannews / Daum, 2026-04-21. https://v.daum.net/v/20260421171629362

[2] M. Siman Tov Bustan et al., "The Mother of All AI Supply Chains: Critical, Systemic Vulnerability at the Core of Anthropic's MCP," OX Security, 2026-04-15. https://www.ox.security/blog/the-mother-of-all-ai-supply-chains-critical-systemic-vulnerability-at-the-core-of-the-mcp/

[3] R. Lakshmanan, "Anthropic MCP Design Vulnerability Enables RCE, Threatening AI Supply Chain," The Hacker News, 2026-04. https://thehackernews.com/2026/04/anthropic-mcp-design-vulnerability.html

[4] K. Townsend, "'By Design' Flaw in MCP Could Enable Widespread AI Supply Chain Attacks," SecurityWeek, 2026-04. https://www.securityweek.com/by-design-flaw-in-mcp-could-enable-widespread-ai-supply-chain-attacks/

[5] Infosecurity Magazine, "Systemic Flaw in MCP Protocol Could Expose 150 Million Downloads," 2026-04. https://www.infosecurity-magazine.com/news/systemic-flaw-mcp-expose-150/

[6] IT Pro, "AI agents using Anthropic MCP could be a vector for supply chain attacks, claim researchers," 2026-04. https://www.itpro.com/security/ai-agents-using-anthropic-mcp-supply-chain-attacks-claim-researchers

[7] BD Tech Talks, "Anthropic's MCP vulnerability: When 'expected behavior' becomes a supply chain nightmare," 2026-04-20. https://bdtechtalks.com/2026/04/20/anthropic-mcp-vulnerability/

[8] Computing UK, "Flaw in Anthropic's MCP putting 200k servers at risk, researchers claim," 2026-04. https://www.computing.co.uk/news/2026/security/flaw-in-anthropic-s-mcp-putting-200k-servers-at-risk

[9] E. Hubinger et al., "Sleeper Agents: Training Deceptive LLMs that Persist Through Safety Training," Anthropic, arXiv:2401.05566, 2024. https://arxiv.org/abs/2401.05566

[10] Microsoft Research, "The Trigger in the Haystack: Extracting and Reconstructing LLM Backdoor Triggers," 2026-02.

[11] "Detecting Sleeper Agents in Large Language Models via Semantic Drift Analysis," arXiv:2511.15992, 2025. https://arxiv.org/pdf/2511.15992

[12] Pivot Point Security, "What is the Model Context Protocol (MCP) in AI and Why Does It Scare Cybersecurity Pros," 2026-03. https://www.pivotpointsecurity.com/what-is-the-model-context-protocol-mcp-in-ai-and-why-does-it-scare-cybersecurity-pros/

[13] Practical DevSecOps, "MCP Security Vulnerabilities: How to Prevent Prompt Injection and Tool Poisoning Attacks in 2026," 2026-01. https://www.practical-devsecops.com/mcp-security-vulnerabilities/

[14] Google Cloud Blog, "Using MCP with Web3: How to secure blockchain-interacting agents," 2025-12. https://cloud.google.com/blog/products/identity-security/using-mcp-with-web3-how-to-secure-blockchain-interacting-agents

[15] BlockEden.xyz, "OpenClaw's 'Lobster Fever' Became Web3's Biggest Security Wake-Up Call of 2026," 2026-03-12. https://blockeden.xyz/blog/2026/03/12/openclaw-lobster-ai-gateway-web3-security-crisis/

[16] Red Hat Blog, "Model Context Protocol (MCP): Understanding security risks and controls," 2025-11. https://www.redhat.com/en/blog/model-context-protocol-mcp-understanding-security-risks-and-controls

[17] R. A. Knipper et al., "The Bias is in the Details: An Assessment of Cognitive Bias in LLMs," arXiv:2509.22856, 2025. https://arxiv.org/pdf/2509.22856

[18] "Large language models show amplified cognitive biases in moral decision-making," PNAS, 2025-06. https://www.pnas.org/doi/10.1073/pnas.2412015122

[19] "Bias Beware: The Impact of Cognitive Biases on LLM-Driven Product Recommendations," arXiv:2502.01349, 2025. https://arxiv.org/html/2502.01349v4

[20] N. Chen et al., "AI Can Be Cognitively Biased: An Exploratory Study on Threshold Priming in LLM-Based Batch Relevance Assessment," SIGIR-AP 2024. arXiv:2409.16022.

[21] Google Threat Intelligence Group, "North Korea-Nexus Threat Actor Compromises Widely Used Axios NPM Package in Supply Chain Attack," Google Cloud, 2026-04. https://cloud.google.com/blog/topics/threat-intelligence/north-korea-threat-actor-targets-axios-npm-package

[22] Microsoft Threat Intelligence, "Mitigating the Axios npm supply chain compromise," Microsoft Security Blog, 2026-04-01. https://www.microsoft.com/en-us/security/blog/2026/04/01/mitigating-the-axios-npm-supply-chain-compromise/

[23] Ionut Arghire, "Axios NPM Package Breached in North Korean Supply Chain Attack," SecurityWeek, 2026-04. https://www.securityweek.com/axios-npm-package-breached-in-north-korean-supply-chain-attack/

[24] Tenable Research Special Operations, "FAQ about the Axios NPM Supply Chain Attack by North Korea-Nexus Threat Actor UNC1069," 2026-04. https://www.tenable.com/blog/faq-about-the-axios-npm-supply-chain-attack-by-north-korea-nexus-threat-actor-unc1069

© 2026 Dennis Kim (김호광) · Published as part of an independent CTI archive (TLP:GREEN). Contact: [email protected] · GitHub: gameworkerkim/CYBER-THREAT-INTELLIGENCE-REPORT