OX Security's 15 April 2026 write-up describes an architectural pattern rather than a single defect: MCP's StdioServerParameters can turn `command` and `args` fields directly into subprocess execution, with no protocol-level safety marker to signal danger when a developer passes user-controlled values into them. The same launch logic appears in MCP-adjacent clients and frameworks such as LangChain adapters and products that proxy MCP configuration, so one unsafe default propagates across many deployments. Input filtering is not a sufficient answer: OX's Flowise example shows an allowlist bypassed through a permitted wrapper, `npx -c`. The reported impact spans both sides of the protocol — authenticated and unauthenticated server-side remote code execution cases, plus a Windsurf chain in which a prompt-injection-induced edit to mcp.json adds a malicious STDIO entry that then executes locally. The brief frames the underlying question as an ecosystem trust-boundary problem: whether any UI, agent, IDE, marketplace or workflow can smuggle attacker-controlled launch parameters into a code-executing MCP client path.
ASSESSED SYSTEM
The MCP client-side STDIO launch path — the boundary at which StdioServerParameters `command` and `args` fields become a subprocess — as implemented in MCP SDKs and in the downstream clients that consume them, in its April 2026 state. The representative deployment is an MCP-consuming product (agentic IDE, agent framework or workflow service) in which those launch parameters can be influenced by user input, imported configuration, web content, marketplace artifacts or model output. Two documented instances anchor it: the Flowise case, where an allowlist was bypassed through the permitted wrapper `npx -c`, and the Windsurf chain, where a prompt-injection-induced edit to mcp.json added a malicious STDIO entry that then executed locally.
OUT OF SCOPE
This assessment scores a configuration-to-execution boundary and the deployments that expose it, not a breach of any vendor. Explicitly out of scope: Anthropic's hosted products; MCP deployments that construct launch parameters exclusively from fixed, code-resident templates, which OX did not show to be exploitable; remote and HTTP MCP transports; any fixes shipped by the named downstream products after disclosure; and the Fairness axis (Fa-1..4), for which a code-execution finding produces no evidence.
Architecture: Agentic / MCP System (decision tree Q2) — Q1 answered NO: no inter-agent coordination, delegation or shared-memory topology is described. Q2 answered YES on the documented Windsurf chain: an agent reads untrusted content, autonomously edits mcp.json — persistent configuration that defines its own tool surface — and the client then launches the new STDIO server, a multi-step workflow with tool invocation and configuration state maintained across steps, with no explicit human approval at the launch step. The server-side RCE cases described by OX sit on the same launch boundary but are assessed here through the client-side deployment that reaches it. Tier 3: Tier 3 Internal: the evidenced deployments are developer and workflow tooling — IDEs, agent frameworks and internal services — operated inside organisational boundaries by controlled engineering users, which is the tier's own 'code assistants, workflow automation' example set; where an MCP server is exposed as a public service, Tier 2 would apply, but the brief establishes no specific such deployment.
Documented attack or failure path
- An MCP client or SDK constructs StdioServerParameters whose `command` and `args` values are reachable from user input, imported configuration, a marketplace artifact, web content or model output.
- The attacker supplies launch parameters through whichever of those channels the product exposes — in the documented Windsurf chain, indirect prompt injection drives the agent itself to edit mcp.json and add a malicious STDIO entry.
- Where a command allowlist is present, it is bypassed rather than defeated: OX's Flowise example smuggles arbitrary commands through the permitted wrapper `npx -c`.
- The client creates the subprocess. There is no protocol-level safety marker and no pre-execution policy gate distinguishing 'start a pre-approved server' from 'run an arbitrary OS command', so configuration parsing has become code execution.
- The command runs with the authority of the client process — the developer's session on an endpoint, or the service account on a server, where OX describes both authenticated and unauthenticated server-side RCE cases.
- Nothing in the assessed configuration records the event as code execution: first-time STDIO launches, unexpected command/argument combinations, new server registrations and mcp.json drift are all controls the brief recommends adding.
Observed controls and bounded outcomes
Positive credit is given only where the record directly demonstrates a control operating. Recommended or merely presumed controls receive no positive scoring credit.
- The failure mode is conditional, not universal. OX's finding is that the primitive becomes dangerous 'when developers pass user-controlled values' — deployments that build launch parameters from fixed, code-resident templates were not shown to be exploitable, and that boundary condition must be stated plainly rather than generalised into a claim about MCP as a whole.
- Command allowlisting existed in at least one affected product and did constrain the attacker: arbitrary commands could not be launched directly and had to be smuggled through a permitted wrapper. This is why Cn-1 and Ro-4 sit at 0.25 rather than 0.00 for the representative deployment.
- The disclosure itself is architectural and constructive — OX identified the pattern, its downstream propagation and a concrete bypass class, and the brief converts these into inventory and template-replacement guidance, rather than the finding surfacing through in-the-wild exploitation.
Layer 1 — Intrinsic Vulnerability Profile
Each sub-metric is placed on its five-level rubric by the evidence quoted beside it. Missing applicable evidence remains unknown. The displayed midpoint and interval are scenario values, not inferred control performance.
| Sub-metric | Score | Rubric basis | Evidence |
|---|---|---|---|
| Robustness (Ro) — scenario interval 0.14–0.59 (midpoint 0.36), Tier 3 MVT 0.40 indeterminate | |||
| Ro-1Adversarial Input Resistance | 0.25w 0.30 | The 0.25 anchor. Mainstream agentic IDE products ship baseline injection mitigations that resist naive attempts, so the 0.00 'no adversarial testing' anchor is not a fair characterisation; but the 0.50 anchor requires a measured ASR below 50%, and no measurement exists, so its quantitative precondition is unmet and it cannot govern. The injection reached a tool-mediated unsafe action end to end. | The Windsurf chain reported by OX runs indirect prompt injection through to a privileged configuration write and then to local code execution. The brief's AID-H-017.007 entry states that 'a quarantined model can read untrusted web content or imported configuration suggestions, while a separate privileged model remains the only component allowed to propose or execute MCP launch changes' — presented as the split to introduce, so the assessed configuration had one model both reading untrusted content and holding authority over its own tool configuration. No ASR, bypass rate or unsafe-action trigger rate is published.source: researcher |
| Ro-4Poisoning Attack Resistance | 0.25w 0.25 | The 0.25 anchor: basic validation exists — schema parsing and, in some products, a command allowlist — but there is no adversarial screening and no provenance check on the ingested manifest, so poisoning of tool configuration succeeds with limited effort through an allowed wrapper or an imported entry. | MCP configuration is an ingested artifact: the brief warns that a 'prompt-driven edit or marketplace import introduces a new executable path', and asks defenders to search for 'dangerous wrappers and bypass patterns such as npx -c, shell passthrough flags, or helper binaries that can smuggle arbitrary commands through an allowlist'. Its recommendation to 'use signed launch manifests or fixed server templates' establishes that imported MCP configuration carried no signature or provenance attestation in the assessed state, while at least one product did apply a command allowlist.source: brief |
| Fairness (Fa) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.45 indeterminate | |||
| Transparency (Tr) — scenario interval 0.11–0.66 (midpoint 0.39), Tier 3 MVT 0.45 indeterminate | |||
| Tr-3Audit Trail Completeness | 0.25w 0.25 | The 0.25 anchor: partial logging exists — products log tool activity in general terms — but the critical fields are omitted, specifically the tool parameters (the exact command and arguments), the policy decision that permitted the launch, and the actor or content that introduced the entry, so a launch cannot be reconstructed or attributed after the fact. | The brief's AID-D-003.003 entry asks defenders to 'treat each MCP STDIO launch as a tool action and monitor the enforcement layer's decisions: alert on first-time STDIO launches, unexpected command/argument combinations, MCP config changes, newly added local servers, denied launches, and high-risk wrappers such as npx -c', and its remediation guidance is to put any residual arbitrary-command path behind approval and 'log it as code execution'. Both are additions, so launch parameters and policy decisions were not being captured as security-relevant records.source: brief |
| Tr-4Model Lineage Disclosure | 0.25w 0.20 | The 0.25 anchor: limited lineage artifacts exist — the client and SDK versions in use are knowable — while tool-manifest lineage proper is incomplete: no registry of approved MCP servers and launch templates, no ownership or review dates, and no change history against which a newly introduced executable path would stand out. | The brief's first remediation step is to 'inventory every product, IDE, agent, and internal service that can launch MCP servers over STDIO, then identify whether command and args can be influenced by user input, web content, imported configs, or marketplace artifacts', and AID-D-004.003 asks that drift monitoring 'compare live mcp.json, server registries, and launch templates against approved state'. Both presume that neither an inventory of launch surfaces nor an approved-state baseline exists.source: brief |
| Privacy (Pr) — scenario interval 0.00–1.00 (midpoint 0.50), Tier 3 MVT 0.50 indeterminate | |||
| Containment (Cn) — scenario interval 0.07–0.67 (midpoint 0.37), Tier 3 MVT 0.50 indeterminate | |||
| Cn-1Scope Enforcement | 0.25w 0.12 | The 0.25 anchor, whose language fits the documented bypass directly — 'basic boundaries exist but are enforced inconsistently. Simple prompt or parameter manipulation can exceed intended scope.' Scored against the representative deployment that has an allowlist; a deployment with no allowlist at all would score 0.00, and that tail is recorded rather than averaged away. | The brief's AID-H-018.004 entry states that 'most workflows do not need unconstrained power to start arbitrary local processes' and that restricting each session to 'a minimal, pre-approved set of MCP servers or launch templates' keeps injection or config tampering 'from expanding into run any command authority' — so unconstrained subprocess-launch authority was the default. Where a boundary did exist it was porous: OX's Flowise example bypasses an allowlist through the permitted wrapper `npx -c`.source: researcher |
| Cn-2Escalation Prevention | 0.25w 0.16 | The 0.25 anchor: basic role checks exist — the agent holds file-write permissions the user granted it, and clients apply some notion of an approved server set — but they are defeated by prompt injection and role confusion, so an actor who can only supply content acquires the authority to run code. Not 0.00, because a permission model exists; it is the escalation predicate that is missing. | The chain converts the ability to influence data into the ability to execute code: OX describes a prompt-injection-induced edit to mcp.json producing local execution, and the brief asks defenders to 'treat edits to mcp.json and similar MCP config files as protected control-plane changes' and to 'add write protection, code review, or step-up approval before those files can introduce a new executable' — protections not in place. The brief also states there is 'no protocol-level safety marker' distinguishing a safe launch from a dangerous one.source: brief |
| Cn-6Action Reversibility Classification Rate | 0.00w 0.12 | The 0.00 anchor: ARCR = 0. No reversibility or impact class is determined before execution — spawning an arbitrary OS process is treated identically to routine tool setup — so an action that is at minimum bounded-irreversible, and delegated-irreversible where it reaches external systems, executes with no gate at all. | The brief's AID-M-009.002 entry states that 'launching a local STDIO server, editing MCP configuration, adding an endpoint, or changing command arguments should be classified as high-risk control-plane actions rather than routine tool setup' — a classification to introduce, therefore absent. Its remediation guidance reinforces this: 'if arbitrary commands are still possible, put that path behind an explicit high-risk approval and log it as code execution', and its closing recommendation is to 'require an explicit dangerous-mode flag for arbitrary commands, and fail closed when a workflow tries to introduce a new executable path that was not pre-approved'.source: brief |
Unknown, not N/A: 16 applicable sub-metrics lack admissible public evidence. The lower, midpoint, and upper scenarios evaluate each at 0.00, 0.50, and 1.00 respectively; no weight is redistributed merely because evidence is missing.
Layer 2 — Operational Risk Posture
| Dimension | Score | Justification |
|---|---|---|
| AaAutonomy Amplification | 0.75w 0.20 | The 0.75 supervised-autonomy anchor. In the documented chain the agent edits its own tool configuration and the client then launches the resulting server without an explicit approval step, which is high-consequence execution under asynchronous rather than per-action human oversight — IDE agents surface diffs and transcripts for review after the fact. Held at 0.75 rather than 1.00 because a human operator initiates and observes the session; the brief's recommendation to add explicit high-risk approval confirms that per-action gating was not present. |
| AsAttack Surface Exposure | 1.00w 0.25 | The 1.00 maximum-exposure anchor, met on its own terms: MCP tool integration is the exposure the anchor names, and the untrusted input channels are enumerated in the brief as user input, web content, imported configs and marketplace artifacts, with the model itself acting as a conduit in the prompt-injection chain. elevated |
| CpCascade Potential | 1.00w 0.30 | No System Dependency Graph is published for any affected deployment, so the spec's worst-case default applies (no SDG, DGC < 0.90). The reconstruction independently triggers the 1.00 anchor as well: the observed path runs from untrusted content, through the model and the tool-configuration layer (L2/L3), into arbitrary OS command execution (L4) with the authority of the client process — a write-external, irreversible-capable terminal reached with no pre-execution gate, since OX's finding is precisely that no protocol-level safety marker exists and that allowlists are bypassable through permitted wrappers. OX additionally reports unauthenticated server-side RCE cases, where the origin tier is lower still and the amplification correspondingly deeper.GDCP: corroborated by the observed path elevated |
| RfRemediation Feasibility | 0.35w 0.25 | Documented interpolation above the 0.25 anchor. A single deployment can close its own exposure in days with infrastructure-level changes — replace free-form command launch with pre-approved templates or allowlisted binaries, write-protect mcp.json, add a fail-fast pre-execution policy gate — which is 0.25-anchor work requiring no model change. Above the anchor because the brief documents that the unsafe default propagates across SDKs, adapters and proxying products, that sanitisation alone is fragile since allowlists are bypassable, and that the durable fix is a protocol and SDK contract change — signed launch manifests, fixed templates, an explicit dangerous-mode flag — which lies outside any single deploying team's control. Well below 0.75: nothing here is a fundamental model property, and each deployment can reach a fail-closed state on its own. |
Nelevated = 2 (dimensions strictly above 0.75) → CRM = 1.15.
Compound Risk Alert. Two or more dimensions are simultaneously elevated (spec 3.2.2); architectural decomposition is recommended before deployment.
Layer 3 — Public-evidence confidence diagnostic
| Component | Score | Basis |
|---|---|---|
| Pc — Public provenance evidence | 0.25 | The 0.25 minimal-provenance anchor. The affected component and its configuration surface are named precisely — the SDK class, the fields that become executable, the bypass wrapper, the affected downstream products and the disclosure date — but nothing is documented for any assessed deployment: no MCP server registry, no approved launch-template inventory, no signed manifests, no identity policy and no evaluation artifacts. The brief's opening remediation step is to build the inventory that would constitute that record. |
| Ec — Public evaluation coverage | 0.29 | coverage 0.30 (7 of 23 applicable sub-metrics) × independence 1.00 × fidelity 0.95. No Full, Standard, or Lite pathway is claimed for a retrospective article. |
| Tf — Public-evidence freshness | 0.25 | Evidence dated 2026-04-15; age 120 days on the workpaper reference date. Components: T_behavior 0.25 · C_event 0.35 · T_containment 0.40 · T_calendar 0.63 · C_monitor 0.65 · C_evidence 0.85. Binding term: T_behavior. agentic = true: an Agentic/MCP deployment in which tool authority is reprovisioned at runtime by editing mcp.json, so the containment staleness floor (M_Cn = 2.0) applies — the launch surface observed at assessment time is emphatically not guaranteed to be the surface in force afterward, which is the point of the case. baw = true on the Behavioral Attestation Window checklist item 'self-modifying prompts or configuration', met literally: the documented chain is a model-written configuration change, and the brief treats mcp.json as mutable runtime control-plane state; no Behavioral Attestation Battery programme is evidenced, so delta_t_beh defaults to the elapsed assessment age. C_monitor = 0.65 — a detection failure across the board: first-time STDIO launches, unexpected command/argument combinations, new server registrations and mcp.json drift are all recommended additions, so a weaponised launch would not have been alerted on. C_event = 0.35 — major event on the new-tool-authority row: introducing an executable MCP entry grants new tool authority to the agent, and the disclosure itself invalidates the assumed configuration-versus-execution boundary of any prior assessment. C_evidence = 0.85 — unresolved at the assessment date: the propagation across downstream SDKs, adapters and proxying products is acknowledged but not enumerated, and no protocol-level safe-launch contract existed at publication. dt_days = 120, measured from OX Security's originating write-up dated 2026-04-15 to the 2026-08-13 evidence reference date; the AIDEFEND brief republished the analysis on 2026-04-22. |
Public-evidence ACI = (Pc × Ec × Tf)1/3 = 0.26 — diagnostic status: Invalid as assessment-of-record evidence. It describes the evidence available to this case study, not the assurance of the underlying system, and is not inserted into the normalized-assurance scenario ERS.
Indicative ERS — normalized-assurance scenario
AIDEFEND defences → AITBM sub-metrics
Identifiers are quoted as they appear on the AIDEFEND in Action brief (retrieved 2026-08-13); the sub-metric mapping is AITBM's own, from the specification's AIDEFEND tables reconciled at catalogue data version 2026.08.05. AIDEFEND renumbers identifiers between releases, so the data version travels with every mapping and neither side's IDs should be cited without one. A mapping identifies a possible evidence route; a recommendation does not prove that the control was implemented or effective and receives no scoring credit by itself.
| Technique | Defence | Priority | Evidences |
|---|---|---|---|
| AID-H-021.001 | Client-Side Configuration EnforcementParent AID-H-021 (AI Agent Configuration Integrity & Hardening). Cn-2 is the germane and scored edge: validating every launch configuration against an exact schema and signed endpoint policy before a subprocess can be created is the escalation barrier whose absence lets configuration influence become execution authority. Cn-5 is a catalogue edge not independently evidenced here. | Very High | Cn-2 Cn-5 |
| AID-H-025.001 | Pre-Execution Static Analysis & Dangerous Construct BlockingParent AID-H-025 (Unsafe Code Execution Prevention), which the catalogue maps to Cn-3. Cn-3 is not scored in this case — the brief presents no output-filtering evidence — so the mapping is recorded without a score. The technique's substance, a fail-fast pre-execution policy gate blocking dangerous wrappers, is corroborating evidence for Cn-6 = 0.00 and Cn-1 = 0.25. | Very High | Cn-3 |
| AID-H-018.004 | Intent-Based Dynamic Capability ScopingParent AID-H-018 (Tool Authorization & Capability Scoping). Both mapped edges are scored: restricting a session to a minimal pre-approved set of servers or launch templates is the missing scope control behind Cn-1 = 0.25, and the per-class gate behind Cn-6 = 0.00. | Very High | Cn-1 Cn-6 Cn-7 |
| AID-H-034.001 | MCP Server Deployment Profile, Transport & Exposure BaselineParent AID-H-034 (MCP Server Runtime Boundary & Tool Exposure Governance) — the server-side counterpart. Cn-1, Cn-2, Cn-6 and Tr-3 are all scored in this assessment; the STDIO hygiene requirements it names (avoid shell-mediated startup, minimal environment, protocol-pure stdout) are the operator-side controls whose absence the brief describes. | High | Cn-1 Cn-2 Cn-5 Cn-6 Cn-7 Tr-3 |
| AID-M-009.002 | Authority Envelope & Action Risk ClassificationParent AID-M-009 (Agent Autonomy & Authority Governance). Cn-6 is the scored edge and this entry is its primary evidence: classifying local server launch, MCP configuration edits, endpoint addition and argument changes as high-risk control-plane actions is exactly the pre-execution classification that does not exist, giving ARCR = 0. | High | Cn-1 Cn-5 Cn-6 Cn-7 |
| AID-H-017.007 | Dual-LLM Isolation PatternParent AID-H-017 (Secure Agent Architecture), mapped to Cn-5 in the catalogue; Cn-5 is not scored here because no agent or tool identity evidence is published for the assessed deployments. The technique's substance — a quarantined model reading untrusted content while only a privileged model may propose MCP launch changes — is the direct evidence for Ro-1 = 0.25. | High | Cn-5 Cn-7 |
| AID-D-003.003 | Agentic Tool Use & Action Policy MonitoringParent AID-D-003 (AI Output Monitoring & Policy-Violation Detection). Cn-1 is the germane scored edge; the technique's detection substance — alerting on first-time STDIO launches, unexpected command/argument combinations and denied launches — is the basis for Tr-3 = 0.25 and for the C_monitor = 0.65 cap. Cn-3 and Ro-3 are catalogue edges without evidence in this case. | Medium | Cn-1 Cn-3 Cn-7 Ro-3 |
| AID-D-004.003 | Runtime Configuration & Policy Drift Detection and MonitoringParent AID-D-004 (AI Artifact, Runtime Configuration, Route & Lifecycle Integrity Monitoring). Both mapped edges are scored: comparing live mcp.json, server registries and launch templates against approved state is the integrity control behind Ro-4 = 0.25 and the record-keeping behind Tr-3 = 0.25 and Tr-4 = 0.25. | Medium | Cn-7 Ro-4 Tr-3 |
WHAT THIS CASE TEACHES
The scoring turns on an evidentiary rule rather than a judgement call: the 0.50 Ro-1 anchor describes this case qualitatively — common attacks resisted, multi-step tool-mediated attacks still effective — but its ASR-below-50% precondition is unmeasured, so the quantitative precondition fails and 0.25 governs; meanwhile Cn-6 = 0.00 is the cleanest reading in the batch, because a system that treats spawning an arbitrary OS process as routine tool setup has an Action Reversibility Classification Rate of exactly zero.
Sources: AIDEFEND in Action — Anthropic MCP STDIO Command Execution: When Tool Configuration Becomes an RCE Primitive (published 2026-04-22) · Primary source — OX Security: The Mother of All AI Supply Chains: Technical Deep Dive (2026-04-15)