T09 · Insecure Skill Coding Practices
Error
- Location
references/setup.md:16- Finding
Shell Injection and Plaintext API Key Exposure Through Environment File Handling
- Content
View full analysis
" > ~/.openclaw/openmail.env source ~/.openclaw/openmail.env ``` ```bash printf 'OPENMAIL_INBOX_ID=%s\nOPENMAIL_ADDRESS=%s\n' \ "" "" >> ~/.openclaw/openmail.env source ~/.openclaw/openmail.env ``` ```bash 1. Check the key is present: `echo $OPENMAIL_API_KEY` 2. Confirm it starts with `om_live_` (production) or `om_test_` (test) 3. Direct the user to generate a fresh key at console.openmail.sh ``` ### Technical Analysis The setup instructions serialize the API key, inbox ID, and inbox address directly into a shell environment file without shell escaping. The file is subsequently loaded with `source`, which interprets its contents as shell syntax rather than inert configuration data. For example, a value containing command substitution could produce an environment file such as: ```bash OPENMAIL_API_KEY=$(attacker-controlled-command) ``` When the file is sourced, the shell executes the substituted command with the privileges of the user running the agent. The same issue applies to the inbox ID and address returned by the external service. Merely passing the value as a separate argument to `printf` does not make the resulting file safe to execute. The file contains a long-lived bearer credential in plaintext, but the instructions do not establish restrictive permissions such as mode `0600`. Its effective permissions therefore depend on the current process umask. In addition, the troubleshooting instruction prints the complete API key through `echo`, potentially exposing it in terminal capture, agent transcripts, CI logs, shell debugging output, or monitoring systems. ### Atta ...[truncated 1440 chars]- Remediation
View remediation