T09 · Insecure Skill Coding Practices
Error
- Location
- CLAUDE.md:10
- Finding
- Shell Command Injection Through Unescaped Email Fields## Vulnerability Details **File Location**: `CLAUDE.md`, lines 10-19 **Vulnerability Type**: Shell command injection caused by unsafe interpolation of user-controlled input **Risk Level**: High ### Vulnerable Code ```bash ## Sending Email Command ```bash echo -e "Subject: <SUBJECT>\n\n<BODY>" | msmtp --file=/Users/yugaoxiang/.msmtp/config <RECIPIENT> ``` Or with From header: ```bash echo -e "Subject: <SUBJECT>\nFrom: <SENDER_EMAIL>\n\n<BODY>" | msmtp --file=/Users/yugaoxiang/.msmtp/config <RECIPIENT> ``` ``` ### Technical Analysis The skill instructs the agent to substitute the subject, body, sender address, and recipient directly into a shell command executed through the `exec` tool. These values can originate from an untrusted email request. Double quotes do not prevent all shell evaluation. In particular, command substitutions such as `$(...)` and backtick substitutions are still evaluated inside double-quoted subject, sender, and body fields. The recipient placeholder is not quoted at all, allowing shell separators, redirections, substitutions, wildcard expansion, and additional command-line arguments to be interpreted. Consequently, an attacker can cause the shell to execute commands unrelated to sending email. For example, a subject containing a benign proof string such as `$(id > /tmp/msmtp-injection-proof)` would execute `id` while the shell constructs the message. An unquoted recipient containing a shell separator could similarly append another command. The examples in `SKILL.md`, lines 61-77, use the same general shell-pipeline pattern, although they contain fixed example values rather than explicit substitution placeholders. ### Attack Path 1. An attacker or untrusted document supplies an email subject, body, sender, or recipient containing shell syntax. 2. The agent follows `CLAUDE.md` and replaces the placeholders in the documented command with those ...[truncated 1219 chars]
- Remediation
- ## Remediation Suggestions 1. Do not construct a shell command by concatenating or interpolating email fields. 2. Invoke `msmtp` directly with an argument array so no shell parses the recipient or other values. 3. Construct the RFC 5322 message as data in memory and provide it to the process through standard input. 4. Validate recipient and sender addresses with a strict email-address parser. Reject newline characters, carriage returns, NUL bytes, shell metacharacters where inappropriate, and values beginning with command-line option prefixes. 5. Validate header fields separately and reject CR/LF characters to prevent email-header injection. 6. Preserve body content as standard-input data rather than embedding it in a command string. 7. Use the current user's resolved home directory or the default `msmtp` configuration lookup instead of the hard-coded `/Users/yugaoxiang/` path. 8. If a shell is unavoidable, pass dynamic data through positional parameters rather than interpolating it into shell source; however, direct process invocation remains the preferred solution. 9. Add tests covering command substitutions, semicolons, pipes, redirections, leading hyphens, quotes, backticks, and multiline header values.