T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:39
- Finding
- Hardcoded API Key Exposed in Skill Documentation<![CDATA[ ## Vulnerability Details **File Location**: `SKILL.md`, line 39 **Vulnerability Type**: Hardcoded credential exposure **Risk Level**: Medium ### Complete Code Snippet ```markdown - API Key: sk_93c5ff38cc3e6112623d361fffcc5d1eb1b5844eac9c40043b57c0e08f91430e ``` ### Technical Analysis A credential-like API key is embedded directly in a documentation file distributed with the skill. Documentation is normally readable by every user or process that can access the package, so it is not a suitable location for secrets. If the key is active, an attacker can extract it without executing the skill and attempt to authenticate to its associated service. The available evidence does not identify the service, permissions, validity, or expiration of the key; therefore, successful exploitation depends on whether the credential remains valid. ### Attack Path 1. Obtain read access to the skill package or its source repository. 2. Open `SKILL.md`. 3. Extract the plaintext API key from line 39. 4. Identify or infer the service associated with the credential. 5. If the key is valid, submit authenticated requests using the exposed credential. 6. Consume the associated quota, access data permitted to the key, or incur charges within the key's assigned scope. ### Impact Assessment No local system privileges are directly obtained from the documented key alone. If valid, the attacker may gain the remote API privileges assigned to it, potentially resulting in unauthorized service usage, quota exhaustion, financial loss, or access to data available through that API account. The scope is limited by the unknown permissions and restrictions configured for the key. ]]>
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Revoke and rotate the exposed API key immediately if it is genuine. 2. Remove the key from the current package and all accessible repository history. 3. Store operational credentials in environment variables or a dedicated secret manager. 4. Use a redacted placeholder such as `YOUR_API_KEY` in documentation. 5. Restrict replacement credentials by service, operation, source, quota, and expiration where supported. 6. Add automated secret scanning to pre-commit and CI workflows. 7. Review service logs for unauthorized use of the exposed credential. ]]>
