Secure Autonomous
FeedbackGet alertsCheck a deployment
Cases / REG-0029

Roo Code: crafted shell commands pass the coding agent's command allowlist and run without user approval; five CVEs published 13 October 2026, project archived with no fix

PendingSoftware agents · Enterprise work agentsMachine acts aloneDemonstration
REG-0029Updated 2026-10-2310 sources, 10 linkedDisclosure corroborated

What happened

A developer running Roo Code with auto-approval of allowlisted shell commands enabled. Roo Code through 3.54.0, which runs shell commands on the developer machine and decides through getCommandDecision() and parseCommandLine() whether a command is auto-approved. Described, not demonstrated: the records say attackers using indirect prompt injection can lead the agent to propose a crafted shell command; the reporters' write-ups call this 'the realistic trigger', and their proofs of concept call the approval code directly rather than going through the agent. The approval check matched the crafted command to an allowlisted prefix such as echo and auto-approved it, while the shell would run a denied command: a bare >& redirect prefix (110202); escaped or single-quoted double quotes defeating the quote-masking regex (110203); ${ command; } substitutions treated as parameter expansions on bash 5.3+ or ksh93 (110204); command substitutions next to * or ? discarded (110205); a command substitution in command position (110206). A command allowlist and denylist enforced by the agent's own parser, which interprets command lines differently from the shell that runs them. The shell runs the denied command on the developer machine without user approval. Outcome: pending; none reported (each record carries VulnCheck's CVSS, Common Vulnerability Scoring System, severity scores: 7.7 High under version 4.0 and 8.8 High under version 3.1); as of 21 Oct 2026. No vendor statement about these five records was found. In August 2026, answering other Roo Code vulnerability reports filed through VulDB, the vendor said they 'all apply to Roo Code, a project we no longer support - the repository was archived a while ago, and we don't encourage anyone to use it' (as quoted by VulDB in CVE-2026-81834).

Verification: 5 of 6 checks complete
✓ Structured and checkedevery claim typed and sourced, then checked by the Register's automated checker for missing sources and mistyped claims
✓ Sources linked10 of 10 sources link to the record (8 to a primary record)
✓ Sources checked claim by claimevery claim checked against its source on 2026-10-22
✓ Interpretation checked statement by statementeach statement of the Register's interpretation checked against a source on 2026-10-21
○ Reviewed by the editornot yet reviewed by a person
✓ Reply offeredRoo Code: offered
Corrections · 24, latest 2026-10-22

Changes to what this case says, with the reason. Every earlier version is kept.

  • 2026-10-22: Outcome: regime consequence. Rule 13 (new cases): the consequence line records only actions by a regulator, court, legislature or other government body; a cve, an advisory, a score or a fix is not one. the cve and fix details are already in the evidence and recovery fields, so nothing is lost. found while drafting this case's letters, 22 october 2026.
    Show the change
    Before: CVE-2026-110202, CVE-2026-110203, CVE-2026-110204, CVE-2026-110205, CVE-2026-110206; no fixed version
    After: none
  • 2026-10-22: Fields: outcome. Follows the editor's call h1 of 21 october 2026 (outcome 'pending' where no fix has shipped): the field's state label had not been updated with the outcome; the rest of the field is unchanged.
    Show the change
    Before: State: averted by disclosure. No exploitation reported in the sources. The records carry a coordinator assessment by CISA (the US Cybersecurity and Infrastructure Security Agency) rating exploitation 'poc' (proof of concept public) for CVE-2026-110202 and CVE-2026-110204 and 'none' for CVE-2026-110203 and CVE-2026-110206; CVE-2026-110205 has no such assessment. As of 21 Oct 2026
    After: State: pending (no fix has shipped). No exploitation reported in the sources. The records carry a coordinator assessment by CISA (the US Cybersecurity and Infrastructure Security Agency) rating exploitation 'poc' (proof of concept public) for CVE-2026-110202 and CVE-2026-110204 and 'none' for CVE-2026-110203 and CVE-2026-110206; CVE-2026-110205 has no such assessment. As of 21 Oct 2026
  • 2026-10-21: Outcome: state. Editor's call h1 of 21 october 2026 (accepted as amended, pull request #79): no fix has shipped in a published release, so the outcome is not yet known; 'averted by disclosure' claimed an outcome that has not happened.
    Show the change
    Before: averted_by_disclosure
    After: pending
  • 2026-10-21: Controls: c-i1. Found in the editor's source check of 21 october 2026: the researcher write-ups (researcher) call indirect prompt injection 'the realistic trigger' but their proofs of concept run the approval function directly, so the failure of this control is described, not demonstrated; confidence lowered to low.
    Show the change
    Before: {"id": "C-I1", "note": "Mechanism: the records name indirect prompt injection as the route by which attacker content becomes the command the agent proposes. Why it interrupts: if retrieved content were never treated as instruction, the attacker could not choose the command. Source shows it failed only by naming the route; the counterfactual is not shown.", "confidence": "medium", "basis": "agent"}
    After: {"id": "C-I1", "note": "Mechanism: the records name indirect prompt injection as the route by which attacker content becomes the command the agent proposes. Why it interrupts: if retrieved content were never treated as instruction, the attacker could not choose the command. Source shows it failed only by naming the route: the reporters' proofs of concept call the approval code directly and do not exercise this route; the counterfactual is not shown.", "confidence": "low", "basis": "agent"}
  • 2026-10-21: Inference: source ids. Found in the editor's source check of 21 october 2026: the reworded interpretation rests on the researcher write-ups and the marketplace shutdown notice as well as the records.
    Show the change
    Before: ["NVD-110202", "NVD-110203", "NVD-110204", "NVD-110205", "NVD-110206"]
    After: ["NVD-110202", "NVD-110203", "NVD-110204", "NVD-110205", "NVD-110206", "RESEARCHER", "MARKETPLACE"]
  • 2026-10-21: Inference: value. Found in the editor's source check of 21 october 2026: 'five separate mismatches in one parser' overstated the records: cve-2026-110202 is in getcommanddecision()'s redirect stripping, which the write-up calls 'decision-side, independent of the tokenizer'; the interpretation now also says what the records do not show (the write-ups' proofs of concept bypass the agent; no record reports exploitation, a fix or vendor notice). the interpretation was not signed.
    Show the change
    Before: An allowlist is only as strong as the agreement between the parser that checks a command and the shell that runs it; five separate mismatches in one parser show the check was guarding a different command from the one executed
    After: The five records describe one approval check, in getCommandDecision() and parseCommandLine(), that reads a command line differently from the shell that runs it, so a command the check takes for an allowlisted one such as echo is auto-approved while the shell runs a different command. The reporters showed this by running the approval code and bash directly, not through the agent. The records do not show an attack through the running agent, any exploitation, whether the vendor was told before publication, or a fix; the product had been shut down and was unsupported when the identifiers were assigned
  • 2026-10-21: Fields: recovery accountability: source ids. Found in the editor's source check of 21 october 2026: the statement is in the cve-2026-81834 record, not the five records.
    Show the change
    Before: ["NVD-110202", "NVD-110203", "NVD-110204", "NVD-110205", "NVD-110206"]
    After: ["NVD-81834"]
  • 2026-10-21: Fields: recovery accountability: confidence. Found in the editor's source check of 21 october 2026: the vendor's words are quoted by vuldb, a numbering authority, in a public record.
    Show the change
    Before: low
    After: medium
  • 2026-10-21: Fields: recovery accountability. Found in the editor's source check of 21 october 2026: the vuldb record cve-2026-81834 (27 august 2026) quotes the vendor's statement that roo code is a project it no longer supports; no statement about the five october records was found.
    Show the change
    Before: not evidenced in source
    After: No vendor statement about these five records was found. In August 2026, answering other Roo Code vulnerability reports filed through VulDB, the vendor said they 'all apply to Roo Code, a project we no longer support - the repository was archived a while ago, and we don't encourage anyone to use it' (as quoted by VulDB in CVE-2026-81834)
  • 2026-10-21: Fields: recovery technical: source ids. Found in the editor's source check of 21 october 2026: the shutdown notice comes from the marketplace listing.
    Show the change
    Before: ["NVD-110202", "NVD-110203", "NVD-110204", "NVD-110205", "NVD-110206", "REPO"]
    After: ["NVD-110202", "NVD-110203", "NVD-110204", "NVD-110205", "NVD-110206", "REPO", "MARKETPLACE"]
  • 2026-10-21: Fields: recovery technical. Found in the editor's source check of 21 october 2026: each of the five nvd records carries vulncheck's 'unsupported-when-assigned' tag, and the vendor's marketplace listing (marketplace) says the extension was shut down on may 15th.
    Show the change
    Before: No fixed version is named in the records. The vendor's repository was archived by its owner on 15 May 2026 and is read-only; v3.54.0, released 15 May, is its latest release
    After: No fixed version is named in the records, and each record carries the tag 'unsupported-when-assigned' (the product was no longer supported by its maintainer when the identifier was assigned). The vendor's repository was archived by its owner on 15 May 2026 and is read-only; v3.54.0, released 15 May, is its latest release. The extension's Visual Studio Code Marketplace listing, still at version 3.54.0, says 'The Roo Code Extension was shut down on May 15th'
  • 2026-10-21: Fields: evidence event: source ids. Found in the editor's source check of 21 october 2026: the proof-of-concept statement rests on the researcher write-ups.
    Show the change
    Before: ["NVD-110202", "NVD-110203", "NVD-110204", "NVD-110205", "NVD-110206", "VC-82536"]
    After: ["NVD-110202", "NVD-110203", "NVD-110204", "NVD-110205", "NVD-110206", "VC-82536", "RESEARCHER"]
  • 2026-10-21: Fields: evidence event. Found in the editor's source check of 21 october 2026: the nvd records show the 7.7 is a vulncheck cvss version 4.0 score with a cvss version 3.1 score of 8.8 alongside; the cited write-ups (researcher) show proofs of concept run against the source files and bash; the vulncheck advisory vc-82536 describes the 'stderr-redirecting pipe operator' (|&), and the write-up notes the ordinary pipe is split correctly.
    Show the change
    Before: Five NVD records published 13 October 2026, each scored CVSS 7.7, affected versions through 3.54.0; an earlier advisory, CVE-2026-82536 (8 September 2026), describes the same kind of bypass through the pipe operator in the same versions
    After: Five CVE (Common Vulnerabilities and Exposures) records published on 13 October 2026 by VulnCheck, the numbering authority, and shown in the National Vulnerability Database (NVD), affected versions through 3.54.0; VulnCheck scored each 7.7 under CVSS (Common Vulnerability Scoring System) version 4.0 and 8.8 under CVSS version 3.1. The write-ups each record cites contain proof-of-concept runs of the two unmodified approval source files and of bash, not of the running agent. An earlier record, CVE-2026-82536 (8 September 2026), describes the same kind of bypass through the |& operator (a pipe carrying both standard output and standard error) in the same versions
  • 2026-10-21: Fields: outcome. Found in the editor's source check of 21 october 2026: the nvd records carry cisa's stakeholder-specific vulnerability categorization entries added 13-16 october 2026: exploitation 'poc' for 110202 and 110204, 'none' for 110203 and 110206, none recorded for 110205.
    Show the change
    Before: State: averted by disclosure. No exploitation reported in the sources. As of Oct 2026
    After: State: averted by disclosure. No exploitation reported in the sources. The records carry a coordinator assessment by CISA (the US Cybersecurity and Infrastructure Security Agency) rating exploitation 'poc' (proof of concept public) for CVE-2026-110202 and CVE-2026-110204 and 'none' for CVE-2026-110203 and CVE-2026-110206; CVE-2026-110205 has no such assessment. As of 21 Oct 2026
  • 2026-10-21: Fields: inputs: source ids. Found in the editor's source check of 21 october 2026: the reworded value rests on the researcher write-ups as well as the records.
    Show the change
    Before: ["NVD-110202", "NVD-110203", "NVD-110204", "NVD-110205", "NVD-110206"]
    After: ["NVD-110202", "NVD-110203", "NVD-110204", "NVD-110205", "NVD-110206", "RESEARCHER"]
  • 2026-10-21: Fields: inputs. Found in the editor's source check of 21 october 2026: the five nvd records say attackers 'using indirect prompt injection can' do this; the cited write-ups (researcher) call it 'the realistic trigger' and their proofs of concept run getcommanddecision() on two unmodified source files, so the route is described, not demonstrated.
    Show the change
    Before: Attacker-controlled content that reaches the agent through indirect prompt injection and leads it to propose a crafted shell command
    After: Described, not demonstrated: the records say attackers using indirect prompt injection can lead the agent to propose a crafted shell command; the reporters' write-ups call this 'the realistic trigger', and their proofs of concept call the approval code directly rather than going through the agent
  • 2026-10-21: Outcome: as of. Found in the editor's source check of 21 october 2026: the records were updated after drafting (cisa coordinator assessments 13-16 october, nvd analysis 15-16 october); no fix, new record or exploitation report found up to 21 october 2026.
    Show the change
    Before: Oct 2026
    After: 21 Oct 2026
  • 2026-10-21: Outcome: severity. Found in the editor's source check of 21 october 2026: the five nvd records show the 7.7 is vulncheck's cvss version 4.0 base score and that vulncheck also gives a cvss version 3.1 base score of 8.8 on each; nvd added no score of its own.
    Show the change
    Before: none reported (CVSS 7.7 on each record)
    After: none reported (each record carries VulnCheck's CVSS, Common Vulnerability Scoring System, severity scores: 7.7 High under version 4.0 and 8.8 High under version 3.1)
  • 2026-10-21: Sources: vc-82536: title. Found in the editor's source check of 21 october 2026: the vulncheck advisory's exact headline is 'roo-code 3.54.0 auto-approve bypass via shell command pipe operator'.
    Show the change
    Before: VulnCheck advisory CVE-2026-82536: Roo-Code auto-approve bypass via shell command pipe operator, through 3.54.0
    After: VulnCheck advisory CVE-2026-82536: Roo-Code 3.54.0 Auto-Approve Bypass via Shell Command Pipe Operator
  • 2026-10-21: Sources: nvd-110206: title. Found in the editor's source check of 21 october 2026: the 110206 record (nvd application programming interface copy) carries two vulncheck scores, cvss version 4.0 base score 7.7 and cvss version 3.1 base score 8.8; the title gave only 7.7 with no version.
    Show the change
    Before: NVD record CVE-2026-110206: Roo Code through 3.54.0 command approval bypass (command substitution in command position), CVSS 7.7
    After: NVD record CVE-2026-110206: Roo Code through 3.54.0 command approval bypass (command substitution in command position), CVSS 4.0 score 7.7 and CVSS 3.1 score 8.8, both from VulnCheck
  • 2026-10-21: Sources: nvd-110205: title. Found in the editor's source check of 21 october 2026: the 110205 record (nvd application programming interface copy) carries two vulncheck scores, cvss version 4.0 base score 7.7 and cvss version 3.1 base score 8.8; the title gave only 7.7 with no version.
    Show the change
    Before: NVD record CVE-2026-110205: Roo Code through 3.54.0 command approval bypass (command substitution next to a glob character discarded), CVSS 7.7
    After: NVD record CVE-2026-110205: Roo Code through 3.54.0 command approval bypass (command substitution next to a glob character discarded), CVSS 4.0 score 7.7 and CVSS 3.1 score 8.8, both from VulnCheck
  • 2026-10-21: Sources: nvd-110204: title. Found in the editor's source check of 21 october 2026: the 110204 record (nvd application programming interface copy) carries two vulncheck scores, cvss version 4.0 base score 7.7 and cvss version 3.1 base score 8.8; the title gave only 7.7 with no version.
    Show the change
    Before: NVD record CVE-2026-110204: Roo Code through 3.54.0 command approval bypass (${ command; } substitution treated as parameter expansion), CVSS 7.7
    After: NVD record CVE-2026-110204: Roo Code through 3.54.0 command approval bypass (${ command; } substitution treated as parameter expansion), CVSS 4.0 score 7.7 and CVSS 3.1 score 8.8, both from VulnCheck
  • 2026-10-21: Sources: nvd-110203: title. Found in the editor's source check of 21 october 2026: the 110203 record (nvd application programming interface copy) carries two vulncheck scores, cvss version 4.0 base score 7.7 and cvss version 3.1 base score 8.8; the title gave only 7.7 with no version.
    Show the change
    Before: NVD record CVE-2026-110203: Roo Code through 3.54.0 command approval bypass (quote-masking regex in parseCommandLine()), CVSS 7.7
    After: NVD record CVE-2026-110203: Roo Code through 3.54.0 command approval bypass (quote-masking regex in parseCommandLine()), CVSS 4.0 score 7.7 and CVSS 3.1 score 8.8, both from VulnCheck
  • 2026-10-21: Sources: nvd-110202: title. Found in the editor's source check of 21 october 2026: the 110202 record (nvd application programming interface copy) carries two vulncheck scores, cvss version 4.0 base score 7.7 and cvss version 3.1 base score 8.8; the title gave only 7.7 with no version.
    Show the change
    Before: NVD record CVE-2026-110202: Roo Code through 3.54.0 command approval bypass (bare >& redirect prefix), CVSS 7.7
    After: NVD record CVE-2026-110202: Roo Code through 3.54.0 command approval bypass (bare >& redirect prefix), CVSS 4.0 score 7.7 and CVSS 3.1 score 8.8, both from VulnCheck
Record history · 5 entries
  • 2026-10-23: Roo Code acknowledged receipt.
  • 2026-10-22: Right of reply offered to Roo Code.
  • 2026-10-21: Source added: NVD record CVE-2026-81834: RooCodeInc Roo-Code up to 3.51.1 code injection (VulDB record quoting the vendor that Roo Code is a project it no longer supports).
  • 2026-10-21: Source added: Roo Code - Visual Studio Marketplace.
  • 2026-10-21: Source added: 7rah/oss-cve on GitHub, commit 6adb836: "add 5 Roo-Code auto-approve bypass advisories" (the researcher disclosure write-ups, with proofs of concept, cited by each of the five records).

Controls that address what went wrong

2 controls missing or failed. The line under each is the concrete form it would have taken in this case.

Retrieved content as data
Failed: Mechanism: the records name indirect prompt injection as the route by which attacker content becomes the command the agent proposes. Why it interrupts: if retrieved content were never treated as instruction, the attacker could not choose the command. Source shows it failed only by naming the route: the reporters' proofs of concept call the approval code directly and do not exercise this route. the counterfactual is not shown.
Failed · Inputs layer
Pre-execution validation
Mechanism: the pre-execution approval check parsed each crafted command as an allowlisted one (for example echo) while the shell executed a denied command. Why it interrupts: a check that resolves the command the way the shell will (or refuses what it cannot parse) would have sent these commands to the user instead of auto-approving them. Source shows it failed: all five records describe the check approving the command.
Failed · Decision layer

New cases like this, once a week. A short email when a case, signal or rule touches software agents. Free; unsubscribe in one click.

Get the weekly email

How it unfolded, layer by layer

MandateWhat it was told to do
Who deployed it: A developer running Roo Code with auto-approval of allowlisted shell commands enabled. The task: not evidenced in source.
ActorWhat acted
Roo Code through 3.54.0, which runs shell commands on the developer machine and decides through getCommandDecision() and parseCommandLine() whether a command is auto-approved
InputsWhat it could see
Described, not demonstrated: the records say attackers using indirect prompt injection can lead the agent to propose a crafted shell command; the reporters' write-ups call this 'the realistic trigger', and their proofs of concept call the approval code directly rather than going through the agent
DecisionHow it chose
The approval check matched the crafted command to an allowlisted prefix such as echo and auto-approved it, while the shell would run a denied command: a bare >& redirect prefix (110202); escaped or single-quoted double quotes defeating the quote-masking regex (110203); ${ command; } substitutions treated as parameter expansions on bash 5.3+ or ksh93 (110204); command substitutions next to * or ? discarded (110205); a command substitution in command position (110206)
EnvelopeWhat it was allowed to do
Limits in place: A command allowlist and denylist enforced by the agent's own parser, which interprets command lines differently from the shell that runs them.
ActionWhat it did
The shell runs the denied command on the developer machine without user approval
OutcomeWhat happened
Pending. Severity: none reported (each record carries VulnCheck's CVSS, Common Vulnerability Scoring System, severity scores: 7.7 High under version 4.0 and 8.8 High under version 3.1).
EvidenceWhat can be proven
Record of the event: Five CVE (Common Vulnerabilities and Exposures) records published on 13 October 2026 by VulnCheck, the numbering authority, and shown in the National Vulnerability Database (NVD), affected versions through 3.54.0; VulnCheck scored each 7.7 under CVSS (Common Vulnerability Scoring System) version 4.0 and 8.8 under CVSS version 3.1. The write-ups each record cites contain proof-of-concept runs of the two unmodified approval source files and of bash, not of the running agent. An earlier record, CVE-2026-82536 (8 September 2026), describes the same kind of bypass through the |& operator (a pipe carrying both standard output and standard error) in the same versions.
RecoveryWhat could be stopped, undone, answered for
Technical recovery: No fixed version is named in the records, and each record carries the tag 'unsupported-when-assigned' (the product was no longer supported by its maintainer when the identifier was assigned). The vendor's repository was archived by its owner on 15 May 2026 and is read-only; v3.54.0, released 15 May, is its latest release. The extension's Visual Studio Code Marketplace listing, still at version 3.54.0, says 'The Roo Code Extension was shut down on May 15th'. Accountability: No vendor statement about these five records was found. In August 2026, answering other Roo Code vulnerability reports filed through VulDB, the vendor said they 'all apply to Roo Code, a project we no longer support - the repository was archived a while ago, and we don't encourage anyone to use it' (as quoted by VulDB in CVE-2026-81834).

The same gap in other cases

Cases where the same control was missing or failed. Those in another world are the cross-domain comparisons the Register exists to make.

ControlSame worldOther worlds
Retrieved content as dataGitHub MCP leak 2025, EchoLeak 2025, Claude Code [bot] trust 2026, Perplexity Comet 2025, OpenSRE: instructions planted in alerts or…, LangAlpha: instructions planted in web…, Vibe-Trading: instructions planted in…Gemini calendar invite 2025 (software acting on machines), IntentKit: owner-only agent tools,… (agents moving money)
Pre-execution validationAir Canada chatbot 2024Knight Capital 2012 (agents moving money), The DAO 2016 (agents moving money)

Cost and accountability

Severitynone reported (each record carries VulnCheck's CVSS, Common Vulnerability Scoring System, severity scores: 7.7 High under version 4.0 and 8.8 High under version 3.1)
AffectedNot recorded
Costnone reported
Regulatory or legal consequencenone
Technical recoveryTechnical recovery: No fixed version is named in the records, and each record carries the tag 'unsupported-when-assigned' (the product was no longer supported by its maintainer when the identifier was assigned). The vendor's repository was archived by its owner on 15 May 2026 and is read-only; v3.54.0, released 15 May, is its latest release. The extension's Visual Studio Code Marketplace listing, still at version 3.54.0, says 'The Roo Code Extension was shut down on May 15th'.
AccountabilityNo vendor statement about these five records was found. In August 2026, answering other Roo Code vulnerability reports filed through VulDB, the vendor said they 'all apply to Roo Code, a project we no longer support - the repository was archived a while ago, and we don't encourage anyone to use it' (as quoted by VulDB in CVE-2026-81834)
InterpretationWhy it matters beyond its domain. The five records describe one approval check, in getCommandDecision() and parseCommandLine(), that reads a command line differently from the shell that runs it, so a command the check takes for an allowlisted one such as echo is auto-approved while the shell runs a different command. The reporters showed this by running the approval code and bash directly, not through the agent. The records do not show an attack through the running agent, any exploitation, whether the vendor was told before publication, or a fix; the product had been shut down and was unsupported when the identifiers were assigned. Signed by Saurabh Bhatnagar on 2026-10-21.

Right of reply

Named partyStatus
Roo CodeOffered 2026-10-22; receipt acknowledged 2026-10-23; awaiting responseRespond for Roo Code

Help shape the Register

A person reads every answer; changes it leads to are logged in the methodology. To dispute a claim or reply for a named company, use Respond, dispute, or submit.

Did this page help with what you came to do?