CVE-2025-58371 is a critical (CVSS 9.8) command injection in the GitHub Actions setup of Roo Code, the AI coding agent for editors. A workflow used unsanitized pull request metadata in a privileged context. Versions 3.26.6 and below are affected, and 3.26.7 fixes it. The pattern is worth checking in your own repositories.
What's affected
Roo Code versions 3.26.6 and below, per the record and the GitHub advisory. The fixed version is 3.26.7.
The weakness is in the project's own GitHub workflow, which ran with broad permissions and access to repository secrets, as the record describes.
For most users of the editor extension the action is to update. The larger lesson applies to anyone who maintains a repository with pull request workflows.
How to check if you're exposed
If you use the extension, check the installed version in your editor.
code --list-extensions --show-versions | grep -i roo
If you maintain repositories, search your workflow files for the pattern behind this bug: pull request titles, branch names, bodies or commit messages placed directly into a shell step.
grep -rn "github.event" .github/workflows
Also check which triggers your workflows use. Workflows triggered by pull requests from forks but running with secrets or write access deserve the most attention.
What to do now
- Update the Roo Code extension to 3.26.7 or later.
- In your own repositories, stop interpolating pull request fields into shell commands. Pass them through environment variables and quote them.
- Reduce the permissions of every workflow token to the minimum, and avoid exposing secrets to workflows that run on untrusted input.
- Rotate secrets that were available to an affected workflow if you have reason to think it ran with hostile input.
Why it matters
The record describes untrusted pull request metadata reaching a command in a privileged workflow. Anyone able to open a pull request could shape that text, and the runner would then execute it with access to secrets and write permissions. The advisory lists consequences from pushing code to creating malicious releases or packages.
This is a software supply chain issue rather than a flaw in the editor itself. A compromised release pipeline poisons everything downstream, which is why CI configuration deserves the same review as application code.
The record classifies the weakness as CWE-78 (OS Command Injection).
A useful habit is to treat any value controlled by an outside contributor as hostile data: titles, branch names, labels, comments. Keep those out of shell steps, use the least privileged token each job needs, and split privileged jobs from jobs that touch untrusted input.
The record shows this CVE is not in the CISA Known Exploited Vulnerabilities catalog.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
Do I need to do anything as an extension user?
Update to 3.26.7 or later. The flaw was in the project's build workflow, so the bigger task is checking your own workflows for the same pattern.
What made this critical?
The record says the workflow ran with broad permissions and secret access, so command execution could lead to repository compromise.
Sources
Last reviewed: 18 October 2026.
