Security: Unvalidated User Input in Shell Command Arguments

[davidcforbes]

Summary

Agent shell command arguments lack validation for shell expansion patterns, allowing potential code execution via glob patterns, variable expansion, and command substitution.

Impact

• Severity: High
• Type: Security vulnerability
• CWE: CWE-78 (OS Command Injection)

Affected Files

• agent/core/policy.go

Vulnerability Details

The current validation only checks for path traversal but doesn't block shell expansion patterns:

• Glob patterns: *, ?, [...]
• Variable expansion: $VAR, ${VAR}, $(cmd)
• Tilde expansion: ~/path
• Windows variables: %USERPROFILE%

These can expand unexpectedly or execute commands when passed to shell.

Recommended Fix

Add comprehensive pattern blocking in denyShellArgsOutsideWorkDir():

func denyShellArgsOutsideWorkDir(workdir string, args []string) error {
    for _, arg := range args {
        // Block shell variable expansion (Unix and Windows)
        dangerousPatterns := []string{
            "$",  // Unix: $HOME, $(cmd), ${VAR}
            "`",  // Command substitution
            "%",  // Windows: %USERPROFILE%
        }
        for _, pattern := range dangerousPatterns {
            if strings.Contains(arg, pattern) {
                return PolicyDeniedError{
                    Kind: PolicyKindPathEscape,
                    Reason: fmt.Sprintf("shell arg contains forbidden pattern %q", pattern),
                }
            }
        }
        
        // Block glob patterns
        if strings.ContainsAny(arg, "*?[") {
            return PolicyDeniedError{
                Kind: PolicyKindPathEscape,
                Reason: "shell arg contains glob pattern",
            }
        }
        
        // Existing path validation...
    }
    return nil
}

References

• Shell Injection Prevention
• CWE-78: OS Command Injection

[kardolus]

I'm sorry but I'm gonna have to disagree with this CWE-78 claim. There's no shell, no expansion, no injection.

[davidcforbes]

Thanks for the quick response, and I totally understand not wanting to overstate the impact.

To clarify, my concern isn’t that the Go code itself is doing shell interpolation, but that the agent is explicitly designed to construct commands that are then executed in a shell context. In that threat model, allowing unvalidated patterns such as $(...), backticks, or %VAR% through to the shell can lead to behavior similar to classic command injection, even if the CLI itself is not calling sh -c directly.

If you’d prefer not to frame this as CWE‑78, I’m happy to adjust the wording to “defense-in-depth hardening of shell arguments for agent-generated commands” and treat it as a security hardening issue rather than a vulnerability. The concrete suggestion is simply to prevent globbing and substitution-style tokens from being passed as arguments, which reduces the blast radius if an agent or prompt is compromised or misused.

I work mostly for regulated banks and financial institutions, so this is a mandatory requirement for them.

Thanks again for this tool. I use it regularly in my daily workflow!

[kardolus]

Hi David! Thanks for following up. I will reopen this issue and think about hardening the shell commands over the weekend. Super appreciate your feedback!

[kardolus]

Fixed here: 8b3a25f