T09 · Insecure Skill Coding Practices
- Location
scripts/dev_janitor.py:84- Finding
Repository-controlled Git configuration can execute commands during scanning
- Content
View full analysis
Vulnerability Details
File Location:
scripts/dev_janitor.py, lines 84–96
Vulnerability Type: Command execution through untrusted Git repository configuration
Risk Level: HighVulnerable Code
python def git_state(repo): """(dirty, n_stashes, unpushed_branches, has_remote)""" def git(*args): try: r = subprocess.run(["git", "-C", str(repo), *args], capture_output=True, text=True, timeout=10) return r.stdout if r.returncode == 0 else "" except Exception: return "" status = git("status", "--porcelain")Technical Analysis
The scanner recursively discovers Git repositories and automatically executes
git statuswithin each one. Althoughsubprocess.runcorrectly uses an argument array and does not invoke a shell, Git is itself an extensible command runner.Repository-local Git configuration can define executable helpers such as
core.fsmonitor. Operations includinggit statusmay invoke those helpers while inspecting the worktree. Consequently, treating a discovered repository as passive data is unsafe when its metadata may have been supplied or modified by an independent party.The Skill explicitly supports broad scans of home directories, inherited machines, build servers, and collections of repositories. In these workflows, repository contents and
.git/configcannot necessarily be assumed trustworthy. The implementation does not validate repository ownership or provenance, disable executable Git features, or isolate Git in a sandbox.The path passed to Git is not vulnerable to ordinary shell metacharacter injection because arguments are supplied without
shell=True. The vulnerability instead arises from Git interpreting attacker-controlled repository configuration and launching a configured helper.Attack Path
- An attacker supplies, modifies, or leaves behind a Git reposito ...[truncated 1499 chars]
- Remediation
View remediation
Remediation Suggestions
- Do not run normal Git worktree operations against repositories of unknown provenance without isolation.
- Execute repository inspection in a sandbox that denies network access, restricts filesystem access to the repository, and prevents access to user credentials.
- Override executable Git configuration for every invocation, including disabling
core.fsmonitorand other helper mechanisms rather than relying on the user's global configuration. - Use a controlled environment with a minimal
PATH, sanitized Git-related environment variables, and isolated global/system Git configuration. - Validate that repositories and their metadata are owned by the expected user before invoking Git. Treat ownership checks as defense in depth, not as a substitute for disabling executable helpers.
- Where practical, inspect required repository metadata directly with a non-executing parser instead of invoking Git commands that process worktree configuration.
- Document that scanning inherited or externally supplied repositories requires sandboxing until the executable-helper exposure is removed.
