TL;DR

VTCode, an open-source Rust coding agent, learns to auto-approve commands: after a user approves three ordinary find commands in the same workspace subdirectory, it treats later find commands in that family as safe. Its guard against destructive flags (-exec, -delete) compares exact tokens, so splicing an empty ANSI-C quote into a flag — -exe$''c — slips a destructive command past the check and runs it without a prompt. With indirect prompt injection steering the agent, that is an unapproved destructive command on the user's machine. JFrog disclosed it as CVE-2026-104247, CVSS 6.3, fixed in 0.171.5 (2026-10-05).

What happened

JFrog's Natan Nehorai found that VTCode's shell-approval logic has two reinforcing weaknesses: a family-learning rule that auto-approves find commands after three manual approvals under the same subdirectory, and a denylist for destructive find flags that matches exact tokens and so misses -exec/-delete written with an empty ANSI-C quote spliced in. Combined, a find command carrying a destructive predicate is classified as safe and executed without approval. Exploitation needs a local session with those prior approvals plus a way to steer the agent, such as indirect prompt injection in the content it reads. An earlier change (0.141.12) blocked the bypass only for bare find; the fix in 0.171.5 (PR #778) also stops family-learning for path-qualified find, quote-spliced and mixed-case flags, wrapper/environment prefixes and compound commands. JFrog rates it CVSS 6.3 (medium), advisory JFSA-2026-001694179 / GHSA-r249-hpfx-x2w7. The crates.io release line is at 0.174.0.

This is the same approval-bypass class as the Mistral Vibe, Cursor and Claude Code find/allowlist bypasses: a coding agent's auto-approve heuristic is a parser, and the shell parses more than the heuristic does. VTCode is niche, but the pattern is the point.

Am I affected?

cargo install --list 2>/dev/null | grep -i vtcode     # < 0.171.5 is affected
vtcode --version 2>/dev/null

You are exposed if you ran VTCode below 0.171.5 and relied on learned find approvals in a workspace where untrusted input can steer the agent.

If you are affected

Upgrade to 0.171.5 or later. Until then do not rely on learned find approvals, and treat any workspace where untrusted content drives the agent as able to run shell commands after a few approved finds. See if-your-local-ai-agent-was-exploited.md and agent-sandboxing.md.

Prevention

Prefer agents that sandbox rather than learn-to-approve, and never let an auto-approve heuristic stand in for an OS sandbox (agent-sandboxing.md); keep untrusted repos and content from steering an agent with command approvals banked (mcp-hygiene.md).

Sources