T05 · Unauthorized Access and Privilege Escalation
- Location
SKILL.md:130- Finding
Automatic Git Push Without Explicit User Authorization
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 130–135 and 364–373
Vulnerability Type: Unauthorized remote repository modification
Risk Level: MediumVulnerable Code
markdown ### 阶段 5：交付（Delivery） 1. Evaluator 确认修复通过 → 状态改为 APPROVED 2. Generator 执行 git commit + push 3. 更新 `summary.md` 为 DELIVERED 状态 4. 向用户报告交付结果markdown ### 完整任务（FULL） 1. 创建变更目录 2. Generator Agent: spec.md + tasks.md 3. Generator Agent: 编码 + coding_report.md + self_review.md 4. Evaluator Agent: code_review_v1.md 5. 如果有 MUST FIX → Generator Agent 修复 → revision_report.md 6. Evaluator Agent: 确认通过 7. git commit + push 8. 更新 summary.mdTechnical Analysis
The FULL delivery workflow makes
git commit + pusha standard mandatory step after evaluator approval. It does not require separate user authorization before the remote write, nor does it require validation of the destination remote, branch, repository ownership, branch protection status, commit contents, or authentication context.A Git push uses credentials already available to the Agent's execution environment. Consequently, the workflow may cross a least-privilege boundary: authorization to edit a local working tree is implicitly treated as authorization to publish those changes remotely. Evaluator approval is a code-quality gate, not evidence that the user authorized a remote repository operation.
Although the lightweight website workflow requires confirmation before implementation, the audited FULL workflow does not define an equivalent confirmation gate immediately before committing and pushing.
Attack Path
- A user requests a coding change sufficiently large to be classified as a FULL task.
- The Agent follows the Skill and modifies the local repository.
- The Generator and Evaluator complete the required review stages.
- The Evaluator marks the change as approved.
- The delivery instructions direct the Generator to execute
git commit + push. - Git uses credentials availab ...[truncated 987 chars]
- Remediation
View remediation
Remediation Suggestions
- Remove automatic
git pushfrom the default delivery workflow. - Require explicit, contemporaneous user approval immediately before any remote write.
- Before requesting approval, present:
- The complete staged diff or a clear diff summary
- The proposed commit message
- The destination repository and remote URL
- The target branch
- Whether the branch is shared or protected
- Any CI/CD or deployment actions expected from the push
- Separate local and remote operations:
- Local edits should be allowed by default.
- A local commit should occur only when requested or clearly authorized.
- A push should require separate explicit authorization.
- Default to a new non-protected feature branch rather than the current branch.
- Prohibit force pushes, tag publication, release creation, and protected-branch writes unless each operation is specifically authorized.
- Validate the remote destination and upstream branch before execution.
- Stop and ask the user if credentials, repository ownership, branch destination, or deployment effects are ambiguous.
- Record the user's approval and the exact pushed commit hash in
summary.md. - Replace the affected workflow step with language such as:
markdown 7. Prepare the proposed commit and report the diff, commit message, remote, and branch. 8. Commit only if authorized by the user. 9. Push only after obtaining separate explicit user approval for the stated remote and branch.- Remove automatic