T09 · Insecure Skill Coding Practices
- Location
SKILL.md:129- Finding
Published Credentials Remain Exposed in Git History After Incomplete Removal
- Content
View full analysis
Vulnerability Details
File Location:
SKILL.md, lines 129–135
Vulnerability Type: Incomplete remediation of secrets committed to a Git repository
Risk Level: HighComplete vulnerable excerpt, translated into English from the source documentation:
markdown #### Committed Files That Should Not Have Been Committed - **Symptom:** A password file or large dependency library was accidentally uploaded to the repository. - **Solution:** 1. Immediately add the file path to `.gitignore`. 2. Use `git rm --cached <file-name>` to remove it from Git tracking. 3. Commit and push the change: `git commit -m "chore: remove sensitive file"` and `git push`.Technical Analysis
The documented remediation removes the sensitive file only from the repository's current tree. The
git rm --cachedcommand followed by a normal commit does not remove the file or its contents from earlier commits. Anyone with access to the repository history may therefore retrieve the exposed password, API key, token, or other secret.Adding the path to
.gitignoreprevents accidental staging in future commits, but it does not protect a secret that has already been committed or pushed. The instructions also omit the most urgent response step: revoking or rotating the compromised credential. Consequently, the secret may remain both recoverable and operational after the user completes every documented remediation step.Attack Path
- A user stages project contents, potentially through the documented
git add .workflow. - A password file or another credential-bearing file is committed and pushed to GitHub.
- An attacker, collaborator, repository reader, automated crawler, or secret-harvesting service obtains the secret from the exposed commit.
- The user follows the documented remediation by adding the file to
.gitignore, runninggit rm --cached, committing the deletion, and pushing it. - The sensit ...[truncated 1054 chars]
- A user stages project contents, potentially through the documented
- Remediation
View remediation
Remediation Suggestions
Replace the documented response procedure with a complete secret-incident workflow:
- Revoke or rotate the credential immediately. Assume any secret pushed to a remote repository is compromised. Do not wait for history cleanup before invalidating it.
- Remove the secret from repository history. Use a supported history-rewriting tool such as
git filter-repoor an equivalent repository-host procedure to purge the file or sensitive value from every affected branch and tag. - Force-push rewritten references carefully. Coordinate with all collaborators before force-pushing branches and tags. Require collaborators to discard or clean affected clones so the removed history is not accidentally restored.
- Inspect secondary exposure locations. Review forks, mirrors, pull-request references, releases, artifacts, caches, logs, and archived clones. Contact the hosting provider if additional cleanup is required.
- Review credential activity. Inspect authentication and audit logs for unauthorized use from the time of initial exposure until revocation.
- Prevent recurrence. Retain an appropriate
.gitignore, use narrowly scoped staging instead of indiscriminate staging where practical, and review staged content withgit diff --cachedbefore committing. - Add automated controls. Enable repository secret scanning, pre-commit secret detection, push protection, and least-privilege, short-lived credentials.
- Clarify limitations in the skill documentation. Explicitly state that
git rm --cachedremoves a file only from the current tracked tree and is insufficient after a secret has entered Git history.