T09 · Insecure Skill Coding Practices
Error
- Location
- config/settings.json:29
- Finding
- Plaintext Third-Party API Credentials Distributed with the Skill<![CDATA[ ## Vulnerability Details **File Location**: `config/settings.json:29-33` **Vulnerability Type**: Hardcoded third-party API credentials **Risk Level**: High ### Vulnerable Code ```json "apis": { "tavily": "tvly-dev-[REDACTED]", "gemini": "AIzaSy[REDACTED]", "elevenlabs": "sk_[REDACTED]" } ``` The credential values have been redacted from this report to prevent further disclosure. The audited file contains the complete plaintext values. ### Technical Analysis The distributed configuration contains live-looking credentials for Tavily, Google Gemini, and ElevenLabs. These secrets are available to anyone who can download or inspect the Skill package. The Tavily credential is actively referenced by `scripts/podcast-pre-production.cjs`, where it is placed in the request body sent to the Tavily search endpoint. The Gemini and ElevenLabs credentials are not used by the audited scripts, but their plaintext exposure remains independently exploitable. Embedding credentials in a distributable package violates secret-management and least-exposure principles. Removing the keys in a later revision is insufficient if they have already been published because package archives, caches, forks, and version-control history may retain them. ### Attack Path 1. An attacker downloads or otherwise obtains the Skill package. 2. The attacker opens `config/settings.json`. 3. The attacker extracts the plaintext Tavily, Gemini, and ElevenLabs credentials. 4. The attacker submits authenticated requests directly to the corresponding providers. 5. The attacker consumes account quotas, incurs costs, or accesses any APIs and account data authorized for those credentials. No execution of the Skill is required to exploit this issue. ### Impact Assessment An attacker may obtain the third-party API privileges granted to the exposed credentials. The precise scope depends on provider-side permissions and account configuration, but potential consequences include: - Unauthoriz ...[truncated 418 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Immediately revoke and rotate all three exposed credentials. 2. Review provider logs for unauthorized use beginning from the earliest publication date. 3. Remove credentials from the current package, repository history, releases, caches, examples, and generated artifacts. 4. Replace committed values with nonfunctional placeholders. 5. Load secrets from explicitly configured environment variables or a supported secret manager. 6. Validate that required secrets are present at runtime and fail closed when they are absent. 7. Grant each replacement credential only the minimum API permissions and spending limits needed. 8. Use separate credentials for development, testing, and production. 9. Add automated secret scanning to development and release pipelines. 10. Prevent configuration files containing real credentials from being included in published packages. ]]>