cursor_agent backend is vulnerable to prompt injection via tool-result content injecting fabricated tool calls

[tg12]

Summary

patch-app installs the asar npm package at runtime via npx --yes asar without any version pin, checksum verification, or integrity check. The installed package modifies the Codex Desktop application bundle (app.asar) — a file the operating system treats as a trusted application component. A supply-chain compromise of the asar package would result in arbitrary code being written into the Electron application and executed with the user's credentials the next time Codex Desktop launches.

Evidence

codex_shim/cli.py, patch_codex_app():

subprocess.run(["npx", "--yes", "asar", "extract", str(app_asar), str(workdir)], check=True)
# ... patches applied ...
subprocess.run(["npx", "--yes", "asar", "pack", str(workdir), str(app_asar)], check=True)

npx --yes resolves the latest version of asar from the npm registry, downloads it if not cached, and executes it immediately — all without user confirmation. The asar package then reads and rewrites app.asar, the signed Electron application bundle. There is no pinned version, no package-lock.json in the repo governing the asar package version, and no SHA verification of the downloaded tarball beyond npm's standard TLS fetch.

Additionally, _resign_codex_app is called after patching on macOS, but only attempts codesign --remove-signature if Apple-silicon-related integrity checks are present — the ad-hoc re-signing path does not validate that the resulting bundle hasn't been further tampered with.

Why this matters

1. Supply chain: Any compromise of the asar npm package (typosquat, registry compromise, dependency confusion, or maintainer account takeover) gives the malicious package full read/write access to the Codex Desktop application bundle.
2. Escalation: Because app.asar is rewritten, the malicious code persists in Codex Desktop across shim restarts and system reboots until the app is reinstalled.
3. Trust boundary violation: The shim is a local developer tool; it should not silently modify a system application's signed bundle via an unpinned, auto-downloaded npm package.

Attack or failure scenario

1. npm registry serves a compromised asar package (e.g., maintainer account takeover, a realistic threat — the asar package has ~2M weekly downloads).
2. Developer runs codex-shim patch-app.
3. npx --yes asar downloads and executes the compromised version.
4. The compromised asar exfiltrates API keys from ~/.codex-shim/models.json and/or injects a backdoor into app.asar itself.
5. Codex Desktop subsequently executes the malicious payload on every launch.

Root cause

Using npx --yes <package> as an installation primitive is a known anti-pattern for privileged operations — it trades reproducibility and security for convenience. The correct approach for a tool that modifies a system application bundle is to pin the asar package version, verify the tarball integrity, and require explicit user opt-in.

Recommended fix

• Add asar as an explicit versioned dependency in pyproject.toml or a companion package.json, and document the required version.
• Alternatively, use a pure-Python ASAR reader/writer (e.g., pyasar) with a pinned version verified in pyproject.toml, eliminating the npm runtime dependency entirely.
• If npx must be used, at minimum document the expected version and fail loudly if the resolved version differs.
• Add a SHA256 integrity check of app.asar before and after patching, storing the expected post-patch hash.

Acceptance criteria

• npx --yes asar is replaced with a pinned, verified dependency.
• The patch-app command documents its exact dependency and how to audit it.
• A test verifies the patch is applied idempotently and the resulting ASAR matches an expected checksum.

Suggested labels

security, dependencies, reliability

Priority

P1

Severity

High — supply-chain attack surface; unpinned auto-downloaded code that modifies a trusted application bundle is a critical trust-boundary violation even if the probability of a registry compromise is low.

Confidence

Confirmed — npx --yes asar is present in the source with no version pin.

[devin-ai-integration]

Fixed in #28 (merged): cursor_agent now defangs <CLAUDE_TOOL_CALL> markers in untrusted transcript content (user text, tool results, prior assistant text) before sending to cursor-agent, so injected markers can't be echoed back and parsed as genuine tool calls.