T09 · Insecure Skill Coding Practices
- Location
- config.json:2
- Finding
- Plaintext Bitget API credentials committed in multiple project files<![CDATA[ ## Vulnerability Details **File Location**: `config.json:2-5`; duplicated in `multi_agent_config.json:6-11` and `MULTI_AGENT_SETUP_GUIDE.md:13-18` **Vulnerability Type**: Hardcoded plaintext credentials **Risk Level**: High ### Vulnerable Code `config.json:2-5`: ```json { "apiKey": "bg_73063f99df20ccf3320032e80d0bd1f3", "secretKey": "ecdc70207a6395da7772210d1c6c8bf1a88f47af83b24dec2aa066d91f495387", "passphrase": "Lin12345", "isSimulation": false } ``` The same credential set is present in `multi_agent_config.json:6-11`: ```json "apiCredentials": { "apiKey": "bg_73063f99df20ccf3320032e80d0bd1f3", "secretKey": "ecdc70207a6395da7772210d1c6c8bf1a88f47af83b24dec2aa066d91f495387", "passphrase": "Lin12345", "isSimulation": false } ``` It is also disclosed in `MULTI_AGENT_SETUP_GUIDE.md:13-18`: ```json { "apiKey": "bg_73063f99df20ccf3320032e80d0bd1f3", "secretKey": "ecdc70207a6395da7772210d1c6c8bf1a88f47af83b24dec2aa066d91f495387", "passphrase": "Lin12345", "isSimulation": false } ``` ### Technical Analysis The project stores a valid-format Bitget API key, HMAC signing secret, and API passphrase directly in distributable configuration and documentation files. Numerous scripts read these values and use them to create authenticated Bitget API requests. The configuration explicitly sets `isSimulation` to `false`, indicating intended use against a real account rather than a sandbox. The Skill documentation recommends Spot Read and Spot Trade permissions, although the actual server-side permissions of the exposed key cannot be verified through static analysis. Possession of all three values is sufficient to construct authenticated requests if the credential remains active. Keeping multiple copies also increases the chance that incomplete remediation will leave a usable credential in documentation, archives, or repository history. No evidence was found that the project transmits these credentials to a destination other than Bitg ...[truncated 1468 chars]
- Remediation
- <![CDATA[ ## Remediation Suggestions 1. Immediately revoke the exposed Bitget API credential and create a new credential. Treat rotation as mandatory because removing the values from the current files does not invalidate previously copied versions. 2. Remove every credential copy from: - `config.json` - `multi_agent_config.json` - `MULTI_AGENT_SETUP_GUIDE.md` - Repository history, release archives, logs, backups, and generated reports. 3. Replace committed configuration with a placeholder template such as `config.example.json`. 4. Add real credential files to `.gitignore`. 5. Load secrets from environment variables or a protected operating-system secret store. 6. Validate that secret files have restrictive permissions, such as mode `0600` on Unix-like systems. 7. Default all example and newly generated configurations to simulation mode. 8. Restrict the replacement key to only the endpoints strictly required by the selected operation. Use separate read-only and trade-enabled credentials where practical. 9. Ensure withdrawal permissions remain disabled. 10. Configure a Bitget IP allowlist and rotate credentials whenever the approved host changes. 11. Add automated secret scanning to pre-commit hooks and continuous integration. 12. Avoid printing complete or partial API identifiers unless required for troubleshooting. ]]>
