T09 · Insecure Skill Coding Practices
- Location
SKILL.md:88- Finding
Unrestricted Git Staging and Remote Publication
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md:88-93
Vulnerability Type: Unsafe repository modification and remote publication
Risk Level: HighVulnerable Code
bash git add . git commit -m "fix: resolve CI failures" git pushTechnical Analysis
The Skill directs the Agent to stage every changed and untracked file in the working tree with
git add ., create a commit, and publish it to the configured remote repository.This behavior exceeds the minimum privileges required for the declared code-review functionality. The workflow does not require:
- Explicit user authorization before committing or pushing
- An allowlist of files intentionally modified during remediation
- Review of the staged diff
- Secret or credential scanning
- Verification of the destination remote and branch
- Confirmation immediately before remote publication
Because
git add .operates on the entire working tree, it can include unrelated source changes, local configuration files, credentials, generated artifacts, or proprietary data that happen to be present. The subsequentgit pushtransmits the resulting commit over the network.No evidence indicates deliberate exfiltration or a malicious payload; however, the unsafe publication workflow creates a practical disclosure and integrity risk.
Attack Path
- A repository contains an unrelated changed or untracked file, such as a local configuration file containing a credential.
- The Agent invokes the Skill while handling a failed CI check on an Agent-owned pull request.
- The Agent applies a repair and follows the documented publication workflow.
git add .stages both the intended repair and the unrelated sensitive file.- The Agent creates a commit without reviewing the complete staged file set.
git pushpublishes the commit to the configured remote repository.- Anyone with access to that repository may retrieve the unintentionally committed information, and the data may remain a ...[truncated 933 chars]
- Remediation
View remediation
Remediation Suggestions
- Keep code-review operation read-only by default. Do not modify, commit, or push unless the user explicitly requests remediation and publication.
- Replace
git add .with explicit staging of only the reviewed files, for example:bash git add -- path/to/reviewed-file - Display and inspect the staged changes before committing:
bash git diff --cached --name-status git diff --cached - Run an appropriate secret scanner against the staged content and stop if credentials or sensitive files are detected.
- Verify the active branch and destination remote before publication:
bash git branch --show-current git remote -v - Require explicit user confirmation after presenting the exact staged diff, destination remote, and branch.
- Do not push automatically. Provide the proposed command to the user or require a separate, clearly authorized publication step.
- Respect branch-protection rules and prefer creating a dedicated remediation branch rather than directly modifying a protected or shared branch.
- If sensitive information has already been published, revoke and rotate affected credentials, remove the data from Git history using an appropriate history-rewriting procedure, and coordinate repository cleanup with administrators.