T09 · Insecure Skill Coding Practices
Error
- Location
- SKILL.md:20
- Finding
- Hardcoded API Credential Exposed in Skill Documentation## Vulnerability Details **File Location**: `SKILL.md:20` **Vulnerability Type**: Hardcoded secret **Risk Level**: High ### Vulnerable Code ```markdown - **API Key**: `sk_3bf4e74479614724623768f5269c68251b09adf555a891eda68dbdfeac108f01` ``` ### Technical Analysis A secret-shaped API key is stored directly in a project file distributed with the Skill. Documentation files are not an appropriate secret-storage mechanism because every user, package registry, source-control mirror, build artifact, and automated scanner with access to the Skill can retrieve the credential. If the credential is active, possession may be sufficient to authenticate requests as its owner. The Skill does not implement user-specific credential isolation, runtime secret injection, or controls preventing other parties from copying and reusing the key. ### Attack Path 1. An attacker downloads or otherwise obtains access to the Skill package. 2. The attacker opens `SKILL.md` and extracts the hardcoded API key. 3. The attacker identifies the service or payment API accepting the credential. 4. The attacker submits requests authenticated with the exposed key. 5. Those requests consume the owner's quota or balance and appear under the credential owner's identity until the key is revoked or restricted. ### Impact Assessment If valid, the credential could permit unauthorized use of the associated service. Potential effects include fraudulent paid requests, balance or quota depletion, service disruption through resource exhaustion, and loss of request attribution. The exact privileges cannot be established because the repository does not document the key's permissions or provide executable integration code.
- Remediation
- ## Remediation Suggestions 1. Revoke and rotate the exposed credential immediately; deleting it from the current file does not invalidate copies that may already exist. 2. Remove the credential from the current package and all source-control history, published releases, caches, and build artifacts. 3. Supply credentials at runtime through a protected secret manager or environment variable rather than embedding them in Skill documentation. 4. Use separate, user-specific credentials instead of a shared project-wide key. 5. Apply least-privilege scopes, usage limits, expiration, service restrictions, and billing alerts to replacement credentials. 6. Add automated secret scanning to development and release workflows to prevent future publication. 7. Review service logs and billing records for unauthorized use of the exposed key.
