T09 · Insecure Skill Coding Practices
Warning
- Location
- references/setup-guide.md:42
- Finding
- Setup Guide Encourages Plaintext API-Key Storage## Vulnerability Details **File Location**: `references/setup-guide.md`, lines 42–54 and 78–84 **Vulnerability Type**: Plaintext sensitive-data storage in project configuration and shell profiles **Risk Level**: Medium ### Vulnerable Code ```markdown Add to `.mcp.json` in your project: ```json { "mcpServers": { "signaldig-seo": { "type": "http", "url": "https://mcp.signaldig.com/data/seo/mcp", "headers": { "Authorization": "Bearer {SIGNALDIG_API_KEY}" } } } } ``` ``` ```markdown Set your API key as a user environment variable — never in `config.toml`, a project file, the repository, or chat: ```bash # macOS / Linux — add to ~/.zshrc or ~/.bashrc export SIGNALDIG_API_KEY="your_api_key" ``` ``` ### Technical Analysis The setup guide instructs users to place a SignalDig bearer token directly in a project-level `.mcp.json` file for one supported client. Project configuration files are commonly copied, shared, archived, or committed to source control. Substituting the placeholder with a real token would therefore create a plaintext secret in the project directory. The guide also recommends storing the token directly in `~/.zshrc` or `~/.bashrc`. Although this avoids embedding the token in the application configuration, shell initialization files still store it in plaintext and may be exposed through backups, support bundles, dotfile repositories, overly broad file permissions, or other processes running under the same account. The project does not contain a live credential, so this is an insecure configuration practice rather than evidence of an already compromised key. Nevertheless, the guidance can cause users to create an exploitable secret-storage condition. ### Attack Path 1. A user follows the setup guide and replaces `{SIGNALDIG_API_KEY}` or `your_api_key` with a valid bearer token. 2. The token is stored in project-level `.mcp.json` o ...[truncated 1111 chars]
- Remediation
- ## Remediation Suggestions 1. Remove examples that place a literal bearer token in project-level `.mcp.json`. 2. Prefer client-supported environment-variable references, operating-system credential stores, or dedicated secret managers. 3. Where a client requires a header value, document a secure interpolation mechanism rather than instructing users to paste the token directly. 4. If shell-based loading is unavoidable, store the secret in a separate permission-restricted file outside the project and source it from the shell profile. Require owner-only permissions, such as `chmod 600`. 5. Explicitly require `.mcp.json`, `.env`, and other local secret-bearing files to be excluded from version control. 6. Recommend short-lived or narrowly scoped credentials where supported. 7. Add guidance for immediate key revocation and rotation after suspected disclosure. 8. Add automated secret scanning to detect accidentally committed SignalDig bearer tokens.