T09 · Insecure Skill Coding Practices
- Location
scripts/auth_manager.py:218- Finding
Hardcoded OAuth Client Credential in Distributed Source Code
- Content
View full analysis
Vulnerability Details
File Location:
scripts/auth_manager.py:218-231, with repeated use atscripts/auth_manager.py:302-311andscripts/auth_manager.py:391-409
Vulnerability Type: Hardcoded OAuth client credential
Risk Level: MediumVulnerable 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#2026Technical 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: Basicheader 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
View remediation
Remediation Suggestions
- Immediately revoke and rotate the exposed OAuth client credential.
- Remove the credential from the current source tree and repository history.
- Do not place replacement secrets in distributable Skill files, environment templates, documentation, command examples, or build artifacts.
- Prefer an OAuth public-client design using Authorization Code Flow with PKCE, because an installed or distributed client cannot securely retain a client secret.
- 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.
- Store deployment-only secrets in an approved secret manager and inject them only into trusted, access-controlled runtime environments.
- Restrict the OAuth client to the minimum necessary grant types, scopes, redirect URIs, and token lifetimes.
- Review authentication logs for unexpected use of the exposed client credential and invalidate affected tokens if misuse is detected.
- Add secret scanning to source-control and release pipelines to prevent recurrence.