CVE-2026-77474 in destructive_command_guard
Summary
by MITRE • 10/16/2026
destructive_command_guard (dcg) is a command-line safety tool that blocks destructive shell commands before AI coding agents run them. Prior to 0.6.6, nested or unclosed substitutions are recursively rescanned after an inner scan returns unterminated, producing exponential-time work. The affected scanners are reached through split_command_segments in src/packs/mod.rs. a destructive command followed by nested or unclosed $( or $(( sequences. nested or unclosed $( and $(( sequences cause repeated rescanning of the remaining command suffix. a hung PreToolUse hook fails open, allowing the destructive command to proceed. This issue is fixed in version 0.6.6.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 10/16/2026
The vulnerability identified within the destructive_command_guard tool represents a critical flaw in its input parsing logic, specifically affecting versions prior to 0.6.6. As a safety mechanism designed to intercept and block harmful shell commands before they are executed by AI coding agents, this tool operates as a gatekeeper for automated development workflows. The core issue stems from an algorithmic inefficiency that leads to exponential time complexity when processing specific malformed inputs. This behavior is triggered through the split_command_segments function located in src/packs/mod.rs, which is responsible for breaking down command strings into manageable segments for analysis. When the tool encounters a destructive command followed by nested or unclosed shell substitution sequences, such as $( or $((, it enters an infinite loop of rescanning operations rather than failing safely or rejecting the input immediately.
The technical root cause lies in how the scanner handles unterminated substitutions during its initial pass. Upon detecting that an inner scan has returned with an indication of being unterminated, the system recursively rescansthe remaining command suffix to attempt recovery or further validation. However, because the logic does not properly account for nested structures where each level adds more complexity without a terminating condition, this recursive rescanning results in exponential growth in computational work relative to the depth and length of the unclosed sequences. This is a classic example of an algorithmic vulnerability that can be exploited through carefully crafted input strings designed to maximize nesting levels or leave parentheses open indefinitely. Such behavior aligns with CWE-400, which describes uncontrolled resource consumption due to insufficient control over loop iterations or recursive calls.
From an operational perspective, this flaw poses a significant risk of denial-of-service conditions against the AI agent infrastructure that relies on destructive_command_guard for safety checks. If an attacker can inject payloads containing deeply nested or unclosed shell substitutions into the command stream processed by the tool, they can cause the guard to hang indefinitely. This excessive CPU consumption and memory usage effectively render the protection mechanism useless during the attack window. More critically, the implementation includes a fail-open design pattern where if the PreToolUse hook responsible for running these checks hangs or times out, it defaults to allowing the command to proceed. Consequently, an attacker could bypass safety restrictions entirely by triggering this hang condition, thereby enabling the execution of destructive commands that were intended to be blocked. This scenario is particularly dangerous in automated CI/CD pipelines or agent-based development environments where such tools are expected to provide real-time protection without introducing latency or instability.
The exploitation vector for this vulnerability typically involves command injection techniques aimed at the interface where shell commands are submitted to the AI coding agents. By crafting inputs that include complex, nested substitution patterns like $($(($(...))) with missing closing brackets, an adversary can force the scanner into a state of exponential recursion. This aligns with ATT&CK technique T1059, specifically sub-techniques related to command and script interpretation, as it involves manipulating how commands are parsed and executed by downstream systems. The failure mode described highlights a critical gap in defensive coding practices where error handling for malformed input does not prioritize safety over functionality. Instead of failing closed when parsing ambiguity is detected, the system continues processing until resources are exhausted or timeouts occur, at which point the security control fails open.
To mitigate this vulnerability, organizations must upgrade to version 0.6.6 or later of destructive_command_guard, where the logic for handling nested substitutions has been corrected to prevent exponential rescanning. In addition to upgrading, it is advisable to implement strict input validation and sanitization at the application layer before commands reach the guard tool. This includes enforcing limits on command length and nesting depth to reduce the attack surface. Furthermore, security architects should review the fail-open configuration of the PreToolUse hook. Implementing a fail-closed approach would ensure that if any part of the safety check process becomes unresponsive or encounters an error, the default action is to block the command rather than allow it. This aligns with best practices for secure system design where availability issues should not compromise security integrity. Regular auditing of third-party libraries used in AI agent workflows is also essential to ensure that such parsing vulnerabilities are identified and patched before they can be leveraged in production environments.