CVE-2026-76072: Continue CLI through 1.5.47 Incomplete Destructive Command Denylist in Headless and Auto Mode
The Continue CLI applies an incomplete denylist as its only barrier to destructive shell commands when running unattended. In headless mode and auto mode the default policy in extensions/cli/src/permissions/defaultPolicies.ts grants the Bash tool the allow permission, and permissionChecker.ts hard-blocks a command only when the terminal-security evaluator returns a disabled verdict, so isCriticalCommand in packages/terminal-security/src/evaluateTerminalCommandSecurity.ts is the sole control. Its dangerous-path test matches only /, /, ~, ~/, /usr, /etc, /bin and /sbin and their prefixes, so a recursive forced removal of /home, /root, /var, /opt or /srv is not disabled. The command line is parsed with shell-quote, which reduces $HOME to an empty token, so rm -rf $HOME also fails the dangerous-path test while the shell re-expands the variable when the command is spawned. find with -delete is rated high risk rather than disabled, and shred, wipefs, truncate and pkexec are not handled. Because the agent autonomously reads content it does not control, including fetched web pages, repository files and issue text, an indirect prompt injection in that content can cause an unattended run to destroy the invoking user's data.
Affected Software
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Deployments running the Continue CLI in headless mode or auto mode are exposed because the default policy allows the Bash tool in those unattended modes. Interactive use is not identified as affected by the provided information.
What does an attacker need to exploit it?
An attacker needs to get malicious instructions into content the agent reads, such as a fetched web page, repository file, or issue text. The unattended agent can then be induced through indirect prompt injection to run destructive commands that the denylist does not disable.
Which destructive commands can bypass the terminal-security control?
Examples include recursive forced removal targeting /home, /root, /var, /opt, or /srv, as well as rm -rf $HOME because $HOME is parsed as an empty token before the spawned shell expands it. The control also does not handle shred, wipefs, truncate, or pkexec, while find with -delete is classified as high risk rather than disabled.
What can be done if patching is not immediately possible?
Avoid running the CLI unattended in headless or auto mode with the default Bash allow policy. In particular, do not allow autonomous runs to consume untrusted fetched pages, repository content, or issue text while Bash execution remains permitted.