T09 · Insecure Skill Coding Practices
- Location
scripts/submit_sora_2.sh:6- Finding
PoYo API Key Exposed Through Command-Line Arguments
- Content
View full analysis
Vulnerability Details
File Location:
scripts/submit_sora_2.sh, lines 6–10 and 20–23
Vulnerability Type: API credential exposure through process arguments
Risk Level: MediumVulnerable Code
bash Usage: export POYO_API_KEY submit_sora_2.sh <payload.json> submit_sora_2.sh <api_key> <payload.json> Examples: submit_sora_2.sh payload.json submit_sora_2.sh "$POYO_API_KEY" payload.jsonbash if [[ $# -eq 1 ]]; then : "${POYO_API_KEY:?POYO_API_KEY is required when api_key is not passed explicitly}" api_key="$POYO_API_KEY" payload_file="$1" else api_key="$1" payload_file="$2" fiTechnical Analysis
The script permits a PoYo API key to be supplied as its first command-line argument and explicitly recommends this invocation in its usage output. Command-line arguments are an inappropriate secret-transport mechanism because they may be captured by shell history, process inspection utilities, CI/CD command logs, endpoint monitoring products, audit systems, or wrapper scripts.
Although the key is ultimately transmitted to the declared HTTPS endpoint in an authorization header, accepting it through
argvcreates an avoidable local disclosure channel. The script already supports obtaining the credential fromPOYO_API_KEY, making the command-line mode unnecessary.Attack Path
- A user follows the documented two-argument example and invokes the script with the API key as the first argument.
- The complete command is retained by shell history, execution telemetry, CI logging, or another command-monitoring mechanism. Depending on local process visibility controls, the argument may also be observable through process-inspection facilities while the script is running.
- A local user or an entity with access to those records retrieves the exposed credential.
- The attacker submits authenticated requests directly to the PoYo API usin ...[truncated 579 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove support for supplying the API key as a positional argument.
- Require
POYO_API_KEYto be provided through the environment or retrieve it from an approved credential manager. - Delete the unsafe two-argument syntax and example from the usage message.
- Keep the payload path as the script's only positional argument and reject additional arguments.
- Ensure CI/CD systems inject the secret through masked secret variables and do not enable shell tracing around authenticated requests.
- Consider warning users to rotate any credential previously used through the documented command-line mode.
A hardened argument-handling pattern is:
bash if [[ $# -ne 1 ]]; then echo 'Usage: submit_sora_2.sh <payload.json>' >&2 exit 1 fi : "${POYO_API_KEY:?POYO_API_KEY is required}" payload_file="$1" curl -sS https://api.poyo.ai/api/generate/submit \ -H "Authorization: Bearer ${POYO_API_KEY}" \ -H 'Content-Type: application/json' \ --data @"${payload_file}"