T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:68- Finding
Automatic Remote Pushes Without Explicit Push Authorization
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:58,SKILL.md:68, andSKILL.md:444
Vulnerability Type: Unauthorized remote repository modification
Risk Level: MediumVulnerable Code
SKILL.md:58:markdown - **每轮只刨一个面，信任后升级粒度。** 首轮严格单面，建立信任；用户明确批量授权（"全做""都修了"）后，切换为"单提交单面"——每个提交独立过验证门、提完立刻推送，归因单位从轮降到提交。SKILL.md:68:markdown - **commit 即 push。** 不囤本地提交，每个通过验证的提交立刻推送。SKILL.md:444:markdown 6. **merge到默认分支、打tag发版、任何对真实用户可见的部署**——这三个动作每一次都需要明确授权。These instructions respectively require an immediate push after each validated commit and require explicit authorization for merging, tagging, and deployment, but omit pushing from the protected operations.
Technical Analysis
The Skill treats successful local validation as sufficient authorization to push a commit to a remote repository. However, authorization to edit files or make local commits does not inherently authorize remote publication.
A Git push crosses a local-to-remote trust boundary. It can expose source changes to collaborators, update a shared branch, trigger CI/CD workflows, invoke repository automation, or disclose material accidentally included in a commit. The Skill's separate consent rules recognize this boundary for merges, tags, releases, and deployments, but do not apply the same protection to pushes.
Exploitation is conditional on the executing Agent already having access to valid Git credentials and a writable remote. The Skill does not acquire new credentials or elevate operating-system privileges. Instead, it can cause the Agent to exercise existing repository permissions beyond the scope clearly authorized by the user.
Attack Path
- A user supplies a repository and requests that the Skill review or improve it.
- The Agent modifies files and validates the resulting change.
- The Agent creates a local commit under the Skill's workflow.
- The `commit immediately followed by ...[truncated 1349 chars]
- Remediation
View remediation
Remediation Suggestions
- Separate local commits from remote pushes. Keep validated commits local by default.
- After committing, present the user with the commit hash, changed-file list, diff summary, intended remote, and intended branch.
- Require explicit imperative authorization before every push, identifying the relevant remote and branch.
- Treat pushing, opening a pull request, merging, force-pushing, tagging, releasing, and deploying as separate approval gates.
- Never infer push authorization from broad instructions such as “fix everything,” from authorization to edit files, or from authorization to create local commits.
- Before requesting push approval, scan staged and committed content for credentials, tokens, private paths, environment files, and unexpected binary or generated files.
- Prohibit force-pushes by default and require separate, explicit authorization if they are exceptionally necessary.
- Prefer pushing to a newly created, user-approved feature branch rather than directly updating a shared or default branch.
- Replace the current policy with wording equivalent to:
markdown Create validated commits locally and report their hashes and diff summaries. Do not push any commit until the user explicitly authorizes a specific remote and branch. Authorization to edit, commit, fix multiple issues, open a pull request, merge, tag, release, or deploy does not imply authorization for any other remote action.