T05 · Unauthorized Access and Privilege Escalation
Warning
- Location
- SKILL.md:49
- Finding
- Overprivileged GitHub Personal Access Token Requirement## Vulnerability Details **File Location**: `SKILL.md:49-54` **Additional Location**: `README.md:23-31` **Vulnerability Type**: Excessive credential privileges **Risk Level**: Medium **Vulnerable Code/Configuration Snippet**: ```markdown 1. Go to https://github.com/settings/tokens 2. Click "Generate new token (classic)" 3. Name: `openclaw-github-skill` 4. Scopes: `repo` (required), `read:user` (optional) 5. Copy the token ``` The README further describes the requested permission as follows: ```markdown 4. Scopes (permissions): - `repo` — Full control of private repositories - `public_repo` — Limited access to public repositories only - `read:user` — Read user profile data (optional) ``` ### Technical Analysis The setup instructions direct users to create a classic GitHub personal access token with the broad `repo` scope. That scope provides extensive control over all private repositories accessible to the user, while the Skill's declared operations are limited to reading repository information, reading commits and CI status, creating issues, creating repositories, and creating pull requests. The implementation automatically reads this token from `process.env.GITHUB_TOKEN` or `context.config.github.token` and attaches it to all GitHub API requests: ```javascript if (process.env.GITHUB_TOKEN) { headers['Authorization'] = `token ${process.env.GITHUB_TOKEN}`; return headers; } const config = context.config?.github || {}; if (config.token) { headers['Authorization'] = `token ${config.token}`; } ``` Requiring a classic `repo` token violates least-privilege principles because the credential authorizes repository operations beyond those exposed by the Skill. Although the audited implementation only sends the credential to the fixed official endpoint `https://api.github.com`, compromise of the Skill process, host environment, OpenClaw configuration, or a future malicious m ...[truncated 1513 chars]
- Remediation
- ## Remediation Suggestions 1. Replace the recommendation for a classic PAT with a fine-grained GitHub PAT restricted to explicitly selected repositories. 2. Document the exact repository permissions required for each action, separating read permissions from write permissions. 3. Offer a read-only configuration for listing repositories, retrieving repository details, checking CI status, searching repositories, and viewing commits. 4. Require users to opt into separate write permissions for issue, repository, and pull-request creation. 5. Consider using separate credentials for repository creation because account-level repository creation may require authority distinct from access to existing repositories. 6. Require explicit user confirmation immediately before write operations. 7. Avoid placing long-lived tokens in broadly inherited process environments where feasible; use the platform's protected credential store. 8. Rotate existing classic PATs after migrating to restricted credentials. 9. Update both `SKILL.md` and `README.md` so the documented permission model consistently reflects least-privilege requirements.