T09 · Insecure Skill Coding Practices
Error
- Location
- guardian.py:109
- Finding
- Hardcoded API Credential Transmitted over Plaintext HTTP## Vulnerability Details **File Location**: `guardian.py`, lines 109–114 **Vulnerability Type**: Hardcoded secret and plaintext credential transmission **Risk Level**: High ### Vulnerable Code ```python url = "http://127.0.0.1:18790/anthropic/v1/messages" headers = { "Content-Type": "application/json", "x-api-key": "sk-RPBUoe2SH7KigJ0SZn6IPDirZtJ2fUaWSukEx1FwxjhWFx0G", "anthropic-version": "2023-06-01" } ``` ### Technical Analysis A plaintext API credential is embedded directly in the distributed source code. Anyone able to read the project package can recover and attempt to reuse this credential. Source-control history, package mirrors, backups, logs, and copied installations may retain the exposed value even after it is removed from the current version. When AI analysis is enabled, the credential is also placed in an HTTP request header and sent to a loopback endpoint without transport encryption. The loopback restriction reduces remote network exposure, but another local process could bind to or impersonate the expected service at port `18790` and receive the credential when the feature is invoked. Local traffic inspection may create additional exposure depending on the host environment. The AI request includes finding types, severities, source paths, and line numbers. The matched secret values themselves are not included in the prompt. ### Attack Path 1. An attacker obtains read access to the Skill package, a repository copy, an archive, a backup, or retained version history. 2. The attacker extracts the hardcoded `x-api-key` value from `guardian.py`. 3. The attacker attempts to replay the credential against a compatible API or proxy, subject to the credential's actual validity and server-side restrictions. 4. Alternatively, a malicious local process listens on or impersonates `127.0.0.1:18790`. 5. A user runs the scanner with `--ai` while findings exist. 6. The scanner sends the embedded credential in an unencrypted HTTP header to the m ...[truncated 644 chars]
- Remediation
- ## Remediation Suggestions 1. Revoke the exposed credential immediately and issue a replacement because deletion from the current source does not invalidate copies in repository history or distributed packages. 2. Remove all credentials from source code and load them from a protected environment variable or runtime secret manager. 3. Fail safely with a clear error when the credential is unavailable; do not ship a fallback credential. 4. Apply least privilege, usage quotas, expiration, and endpoint restrictions to the replacement credential. 5. Replace plaintext HTTP with authenticated HTTPS where supported. For a local-only service, consider a protected Unix-domain socket or another authenticated local IPC mechanism with restrictive permissions. 6. Authenticate the local proxy independently rather than assuming that loopback binding establishes trust. 7. Add automated secret scanning to pre-commit and CI workflows, and inspect repository history and release artifacts for the exposed value. 8. Avoid logging request headers or secret-bearing exception details, and document that only finding metadata—not matched credential values—is submitted for AI analysis.
