Roo Code auto-approve bypass: the ${ command; } form lets denied shell commands slip past the check

Who is affected

“The researcher’s write-up” on this page is the vulnerability write-up the finders, Minqiang Gui and Siyu Lou, published on GitHub (listed as the Researcher Disclosure in the CVE record); that page contains exploit code, so we don’t link to it. The researcher tested main-branch commit b867ec9 and labels it v3.53.0; however, per the repository history, b867ec9 is not the v3.53.0 release commit but a May 15, 2026 commit that comes two commits after the v3.54.0 release commit (f49f0ce). VulnCheck, which assigned the CVE, tagged it unsupported-when-assigned, meaning the product was no longer supported when the CVE ID was assigned. The vendor’s GitHub repository is archived (read-only), and sources disagree on the date: the repository banner says May 15, 2026, while the researcher’s write-up quotes May 16. A third-party news tracker also reports that the whole Roo Code suite (Extension, Cloud and Router) shut down on May 15, 2026.

How it works

Roo Code is an AI coding assistant (an “agent”) that can run shell commands in your terminal. With auto-approve on (the researcher’s write-up calls the setting “always approve execute”, and this page uses that name; the CVE record only says auto-approve), it stops asking you and instead checks each command against an allowlist and a denylist to decide on its own.

To do that check, it first has to split the command line apart and find every command that will actually run. That’s the job of parseCommandLine(). The problem is how it handles ${...}:

• In older shells, forms like ${NAME} are “parameter expansions”: they just read a variable’s value and run nothing.
• bash 5.3 (2025) added a ${ command; } form (called funsub command substitution), which does run the command inside.

Roo Code’s parser uses one regular expression to treat every ${...} as a parameter expansion and hide it behind a placeholder, so the command inside is never compared to the lists. All that’s left is an outer command on the allowlist, such as echo, which gets auto-approved. The parser and the shell read the same text differently, which is what CWE-436 (Interpretation Conflict) describes.

The realistic trigger usually isn’t the user but indirect prompt injection: a file, web page, repository or MCP result the agent reads contains instructions that steer it into proposing such a command. The command runs with the agent’s auto-execute privileges.

The flawed approach (conceptual illustration, not the original source code):

// Treat every ${...} as "just a variable" and hide it behind a placeholder
cmd = cmd.replace(/\$\{[^}]+\}/g, () => PLACEHOLDER)
// Then only the outer command is checked → it's on the allowlist → auto-approved

The approach the researcher recommends (per the researcher’s write-up, which contains exploit code, so we don’t link to it; conceptual illustration, not a vendor fix):

// The ${ ...; } funsub form is not a parameter expansion:
// pull out the inner command and check it against the lists like any other substitution
if (isFunsub(segment)) {
  checkAgainstLists(innerCommand(segment))
}

Timeline

Further reading

• Scoring: NVD finished its analysis on 2026-10-15 but gave no score of its own; it only lists the scores from VulnCheck, the assigner (CVSS 4.0 7.7, CVSS 3.1 8.8). The CVE record lists CVSS 3.1 8.8 (supplied by VulnCheck, the assigner) and CVSS 4.0 7.7; this page uses the 4.0 score. Both say the attacker needs no privileges; 3.1 says user interaction is required, while 4.0 rates it as passive.
• Exploitation: CISA’s SSVC rating marks it poc, meaning a public proof of concept exists. That does not mean it has been exploited in the wild. No source reports in-the-wild or zero-day exploitation.
• Credited to Minqiang Gui and Siyu Lou. Their write-up contains exploit code, so we don’t link to it; see the CVE record, NVD and the VulnCheck advisory for the vulnerability details.
• Related: CVE-2026-63108 is a separate Roo Code (≤3.54.0) auto-approve bypass that also involves how the parser handles parameter expansions, but it is a different CVE.
• Related weakness type: CWE-436.