T09 · Insecure Skill Coding Practices
Warning
- Location
- SKILL.md:24
- Finding
- Plaintext Storage of an Overprivileged GitHub Access Token## Vulnerability Details **File Location**: `SKILL.md`, lines 24–48 **Vulnerability Type**: Plaintext sensitive credential storage and excessive token permissions **Risk Level**: Medium ### Vulnerable Code Snippet ```markdown **Token permission requirements:** - `repo` - Full repository operations - `read:user` - Read user information - `workflow` - GitHub Actions operations ``` ```json { "env": { "GITHUB_TOKEN": "ghp_xxxxxxxxxxxx" } } ``` ### Technical Analysis The Skill instructs users to persist a GitHub personal access token directly in `~/.openclaw/openclaw.json`. Although the displayed token is a placeholder rather than an exposed live credential, following this configuration pattern places the actual token in a plaintext file. The requested classic-token scopes are also broad. The `repo` scope may provide read and write access to private repositories, while `workflow` permits GitHub Actions workflow operations. These permissions are prescribed globally rather than being limited to the repositories and operations required for a particular task. The documentation does not require restrictive file permissions, token expiration, repository restrictions, secret-manager integration, or fine-grained permissions. Consequently, another local user or process, an insecure backup, or an accidentally published configuration could disclose a reusable and highly privileged credential. ### Attack Path 1. A user follows the documented instructions and writes a real GitHub token into `~/.openclaw/openclaw.json`. 2. A local process, another user with file access, an untrusted plugin, a backup system, or an accidentally committed configuration obtains the plaintext token. 3. The attacker extracts the `GITHUB_TOKEN` value and uses it to authenticate to the GitHub API. 4. The attacker performs operations allowed by the token's scopes and repository authorization. 5. Depending on the token's effective access, the attacker reads private repository content, mo ...[truncated 921 chars]
- Remediation
- ## Remediation Suggestions 1. Replace classic broadly scoped personal access tokens with fine-grained GitHub tokens. 2. Restrict each token to the minimum required repositories and operations. 3. Request permissions per use case instead of prescribing `repo` and `workflow` globally. 4. Store credentials in an operating-system keychain or dedicated secret manager and inject them only at runtime. 5. If file-based storage is unavoidable, require owner-only file permissions, such as mode `0600`, and ensure the configuration is excluded from version control and insecure backups. 6. Use short token expiration periods and establish regular rotation and immediate revocation procedures. 7. Document how users can verify the token's effective repository access and permissions before use. 8. Avoid printing tokens in command output, logs, diagnostics, or error messages.