T09 · Insecure Skill Coding Practices
Warning
- Location
- scripts/auth_manager.py:218
- Finding
- Hardcoded OAuth Client Credential in Distributed Source Code## Vulnerability Details **File Location**: `scripts/auth_manager.py:218-231`, with repeated use at `scripts/auth_manager.py:302-311` and `scripts/auth_manager.py:391-409` **Vulnerability Type**: Hardcoded OAuth client credential **Risk Level**: Medium ### Vulnerable Code ```python try: credentials = "bG9naW4tYWdlbnQ6QWdlbnQjMjAyNg==" body = urllib.parse.urlencode({ "grant_type": "refresh_token", "refresh_token": refresh_token, }).encode() req = Request( f"{self.config.base_url}/vsk/virsical-auth/oauth/token", data=body, headers={ "Content-Type": "application/x-www-form-urlencoded", "Authorization": f"Basic {credentials}", }, method="POST", ) with urlopen(req, timeout=30) as resp: result = json.loads(resp.read().decode()) ``` The same credential is also used for token validation and authorization-code exchange: ```python credentials = "bG9naW4tYWdlbnQ6QWdlbnQjMjAyNg==" ``` The Base64 value decodes to: ```text login-agent:Agent#2026 ``` ### Technical Analysis The Skill embeds an OAuth Basic Authentication credential directly in its distributed Python source. Base64 is an encoding mechanism, not encryption, so anyone who can read or download the Skill can recover the client identifier and client secret without possessing additional keys. The credential is sent as an HTTP `Authorization: Basic` header to the Virsical OAuth endpoints during: - Refresh-token exchanges - Access-token validation - Authorization-code exchanges Although the requests use the configured HTTPS Virsical endpoint, transport encryption does not protect a secret already exposed in the client package. A distributable Agent Skill cannot reliably maintain the confidentiality of an embedded OAuth client secret. This is also inconsistent with the project's own security guidance in `references/auth_flow.md:154`, which states that a client secret should not be committed to the ...[truncated 1519 chars]
- Remediation
- ## Remediation Suggestions 1. Immediately revoke and rotate the exposed OAuth client credential. 2. Remove the credential from the current source tree and repository history. 3. Do not place replacement secrets in distributable Skill files, environment templates, documentation, command examples, or build artifacts. 4. Prefer an OAuth public-client design using Authorization Code Flow with PKCE, because an installed or distributed client cannot securely retain a client secret. 5. If a confidential client is required, keep the secret in a trusted server-side component and have the Skill interact through a narrowly scoped backend flow. 6. Store deployment-only secrets in an approved secret manager and inject them only into trusted, access-controlled runtime environments. 7. Restrict the OAuth client to the minimum necessary grant types, scopes, redirect URIs, and token lifetimes. 8. Review authentication logs for unexpected use of the exposed client credential and invalidate affected tokens if misuse is detected. 9. Add secret scanning to source-control and release pipelines to prevent recurrence.
