T09 · Insecure Skill Coding Practices
- Location
SKILL.md:103- Finding
Overbroad staging and remote publication of repository changes
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:103-106
Vulnerability Type: Overbroad Git staging followed by a remote push
Risk Level: Mediumbash git add . git commit -m "fix: resolve CI failures" git pushTechnical Analysis
When repairing CI failures on a pull request owned by the user, the Skill instructs the Agent to stage the entire working tree with
git add ., create a commit, and push it to the configured remote repository.git add .does not limit the commit to files intentionally changed during the repair. It can stage unrelated modifications and untracked files beneath the current working directory, including local configuration, unfinished work, generated artifacts, or files containing credentials. The workflow does not require the Agent to:- Stage only the files modified for the repair.
- Inspect the staged diff before committing.
- Scan the staged content for secrets.
- Verify the destination remote and branch.
- Obtain explicit user approval before publishing the commit.
The subsequent
git pushcrosses a local-to-remote trust boundary. This exceeds the minimum permissions necessary for code review, which ordinarily requires only read access. Even when automated repair is requested, unrestricted staging and publication grant broader write and network capabilities than necessary.Attack Path
- A repository working tree contains an unrelated modified or untracked file, such as a local configuration file with credentials.
- The Skill identifies a CI failure in a pull request treated as belonging to the user.
- The Agent edits one or more files to repair the CI failure.
- The Agent follows the documented
git add .instruction, staging both the intended repair and unrelated files. - The Agent commits the complete staged set without a mandatory staged-diff or secret review.
- The Agent runs
git push, publishing all committed content to the configured re ...[truncated 948 chars]
- Remediation
View remediation
Remediation Suggestions
-
Replace
git add .with explicit staging of only the files intentionally modified for the repair:bash git add -- path/to/modified-file -
Require inspection of both unstaged and staged changes before committing:
bash git status --short git diff git diff --cached -
Run an approved secret scanner against the staged content and stop if credentials or sensitive files are detected.
-
Verify the destination before any publication:
bash git remote -v git branch --show-current -
Require explicit user confirmation before creating a commit or running
git push. Code review should default to reporting findings or producing a local patch rather than modifying the remote repository. -
If automated modification was expressly requested, use a narrowly scoped workflow:
- Record the initial working-tree state.
- Modify only approved files.
- Stage explicit paths.
- display the staged diff to the user.
- Commit only after approval.
- Push only to an approved remote and branch.
-
Document recovery procedures for accidental disclosure, including immediate credential revocation, secret rotation, removal from the current tree, and Git-history remediation where appropriate.
-
