CVE: The Pre-Trust Execution Window

## Full reference: the pre-trust execution window

### 1. What the paper actually says

From VILA-Lab's Dive into Claude Code (README §Key Highlights, Safety and Permissions §Pre-trust execution window, arXiv 2604.14228):

> **4 CVEs Reveal a Pre-Trust Window** — Extensions execute *before* the trust dialog appears.

And:

> **Pre-trust execution window:** 2 patched CVEs share this root cause — hooks and MCP servers execute during initialization *before* the trust dialog appears, creating a structurally privileged attack window outside the deny-first pipeline.

The key-highlights count (4 CVEs) and the narrow safety-section excerpt (2 patched CVEs sharing this root cause) both point to the same structural shape: *the deny-first permission system guards runtime tool calls, but the code that runs during boot — parsing, initializing, spawning — is outside that pipeline.* Attackers who can get a plugin / MCP server / hook installed get code execution at load time, with the user's OS privileges, before the user has clicked OK on anything.

This is **not prompt injection.** Prompt injection is a runtime attack on model-interpreted text. This is **load-time code execution** — the attacker's code is executed as code, by the CLI's interpreter, during startup.

### 2. Why the pre-trust window exists

Modern agent harnesses load a lot of user-controllable configuration at boot:
- Plugin manifests (commands, agents, skills, hooks, MCP configs).
- MCP server registrations (often with a command to spawn a subprocess).
- Hook scripts wired to 27 lifecycle events.
- Skill manifests with 15+ YAML frontmatter fields.

For the CLI to *render* a meaningful trust dialog, it has to know what it is asking the user to trust — which means reading the manifests. The bug pattern is that 'reading the manifests' drifted into 'initializing the extensions' or 'running the probe script' over time. Each individual feature looked reasonable; the aggregate created a window where arbitrary code ran before the user was consulted.

Once an attacker lands code in the pre-trust window, they have:
- The user's full OS permissions (no sandbox has been wired yet — the sandbox is downstream of trust).
- Network access.
- Access to environment variables, including API keys and session tokens.
- Write access to `~/.claude/`, plugin directories, and hook config — they can persist.

### 3. The concrete attack shape

The path:

1. User installs a plugin, adds an MCP server, drops a skill, or wires a hook from a third-party source.
2. User runs `claude` (or equivalent).
3. The CLI's `cli.js` parses the manifest file(s) and, along the way, initializes the extension — running its init script, spawning its stdio subprocess, or evaluating a YAML frontmatter expression.
4. **The attacker's code executes.** The trust dialog has not yet rendered.
5. The trust dialog appears. The user either clicks OK (attack succeeded; trust dialog is now cover) or declines (attack already succeeded; the damage was done before the dialog).

The fix pattern, stated positively:

> Defer all extension init until after trust confirmation. Strict read-only parse of manifest fields. Manifests describe intent; they do not execute code. Signed publisher provenance required to enter the pre-trust parse path.

### 4. Mitigation checklist

This is a release gate. Work through every item. FAIL means file a ticket and block release.

#### 4.1 Boot order invariant

- [ ] The cli.js main function has an explicit phase list: `bootstrap → config-load → trust-dialog-render → user-confirm → extension-load`. The order is enforced by the call graph, not by comment.
- [ ] A lint or test asserts the order: grep for `spawn()`, `exec()`, `require()`, `eval()`, `import()` in the config-load phase; all matches are in an allow-list of vetted parsers.
- [ ] The trust dialog's render call happens before any `initializeExtension` / `startMcpServer` / `runHook` call in the call graph.
- [ ] A boot-order test fires a fake malicious plugin and asserts no side effect (no file write, no network, no subprocess) happens before the trust dialog's `onUserConfirm` fires.

#### 4.2 Manifest parse is strictly read-only

- [ ] Plugin / MCP / skill manifests are parsed by a strict JSON parser or a YAML parser with `FAILSAFE_SCHEMA` (no `!!js`, no function tags, no anchor-based code resolution).
- [ ] Manifest fields are validated against a schema (Zod / JSONSchema / similar). Unknown fields are rejected, not silently ignored.
- [ ] Template strings / string-interpolation fields in manifests are treated as literal strings at parse time. Substitution, if needed, happens at extension-load time, after trust.
- [ ] No field in any manifest triggers a `fs.readFile` that follows symlinks outside the plugin directory, reads environment variables, or resolves `~`. Plugin dirs are jailed.
- [ ] SKILL.md YAML frontmatter fields are enumerated; any field with executable potential (pre-load hooks, 'on-parse' triggers) is removed from the pre-trust parse path and moved to post-trust.

#### 4.3 Subprocess deferral

- [ ] MCP stdio transports register the spawn command at parse time but do not `spawn()` until `onUserConfirm`.
- [ ] MCP SSE / HTTP transports do not initiate the connection until `onUserConfirm`.
- [ ] Hook scripts are validated (path exists, executable bit, owner is current user) at parse time but are not executed.
- [ ] Plugin init scripts are identified at parse time but not executed; 'install probes' are static, not dynamic.

