[AVE] New class: mcp-stdio-launch-config-injection (registry_metadata layer)

[chaksaray]

Before you open this issue

• I have searched the registry at ave.bawbel.io and the records/ directory
• This is a genuinely distinct behavioral class, not a variant of an existing record
• I have a citable primary source (CVE, paper, disclosure, or working PoC)

---

Behavioral fingerprint

Untrusted data (from a config file, registry entry, UI form, or a model-influenced file edit) reaches the command/args fields that an MCP client uses to spawn an MCP server as a STDIO subprocess, with no validation gate between "configuration data" and "process execution" — the OS executes whatever command the config specifies, under the client application's own privileges, before any MCP protocol handshake occurs.

Why this is a new class, not a variant

Checked against AVE-2026-00001 (Metamorphic Payload) and AVE-2026-00034 (Dynamic Skill Import). Both describe a component's content fetching or loading new instructions at runtime — the LLM is still in the loop, executing instructions found in fetched data.

This candidate happens before any protocol handshake or LLM reasoning: it is not the LLM being tricked into following bad instructions, it is the client's own process-spawning logic trusting configuration data it should not. Confirmed as explicitly distinct from prompt injection via direct technical source review (penligent.ai MCP STDIO RCE writeup): "the attacker's goal may not be to make the model say something unsafe... [it manipulates] the boundary between configuration and process creation." Four attacker-influenceable entry points were documented: UI-driven config submission, allowlist-bypass via argument semantics, prompt-injection-driven file edits to local MCP config files (i.e. this class can be reached via prompt injection but is not itself a prompt-injection mechanism), and backend transport substitution.

Primary source

• OX Security — "The Mother of All AI Supply Chains", 2026-04. OX Security is a named trusted vendor per this repo's research-new-attack-classes skill. Documents an architectural (not coding-error) flaw baked into Anthropic's official MCP SDKs across Python, TypeScript, Java, and Rust. Scope: 150M+ combined downloads, 200,000+ potentially exposed instances, 9 of 11 tested MCP registries accepted a malicious proof-of-concept submission with no review.
• Cloud Security Alliance research notes (4 related notes, April-May 2026) corroborating the finding and its systemic scope; PoC RCE demonstrated on 6 live production platforms per the CSA summary.
• NSA/CISA CSI_MCP_SECURITY advisory (2026-06), cited via search coverage — direct fetch of the PDF returned HTTP 403, so I was not able to independently re-verify its content; flagging this so the maintainer can fetch it directly if this issue proceeds.
• Adjacent named CVE: CVE-2026-30615 (Windsurf), part of the same disclosure batch.

Proposed record skeleton

attack_class:        Supply Chain - MCP STDIO Launch Configuration Injection
severity:             CRITICAL (est.)
owasp_mcp:            [MCP05, MCP04]   (MCP05 = Command Injection and Execution, terminal effect;
                      MCP04 = Software Supply Chain Attacks, secondary — entry point is commonly a
                      poisoned registry/config)
owasp_asi:            (none proposed — TBD during implementation)
mitre_atlas:          [AML.T0104]   (Publish Poisoned AI Agent Tool — fits the registry-poisoning
                      delivery path documented in the OX report; not currently used by any existing
                      AVE record)
detection_layer:      registry_metadata   (the vulnerable data is the declared launch command/args
                      in a server's config or registry entry, auditable before the process ever
                      spawns — same layer AVE-2026-00017 server-impersonation uses)
detection_stage:      static_detection
evidence_basis_engines: [pattern, llm]   (disambiguating a malicious command/args field from a
                      legitimate STDIO launch config likely needs more than a fixed pattern)

Real-world evidence

Extensive — 10+ Critical/High CVEs from the disclosure batch, PoC RCE on 6 live production platforms, NSA/CISA advisory issued. No single canonical CVE ID covers the architectural pattern itself (it manifests per-platform); CVE-2026-30615 (Windsurf) is one instance. Pushes THM toward 1.0 in AIVSS scoring.

Indicators of compromise

• MCP client configuration entry's command or args field is sourced from user input, a database, an HTTP request, or LLM-generated content rather than a fixed, developer-authored value
• STDIO server launch accepts an arbitrary executable path/name not restricted to an allowlist of known MCP server binaries
• A registry or marketplace listing's declared launch command differs from what a prior audit recorded (dynamic/late-bound launch config)

Researcher

Bawbel Security Research Team (research-new-attack-classes skill run, 2026-07-10)

[chaksaray]

Implemented as AVE-2026-00055 (commit 13fb125 on vendor-neutral, not yet merged to main).

• Record, detection rule (rules/pattern/AVE-2026-00055.py), and positive/negative fixtures all in place
• python scripts/validate_records.py clean, pytest tests/ -x -q green (110 passed)
• detection_layer: registry_metadata, mitre_atlas: [AML.T0104] (Publish Poisoned AI Agent Tool -- confirmed not used by any other record before adding it here)

AIVSS landed at 7.7/HIGH -- notably higher than the other three records implemented so far in this batch (7.5, 6.3, 6.7), for a real reason: this class has genuinely elevated self_modification (0.7) and persistent_memory (0.5) AARF scores, since a successfully-poisoned launch config changes what tools/servers the agent loads in future sessions. AVE-2026-00052/53/54 are all single-call flaws with no persistence; this one isn't. cvss_base (9.5) is a freshly-authored vector since no single canonical CVE covers the architectural pattern itself -- CVE-2026-30615 (Windsurf) is cited as one named instance, not the anchor.

Rule passed both fixtures on the first attempt and held up against four legitimate launcher patterns I stress-tested afterward (uvx, docker, a local node script, and a URL passed as a plain non-eval argument).

Leaving open until merged to main.