T09 · Insecure Skill Coding Practices
- Location
SKILL.md:28- Finding
API Credential May Be Transmitted over Plaintext HTTP
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 28–39 and 704–721
Vulnerability Type: Transmission of a sensitive API credential over an unencrypted channel
Risk Level: HighThe skill sends
BAMBUDDY_API_KEYin theX-API-Keyrequest header. Its setup instructions explicitly demonstrate anhttp://service URL and permit use of an external URL without requiring HTTPS.bash # Convenience alias — reuse this pattern for every call BB_URL="${BAMBUDDY_URL}/api/v1" BB_AUTH="X-API-Key: ${BAMBUDDY_API_KEY}" # GET example curl -s -H "$BB_AUTH" "$BB_URL/system/info" | jq . # POST example curl -s -X POST -H "$BB_AUTH" -H "Content-Type: application/json" \ -d '{"key":"value"}' "$BB_URL/some/endpoint" | jq .json { "skills": { "entries": { "bambuddy": { "enabled": true, "env": { "BAMBUDDY_URL": "http://192.168.1.x:8000", "BAMBUDDY_API_KEY": "bb_your_key_here" } } } } }text If Bambuddy is on a remote server, use its external URL or set up a Tailscale/WireGuard VPN.Technical Analysis
HTTP provides neither transport confidentiality nor server authentication. When
BAMBUDDY_URLuseshttp://, each request carries the reusable API key in plaintext within the HTTP headers. An attacker able to observe or manipulate the network path can capture theX-API-Keyheader, inspect sensitive responses, modify traffic, or impersonate the Bambuddy server.The risk is particularly significant on shared wireless networks, compromised local networks, untrusted reverse proxies, or remote connections routed across networks outside the user's control. Quoting shell variables protects against ordinary shell word splitting but does not protect the credential in transit.
Attack Path
- A user follows the documented example and configures
BAMBUDDY_URLwith anhttp://LAN or external ad ...[truncated 1379 chars]
- A user follows the documented example and configures
- Remediation
View remediation
Remediation Suggestions
-
Require
https://for every non-loopback Bambuddy URL and clearly mark plaintext HTTP as acceptable only for explicitly isolated local development. -
Replace the documented
http://192.168.1.x:8000example with an HTTPS URL. -
Add a preflight scheme check that refuses insecure remote URLs, for example:
bash case "$BAMBUDDY_URL" in https://*) ;; http://localhost:*|http://127.0.0.1:*|http://[::1]:*) ;; *) echo "Refusing to transmit BAMBUDDY_API_KEY over insecure HTTP" >&2 exit 1 ;; esac -
Configure valid TLS certificates and retain normal certificate verification. Do not recommend
curl -kor--insecure. -
Where direct TLS is unavailable, require a trusted encrypted tunnel such as WireGuard or Tailscale and explain that an arbitrary external HTTP URL is unsafe.
-
Provision least-privilege API keys with only the permissions necessary for the intended workflow. Avoid granting printer-control or administrative capabilities to read-only integrations.
-
Use expiring keys where supported, rotate them regularly, and immediately revoke any key suspected of exposure.
-
Avoid returning or logging credential-bearing command traces, and ensure shell debugging such as
set -xis disabled around authenticated requests.
-
