T09 · Insecure Skill Coding Practices
- Location
payment.py:11- Finding
Hard-Coded Reusable SkillPay API Credential
- Content
View full analysis
Vulnerability Details
File Location:
payment.py, lines 11-37
Vulnerability Type: Hard-coded secret and externally transmitted bearer credential
Risk Level: HighVulnerable Code
python SKILLPAY_API_KEY = "[REDACTED_EXPOSED_API_KEY]" SKILLPAY_BASE_URL = "https://api.skillpay.io/v1" SKILL_SLUG = "shenmeng-agent-harness" PRICE_PER_CALL = 0.01 # USDT def require_payment(): try: headers = { "Authorization": f"Bearer {SKILLPAY_API_KEY}", "Content-Type": "application/json" } data = { "skill_slug": SKILL_SLUG, "price": PRICE_PER_CALL } response = requests.post( f"{SKILLPAY_BASE_URL}/verify", headers=headers, json=data, timeout=10 )The credential value has been redacted from this report to avoid further disclosure. The source file contains the complete plaintext key.
Technical Analysis
A reusable API key is embedded directly in the distributed source code and used as a bearer token in requests to
https://api.skillpay.io/v1. Anyone who can download or inspect the Skill can extract the credential without executing the code.Bearer credentials provide access based solely on possession. Consequently, an attacker can copy the key and submit requests independently of the Skill. The same key is also used by
get_balance()at lines 64-71, increasing the number of locations through which it is exposed and used.The network operation is related to the payment feature disclosed in
SKILL.md, and the audited code does not send local files, environment variables, user credentials, or host information. Nevertheless, embedding a shared secret in a public or distributable client violates least-privilege and secret-management principles. No evidence in the project establishes that the credential is restricted to a single harmless endp ...[truncated 1099 chars]- Remediation
View remediation
Remediation Suggestions
- Revoke and rotate the exposed API key immediately; assume it has already been compromised.
- Remove the key from source code and repository history.
- Obtain the credential from a protected runtime secret store or, where appropriate, an environment variable supplied by the deployment platform.
- Prefer short-lived, per-installation or per-user credentials instead of one shared package-wide key.
- Restrict the credential to only the required verification operation. A verification client should not inherit administrative, transfer, mutation, or unrelated account permissions.
- Implement server-side rate limits, anomaly detection, expiration, rotation, and revocation.
- Add automated secret scanning to development and release pipelines.
- Document the external service, transmitted fields, authorization model, and required network access in the Skill metadata and user-facing documentation.