Which VTCode versions are affected by CVE-2026-104247?

CVE-2026-104247 affects every VTCode version below 0.171.5, and JFrog Security Research names 0.171.5 as the fixed release. The repair applies one shared validation policy at the point where commands execute, and it also stops approval families being learned for path-qualified find commands, mixed-case or quote-spliced flags, wrapper prefixes and compound commands.

How would an attacker reach the VTCode approval bypass?

JFrog states that reaching CVE-2026-104247 needs a local VTCode session where the user already approved three ordinary find commands in the same workspace subdirectory, plus a way to steer the agent, such as indirect prompt injection in a file or page it reads. Without those learned approvals, the command still raises a prompt.

Why did VTCode's blocklist miss the -exe$''c flag?

VTCode compared command tokens against its list of blocked find options exactly, so -exec matched and -exe$''c did not. The shell removes the empty ANSI-C quote before running the command, so the agent's check saw a harmless string while the operating system received -exec. JFrog describes the same gap for mixed-case spellings and wrapper prefixes.

MEDVulnerability

VTCode: a quoted flag slipped past the agent's find approval check

CVE-2026-104247 let an attacker who could steer VTCode run shell commands through an approval check that compared flags as exact tokens.

October 5, 2026 · JFrog · Research by Natan Nehorai (JFrog Security Research)

CVE-2026-104247

MEDVulnerability

VTCode, an open-source terminal coding agent, auto-approved shell commands a token check should have blocked. JFrog reports that an empty quote inside a find flag, written as -exe$''c, kept the command classified as safe. Fixed in 0.171.5.

01What happened

JFrog Security Research disclosed CVE-2026-104247 in VTCode on October 5, 2026, found by Natan Nehorai of its own team. VTCode is an open-source terminal coding agent written in Rust that asks for human approval before running shell commands. The fix shipped in version 0.171.5.

02How it works

VTCode learns a family of safe find commands once a user approves three ordinary finds under the same workspace subdirectory, and later commands in that family run with no prompt. The check that blocks destructive options such as -exec and -delete compares tokens exactly, so an empty ANSI-C quote spliced into a flag, written as -exe$''c, matches nothing on the blocked list. VTCode therefore still classifies the command as a safe find and auto-approves it, and the shell strips the empty quote and runs the real option as the user.

03Who is affected

Every VTCode version below 0.171.5 is affected. JFrog states that exploitation needs a local session in which a few ordinary find commands were already approved, plus something able to steer the agent, such as indirect prompt injection in content the agent reads.

04What to do

Upgrade VTCode to 0.171.5 or later. Until that lands, do not rely on learned find approvals, and treat any workspace where untrusted content can reach the agent as one where the agent can already run shell commands.

Questions people ask

Which VTCode versions are affected by CVE-2026-104247?: CVE-2026-104247 affects every VTCode version below 0.171.5, and JFrog Security Research names 0.171.5 as the fixed release. The repair applies one shared validation policy at the point where commands execute, and it also stops approval families being learned for path-qualified find commands, mixed-case or quote-spliced flags, wrapper prefixes and compound commands.
How would an attacker reach the VTCode approval bypass?: JFrog states that reaching CVE-2026-104247 needs a local VTCode session where the user already approved three ordinary find commands in the same workspace subdirectory, plus a way to steer the agent, such as indirect prompt injection in a file or page it reads. Without those learned approvals, the command still raises a prompt.
Why did VTCode's blocklist miss the -exe$''c flag?: VTCode compared command tokens against its list of blocked find options exactly, so -exec matched and -exe$''c did not. The shell removes the empty ANSI-C quote before running the command, so the agent's check saw a harmless string while the operating system received -exec. JFrog describes the same gap for mixed-case spellings and wrapper prefixes.

Sources 3 links, all fetched

1research.jfrog.comJFrog Advisory
2github.comFix Pull Request
3github.comVTCode Repository