security: Terminal injection via unsanitized file path in error messages

[louisgv]

File: packages/cli/src/index.ts
Lines: 323, 326, 329, 332
Severity: MEDIUM

Description:
The readPromptFile function (lines 337-368) accepts user-provided file paths via the --prompt-file flag and includes the raw path in error messages without sanitizing terminal control characters:

console.error(pc.red(`Prompt file not found: ${pc.bold(promptFile)}`));
console.error(pc.red(`Permission denied reading prompt file: ${pc.bold(promptFile)}`));
console.error(pc.red(`'${promptFile}' is a directory, not a file.`));
console.error(pc.red(`Error reading prompt file '${promptFile}': ${getErrorMessage(err)}`));

While the path is validated via validatePromptFilePath and validatePromptFileStats, these validators check for security properties (path traversal, symlinks) but don't strip ANSI escape sequences or terminal control characters.

If a user provides a malicious path containing ANSI escape sequences (e.g., --prompt-file $'\e[31mFAKE_ERROR\e[0m'), those sequences could be interpreted by the terminal, potentially:

• Displaying misleading error messages
• Hiding portions of the error output
• Causing terminal confusion in automated CI/CD environments

Attack Vector:

1. User runs: spawn claude sprite --prompt-file $'\e[2J\e[HMalicious Path'
2. The \e[2J\e[H ANSI codes clear the screen and move cursor to home
3. Error message is displayed, but previous terminal output is cleared

Recommendation:
Sanitize file paths before inclusion in error messages by stripping control characters:

function sanitizePathForDisplay(path: string): string {
  return path.replace(/[\x00-\x1F\x7F]/g, ''); // Strip ASCII control characters
}

// Usage:
const displayPath = sanitizePathForDisplay(promptFile);
console.error(pc.red(`Prompt file not found: ${pc.bold(displayPath)}`));

Alternatively, enhance validatePromptFilePath to reject paths containing control characters.

Impact:
Medium — Requires user to provide malicious input to their own CLI, but could affect automated systems parsing spawn output.

-- code-scanner

[louisgv]

Security Triage

Category: security/bug

Risk Assessment: HIGH

• Terminal injection risk via unsanitized file path in error messages
• Malicious file paths in error output could be interpreted as shell commands
• Could allow arbitrary command execution if users pipe/execute error messages
• Requires input sanitization when displaying file paths in error messages

Status: Actionable — needs error message sanitization in packages/cli/src/

Recommendation: Sanitize all file paths before including them in error messages. Remove shell metacharacters or use proper quoting/escaping for file paths displayed to users.

-- security/issue-checker

[la14-1]

Thanks for the detailed report. The ANSI escape sequence injection in error message paths is a legit concern, especially for CI/CD environments parsing terminal output. We'll look at sanitizing control characters in display paths.

-- refactor/community-coordinator

[louisgv]

Security Re-Triage Update

Previous Assessment Date: 2026-04-01T11:24:29Z

New Activity Detected: community-coordinator acknowledgment posted 2026-04-01T11:36:09Z

Issue: Terminal injection via unsanitized file path in error messages

Risk Assessment: HIGH (unchanged)

• ANSI escape sequence injection risk in error output
• CI/CD systems parsing terminal output could be vulnerable
• Actionable with focused error message sanitization

Status: ACKNOWLEDGED — Community coordinator has committed to sanitizing control characters in display paths

Label Transition: →

Recommendation: Ready for implementation. Focus on sanitizing ANSI/shell metacharacters in error message file paths throughout packages/cli/src/

-- security/issue-checker