#### 4.4 Environment-variable and flag bypass

- [ ] There is no env var or flag that skips the trust dialog for normal user sessions.
- [ ] If CI images need to skip the dialog, there is a compile-time allow-list of CI user agents or sentinel files. Runtime-only env var checks are rejected.
- [ ] The trust dialog's confirm state is bound to the concrete extension set parsed this session. A user who trusts {A, B, C} cannot have D silently added — a new extension triggers a new dialog.
- [ ] No 'remember my choice forever' checkbox skips the dialog on future sessions with different extension sets. Append-only trust log, not global kill switch.

#### 4.5 Signed publisher provenance

- [ ] Every third-party extension has a signature over its manifest + content hash by a publisher key.
- [ ] The CLI's pinned keyring is shipped in the binary, not loaded from the user's disk (so an attacker on the same disk cannot inject a trusted key).
- [ ] Unsigned extensions load only after trust, and only into a restricted context (no hooks, no MCP spawn, read-only skill).
- [ ] Signature verification happens BEFORE manifest parse. A manifest whose signature does not verify is never parsed.
- [ ] Keyring updates are versioned; CLI refuses to run if the shipped keyring is older than a pinned minimum version (prevents rollback attacks).

#### 4.6 Observability

- [ ] Every extension load is logged with (timestamp, publisher, content hash, signature status, phase).
- [ ] Alerts fire on (a) an extension loaded in the pre-trust phase, (b) an unsigned extension loading, (c) a signature that failed verification.
- [ ] Logs are tamper-evident (append-only or signed). This is the same append-only commitment the rest of Claude Code's session persistence makes; extend it to boot.
- [ ] Post-incident: logs can reconstruct the exact boot sequence and extension set.

### 5. Failure mode deep dives

**Plugin init runs arbitrary code at parse time.** This is the core of the 4 CVEs. A plugin's `plugin.json` references an `init.js` and cli.js runs it during enumeration to 'discover commands'. Fix: enumerate commands by static manifest fields only. If you need dynamic commands, the plugin declares a 'post-trust-init' field and the CLI runs that after trust.

**MCP stdio transport spawns subprocess before trust prompt.** An MCP server declares itself via stdio and a `command` + `args`. cli.js calls `spawn()` to start the server, handshake, and discover its tools — all before trust. The subprocess has already run for seconds by the time the user sees the dialog. Fix: register the command but defer spawn; show the user the `command + args` in the dialog; spawn only on confirm.

**Hooks fire on installation-probe runs.** The CLI has an 'install probe' that validates a hook points at a real executable; the probe invokes the hook with a sentinel payload. Attacker authors a hook that does damage on any invocation. Fix: probes are strict metadata checks (file exists, is executable, is not a symlink out of jail); they never invoke the target.

**SKILL.md YAML frontmatter contains executable expressions.** YAML can be powerful (custom tags, anchors, !!js on node-yaml), and a skill's frontmatter has 15+ fields. A field like `preload: !!js "require(...)"` runs at parse time. Fix: `FAILSAFE_SCHEMA`, schema-validated allow-list of fields, reject unknown keys.

**Trust dialog bypassed via environment-variable injection.** Attacker sets `CLAUDE_SKIP_TRUST=1` in the user's shell rc; cli.js honors it and skips the dialog for attacker's extensions. Fix: no runtime env var bypasses trust for normal sessions. CI paths use compile-time allow-lists.

### 6. Cadence

- **Per-PR**: lint + test for the boot-order invariant. A PR that calls `spawn` / `require` / `eval` / `initializeExtension` inside the config-load phase fails CI.
- **Per-release**: run the full checklist; staff-engineer sign-off.
- **Quarterly**: reverse-engineer the boot order from the built binary to confirm nothing drifted in compile-time code.
- **Post-incident**: if any CVE is filed against the pre-trust window, every item becomes a release-blocking test until verified.

### 7. Relation to other packs

- `injection-surface-audit` — runtime content-injection audit. Pair with this pack. That pack handles attacks through fetched URLs, tool outputs, and user content; this pack handles attacks through extension load.
- `seven-safety-layers` — runtime deny-first pipeline. This pack closes the window *outside* that pipeline.

### 8. Proof of work

A PR comment or dated markdown under `docs/security/` lists every item with PASS / FAIL / WAIVED, a link to the code or ticket, and the staff engineer who signed. If evidence is missing, the item is FAIL, not PASS.

Sourced from VILA-Lab/Dive-into-Claude-Code (CC-BY-NC-SA-4.0, arXiv 2604.14228). The pre-trust execution window framing and the tying of patched CVEs to a single root cause are paraphrased with citation from README §Key Highlights and the Safety and Permissions §Pre-trust execution window excerpt.