ForgeCode Untrusted .mcp.json Auto-Execution Leading to Arbitrary Code Execution

Technical Analysis

The entry point is the .mcp.json configuration file, which ForgeCode trusts implicitly as project-level MCP server definitions rather than treating as untrusted, attacker-controllable input from a cloned repository. The mcpServers block allows specification of arbitrary command and args fields (e.g., bash -c '<payload>'), and ForgeCode spawns these as child processes on startup with no sandboxing, allow-listing, or confirmation prompt. This crosses the trust boundary between 'repository content' and 'local execution environment,' converting a passive code-review action into an active RCE primitive. The attacker gains code execution under the invoking user's OS privileges, enabling persistence, credential theft, lateral movement, or further supply-chain poisoning (e.g., modifying other MCP configs or exfiltrating secrets accessible to the developer's shell). Because MCP server definitions are often treated as benign configuration rather than executable content, this bypasses typical code-review scrutiny that source files receive.

Affected Systems

ForgeCode (tailcallhq/forgecode); protocols: MCP

Detection Signatures

• Presence of .mcp.json in repository root or subdirectories with mcpServers entries specifying shell interpreters (bash, sh, cmd, powershell) as the command field.
• mcpServers args containing shell metacharacters, '-c' flags, curl/wget download-and-execute chains, or reverse-shell patterns.
• Unexpected child processes spawned by the forge CLI binary immediately after startup in a freshly cloned repository directory.
• File writes, network connections, or credential file access originating from a forge process shortly after launch with no corresponding user-initiated MCP tool call.
• CLI startup logs showing MCP server registration without any user prompt or confirmation step.

Remediation Steps

1. 1

   Require explicit user confirmation for repo-defined MCP servers

   Modify ForgeCode to prompt the user with the full command/args before executing any MCP server defined in a repository-local .mcp.json, defaulting to deny.

2. 2

   Sandbox or allow-list MCP server execution

   Execute repository-supplied MCP server commands in a restricted sandbox (container, seccomp profile, or restricted user) and only allow-list known-safe binaries rather than arbitrary commands.

3. 3

   Separate trusted vs untrusted config scopes

   Distinguish between user-level/global MCP configs (trusted) and repository-level configs (untrusted), applying stricter execution policies to the latter.

4. 4

   Upgrade ForgeCode

   Apply the vendor patch for CVE-2026-57860 once available and verify that auto-execution of repo-local MCP servers is disabled by default.

5. 5

   Developer hygiene for untrusted repos

   Advise developers to review .mcp.json contents before running forge in any newly cloned or untrusted repository, and to run such evaluations in an isolated VM or container.