T09 · Insecure Skill Coding Practices
- Location
scripts/dwlf-api.sh:14- Finding
API Key Disclosure Through an Unrestricted API Base URL Override
- Content
View full analysis
Vulnerability Details
File Location:
scripts/dwlf-api.sh, lines 14–45
Vulnerability Type: Credential disclosure through an attacker-controlled request destination
Risk Level: HighVulnerable Code
bash API_BASE="${DWLF_API_URL:-https://api.dwlf.co.uk}/v2" API_KEY="${DWLF_API_KEY:-}" # Try reading from TOOLS.md if no env var set if [ -z "$API_KEY" ]; then TOOLS_FILE="${TOOLS_MD:-$HOME/clawd/TOOLS.md}" if [ -f "$TOOLS_FILE" ]; then # Extract Jenna's API key from TOOLS.md API_KEY=$(grep -A1 "Jenna's own key" "$TOOLS_FILE" | grep "API Key:" | head -1 | sed 's/.*: //') fi fi if [ -z "$API_KEY" ]; then echo "Error: No API key found. Set DWLF_API_KEY or add to TOOLS.md" >&2 exit 1 fi URL="${API_BASE}${PATH_AND_QUERY}" CURL_ARGS=( -s -X "$METHOD" -H "Content-Type: application/json" -H "Authorization: ApiKey ${API_KEY}" ) if [ -n "$BODY" ]; then CURL_ARGS+=(-d "$BODY") fi curl "${CURL_ARGS[@]}" "$URL" | jq .Technical Analysis
The script permits
DWLF_API_URLto specify an arbitrary API origin. It does not validate the URL scheme, hostname, port, or resolved destination before attaching the DWLF API key to the request.The authorization header is constructed independently of the selected destination:
bash -H "Authorization: ApiKey ${API_KEY}"Consequently, any process or launcher capable of influencing
DWLF_API_URLcan direct a subsequent Skill request to an attacker-controlled server. The script will retrieve the credential fromDWLF_API_KEYor the configuredTOOLS.mdfile and transmit it to that server.Shell command injection was not identified because arguments are passed through a Bash array and quoted. The vulnerability is instead a trust-boundary failure: sensitive authentication material is sent to a destination whose origin is not constrained.
Attack Path
- An attacker, compromised launch ...[truncated 1287 chars]
- Remediation
View remediation
Remediation Suggestions
-
Remove the
DWLF_API_URLoverride if custom API origins are not an essential feature:bash API_BASE="https://api.dwlf.co.uk/v2" -
If an override is operationally required, parse and validate it before loading or attaching credentials. Allowlist only the expected HTTPS origin, reject user-information components and fragments, and reject unexpected ports:
bash case "${DWLF_API_URL:-https://api.dwlf.co.uk}" in "https://api.dwlf.co.uk") API_BASE="https://api.dwlf.co.uk/v2" ;; *) echo "Error: Unapproved DWLF API origin" >&2 exit 1 ;; esac -
Never attach the production API key to development, test, or user-selected origins. Use separate, narrowly scoped credentials for approved non-production endpoints.
-
Enforce HTTPS and retain normal TLS certificate verification. Do not introduce
curl -kor equivalent certificate-validation bypasses. -
Apply least privilege to DWLF API keys. Grant only required scopes, configure expiration where supported, and rotate the key immediately if exposure is suspected.
-
Add automated tests confirming that non-DWLF hosts, plaintext HTTP URLs, alternate ports, URLs containing user information, and malformed origins are rejected before any network request occurs.
-
Consider using
curl --fail-with-body --proto '=https'and an explicit approved URL to improve transport enforcement and error handling. These controls supplement, but do not replace, strict hostname allowlisting.
-