Two auto-approve bypasses found in Roo-Code coding agent
Advisories published on 8 September 2026 describe parser flaws that let denied shell commands slip past Roo-Code's approval gate and run automatically.
By The Agentic Times ·
Two security advisories published on 8 September 2026 describe auto-approve bypass vulnerabilities in Roo-Code, the AI coding agent, affecting all versions through 3.54.0. Both flaws let an attacker run shell commands that the user has denied, using the agent's own auto-execute privileges on a developer's machine.
The first issue, tracked as CVE-2026-82536, sits in Roo-Code's shell command parsing logic. According to the advisory, the parser's set of operator tokens — the characters it recognises as separating one command from another — omits the bash pipe operator. An attacker can therefore build a command line that starts with an allowlisted prefix, follows it with the stderr-redirecting pipe operator, and then appends a denied command. The parser reads the whole pipeline as a single approved command and waves it through. Bash, which does understand the operator, then runs the denied component with the agent's auto-execute privileges.
The second issue, CVE-2026-82537, exploits a different disagreement between the approval gate and the shell. The advisory describes a word-boundary mismatch in how comments are handled. In bash, a hash character can begin a comment, but only in certain positions. An attacker can write an allowlisted word immediately followed by a hash character, a separator, and then a denied command. The approval gate's parser and bash interpret that string differently, so the command passes the gate and the denied part executes anyway.
Both advisories describe the same pattern. Roo-Code decides whether a command is safe by parsing it with its own logic, and that logic does not match the behaviour of the shell that will actually run the command. Where the two disagree, the attacker wins. This class of problem is common wherever a security check and an execution engine parse the same input separately.
The practical consequence is that a Roo-Code user's denylist offers weaker protection than it appears to. Auto-approve features exist so an agent can run routine commands — listing files, running tests — without stopping to ask each time. Users typically pair that with rules about which commands are never allowed. Both advisories state that the bypasses give an attacker execution with the agent's auto-execute privileges on the developer's machine, which is where source code, credentials and build tooling usually live.
Neither advisory names a fixed version, and neither lists affected packages in the published record. The advisories do not describe how an attacker would deliver a crafted command to the agent in the first place, and they do not report any exploitation in the wild.
For teams using Roo-Code, the immediate reading is that denylists based on command prefixes should not be treated as a hard boundary. An approval gate that parses shell syntax has to match the shell exactly, including operators and comment rules, and these two advisories show two places where it did not. Until a patched release is confirmed, running the agent with narrower filesystem and network access, or without auto-approve enabled, reduces what a bypass can reach.
Sources
- github.comhttps://github.com/advisories/GHSA-cvxc-67pr-wffj
- github.comhttps://github.com/advisories/GHSA-8fwh-72qq-gr52
