T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/submit_sora_2_pro.sh:4
- Finding
- API Key Exposure Through Command-Line Arguments## Vulnerability Details **File Location**: `scripts/submit_sora_2_pro.sh`, lines 4–6 **Vulnerability Type**: API key exposure through process arguments and shell history **Risk Level**: Medium ### Vulnerable Code ```sh api_key="${POYO_API_KEY:-${1:-}}" if [ -z "$api_key" ]; then echo "Usage: submit_sora_2_pro.sh [api_key] [payload.json]" >&2 ``` ### Technical Analysis The script accepts the PoYo API key as its first positional command-line argument when `POYO_API_KEY` is unset. Secrets passed this way may be recorded in shell history and exposed through process inspection while the script is running. The usage message explicitly encourages this insecure invocation method. The API key is subsequently used as a bearer token for requests to the PoYo generation API. Although transmitting it to that declared HTTPS endpoint is necessary for the skill's stated function, accepting it through a positional argument unnecessarily exposes the credential on the local system. ### Attack Path 1. A user invokes the script as documented: ```sh ./scripts/submit_sora_2_pro.sh 'POYO_API_KEY_VALUE' payload.json ``` 2. The command, including the plaintext key, may be retained in the user's shell-history file. 3. While the process is running, the argument may also be visible through local process-monitoring interfaces, subject to operating-system permissions and hardening. 4. A local user, monitoring process, support-data collector, or account with access to the history file retrieves the credential. 5. The attacker sends authenticated requests to the PoYo API using the stolen bearer token. ### Impact Assessment Successful exploitation discloses the user's PoYo API credential. An attacker could authenticate to services available to that key, submit billable generation requests, consume account quotas, and access any other API operations authorized for the credential. This issue does not itself provide operating-syst ...[truncated 264 chars]
- Remediation
- ## Remediation Suggestions 1. Remove support for supplying the API key as a positional argument. 2. Require `POYO_API_KEY` to be provided through the environment or a protected secret-management mechanism. 3. Change the usage message so it no longer recommends placing a credential on the command line. 4. If interactive entry is required, read the key without terminal echo and avoid exporting or logging it. 5. Ensure CI/CD systems inject the credential through masked secret variables rather than command arguments. 6. Advise users who previously supplied keys as arguments to clear affected shell-history entries and rotate potentially exposed credentials. A safer initialization pattern is: ```sh api_key="${POYO_API_KEY:-}" if [ -z "$api_key" ]; then echo "POYO_API_KEY must be set." >&2 echo "Usage: submit_sora_2_pro.sh [payload.json]" >&2 exit 1 fi payload="${1:-}" ```