T09 · Insecure Skill Coding Practices
- Location
scripts/zy_api.sh:24- Finding
API Key Exposed Through the curl Process Command Line
- Content
View full analysis
Vulnerability Details
File Location:
scripts/zy_api.sh, lines 24-35
Vulnerability Type: Credential exposure through process arguments
Risk Level: MediumVulnerable Code
bash CURL_ARGS=( -s -w "\n%{http_code}" -X "$METHOD" -H "X-API-Key: ${ZAPYETI_API_KEY}" -H "Content-Type: application/json" ) if [ -n "$BODY" ]; then CURL_ARGS+=(-d "$BODY") fi RESPONSE=$(curl "${CURL_ARGS[@]}" "${BASE_URL}${PATH_ARG}")Technical Analysis
The script expands
ZAPYETI_API_KEYinto the argument supplied to curl through the-Hoption. Consequently, the resulting curl process receives an argument equivalent to:text X-API-Key: sensitive-key-valueOn systems where process arguments are visible through process-monitoring utilities or process metadata interfaces such as
/proc, another local user or monitoring component may capture the key while curl is running. Although the exposure window is limited to the lifetime of the curl process, repeated API calls increase the opportunity for observation. Long-running requests can further extend that window.Exploitability depends on the operating system's process-visibility controls and the attacker's ability to observe other processes. This issue does not by itself grant local code execution or elevated operating-system privileges.
Attack Path
- A victim configures a valid
ZAPYETI_API_KEYand invokesscripts/zy_api.sh. - The script interpolates the key into curl's
X-API-Keycommand-line argument. - A local attacker or process-monitoring service observes curl's arguments while the request is active.
- The attacker extracts the API key from the visible header argument.
- The attacker submits requests directly to
https://api.zapyeti.comusing the stolen key. - The attacker can access or modify resources permitted by that key until it is revoked or expires.
Impact Assessment
Successful exploitation ...[truncated 654 chars]
- A victim configures a valid
- Remediation
View remediation
Remediation Suggestions
Avoid placing sensitive header values directly in curl's command-line arguments.
Prefer a protected, short-lived curl configuration file supplied through standard input, so the secret does not appear in process arguments:
bash RESPONSE=$( { printf 'header = "X-API-Key: %s"\n' "$ZAPYETI_API_KEY" printf 'header = "Content-Type: application/json"\n' } | curl --config - \ -sS \ -w $'\n%{http_code}' \ -X "$METHOD" \ ${BODY:+--data "$BODY"} \ "${BASE_URL}${PATH_ARG}" )Because conditional array handling is safer than shell parameter expansion for the body, the implementation should ideally retain an argument array for non-secret options and pass only the secret configuration through standard input. Additional hardening should include:
- Ensure the secret is never printed in normal output, debug traces, or error logs.
- Explicitly disable shell tracing around credential handling if callers might enable
set -x. - Apply restrictive process-visibility controls, such as an appropriately configured
/procmount, as defense in depth. - Use narrowly scoped API keys with the minimum required permissions.
- Support key expiration and rotation.
- Revoke and replace any key suspected of having been exposed.
- Review monitoring and telemetry systems to ensure they do not retain command-line arguments containing credentials.