T09 · Insecure Skill Coding Practices
- Location
SKILL.md:32- Finding
Automatic Broad Staging and Commit Without User Confirmation
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:32-47; supporting implementation guidance inreferences/safety-errors.md:19-24andreferences/workflow-examples.md:14-18
Vulnerability Type: Unrestricted staging of repository contents followed by an unconfirmed commit
Risk Level: MediumVulnerable Code
SKILL.md:32-34:markdown 2. **暂存区为空**(`git diff --cached --stat` 无输出) - 先执行 `git add .` 添加所有变更 - 再分析变更内容,生成 commit message 并提交SKILL.md:42-47:markdown 所有操作都会: 1. 确认工作目录是 Git 仓库(非 Git 目录直接报错退出) 2. 检查暂存区状态(有内容→直接提交;无内容→先 git add .) 3. 分析代码变更 4. 生成符合规范的 commit message 5. 直接执行 `git commit -m "<message>"`(不需要用户确认)references/safety-errors.md:19-24:bash # 3. 检查暂存区状态 if [ -z "$(git diff --cached --name-only)" ]; then echo "i️ 暂存区为空,自动执行 git add ." git add . fiTechnical Analysis
When the staging area is empty, the Skill instructs the agent to execute
git add .. This broadly stages all tracked modifications and all non-ignored, untracked files beneath the current repository path. The Skill then executesgit commitwithout requesting user confirmation.This violates least-change principles for source-control automation. A request to commit intended code changes does not necessarily authorize the inclusion of every file in the working tree. The project mentions checking for sensitive information in
references/best-practices.md, but it defines no concrete secret-detection procedure, sensitive-path denylist, staged-file review, or blocking control before the commit.An attacker does not need command execution to exploit this behavior. It is sufficient to place a sensitive or unrelated non-ignored file inside a repository and induce a user to invoke the Skill while the staging area is empty. The file can then become part of permanent Git history.
Attack Path
- A repository contains an untracked or modified file that th ...[truncated 1530 chars]
- Remediation
View remediation
Remediation Suggestions
- Do not run
git add .automatically. Preserve existing user staging decisions whenever possible. - If the staging area is empty, display
git status --shortand require the user to select or approve the exact paths to stage. - Prefer explicit commands such as
git add -- path/to/filefor approved files. If only modifications to already tracked files should be included, considergit add -uafter clearly explaining its scope. - Before committing, display the final output of
git diff --cached --name-statusand require explicit confirmation. - Add blocking checks for common sensitive files and patterns, including environment files, private keys, credential exports, tokens, database dumps, and local configuration files.
- Integrate a recognized secret scanner where available, while treating scanner success as an additional safeguard rather than a replacement for user review.
- Abort when no files are approved, when unresolved conflicts exist, or when secret detection reports a possible credential.
- Avoid committing automatically. Present the proposed commit message and staged-file summary, then execute
git commitonly after informed user approval.
- Do not run