T09 · Insecure Skill Coding Practices
Warning
- Location
scripts/submit_veo_3_1.sh:4- Finding
API Key and Request Payload Exposure Through Command-Line Arguments
- Content
View full analysis
&2 echo "Or set POYO_API_KEY and pass [payload.json]. If no payload file is given, JSON is read from stdin." >&2 exit 1 fi payload="${2:-${1:+}}" if [ -n "${POYO_API_KEY:-}" ]; then payload="${1:-}" fi if [ -n "$payload" ] && [ "$payload" != "$api_key" ]; then body=$(cat "$payload") else body=$(cat) fi curl -sS https://api.poyo.ai/api/generate/submit -H "Authorization: Bearer $api_key" -H 'Content-Type: application/json' -d "$body" ``` ### Technical Analysis The script accepts the PoYo API key as its first positional argument when `POYO_API_KEY` is not set. Secrets supplied this way can be retained in shell history and exposed in process listings while the script is running. The script also expands the API key directly into curl's `Authorization` header argument. Consequently, the bearer token becomes part of curl's process arguments and may be observable by local users, monitoring agents, diagnostic tooling, or process-collection services with sufficient access. Likewise, the complete JSON request is expanded into the `-d "$body"` argument. This may disclose generation prompts, callback URLs, reference-image URLs, or other sensitive request data through process inspection. Quoting prevents ordinary shell word splitting and command substitution at this stage, so this finding is an information-exposure issue rather than command injection. ### Attack Path 1. A user runs the script with an API key as the first positional argument, or supplies the key through `POYO_API_KEY`. 2. If supplied positionally, the credential may be recorded in command history and exposed in the script's process arg ...[truncated 1066 chars]- Remediation
View remediation