An allowlist cannot out-parse the shell

A coding agent proposes a shell command. Before it runs, a small piece of code decides whether to ask the human or wave it through. In Roo Code that piece of code has just collected five CVEs in a single day, and every one of them works the same way: the gate reads the command one way, the shell reads it another, and the shell wins.

Two parsers, one string

An approval gate for shell commands is, whether its authors meant it or not, a second shell parser. It has to find every command inside a string before it can check them against a list. The real parser is bash, which has decades of grammar behind it: quoting rules, substitutions, redirections, globbing, and new syntax in every release. The gate is a handful of regular expressions.

Whenever the two disagree about where a command begins or ends, an attacker gets to choose which reading the gate sees. The weakness label on four of the five records is exactly that, an interpretation conflict. It is the most honest CWE assignment we have seen this year.

>&echo X            redirect stripped, the rest reads as echo
echo \";X;\"         an escaped quote masks the separators
echo ${ X; }         a funsub read as a parameter expansion
echo *$(X)          the substitution vanishes with the glob
$(echo X)           echo's output becomes the command

None of these needs a clever payload. Each is ordinary shell syntax that the gate simply does not model. The last one is the purest case: the gate checks the inner command, sees a harmless echo, and approves. The shell runs echo, then executes whatever echo printed.

Why the next patch would not have closed it

The code already had a dedicated check for dangerous substitutions, a hand-written list of forms to send to the human. The glob case got its own label, an incomplete list of disallowed inputs, because that is what a list of known-bad shapes always becomes. Every one of these bypasses could be patched with one more regular expression, and the patched gate would still be a partial copy of bash chasing an original that keeps moving: one of the five uses syntax that older bash releases do not even accept.

The trigger is content, not a user

The records name indirect prompt injection as the way in. Nobody types these commands. The agent reads a README, an issue or a web page carrying instructions, proposes a command shaped like the ones above, and the gate approves it because the visible prefix is on the list. Trust is the attack surface: the allowlist was trusted to describe what would run, and it only ever described what the gate managed to parse.

What to actually do

• Turn off command auto-approval in Roo Code now. No record names a fixed version, so the setting is the only control you have. Every command then goes to a human.
• Check every coding agent you run for the same design. If auto-approval works by matching prefixes of a shell string, assume the same class of bypass exists until shown otherwise. Forks of one codebase share one parser.
• If you build agents, stop handing strings to a shell. Run tools as an argument vector with no shell in between, or refuse to auto-approve any command containing shell metacharacters at all. Both are cruder than a parser and both are correct.
• Put the boundary below the agent. A container or sandbox without your credentials limits what an approved command can reach, whichever parser was fooled.