GHSA-9ccr-r5hg-74gf
HIGHGHSA-9ccr-r5hg-74gf is a high-severity (CVSS 7.8) CWE-696 vulnerability in @github/copilot. O3 Security confirms whether GHSA-9ccr-r5hg-74gf is actually reachable in your code before you act, and blocks exploitation at runtime until you patch.
GitHub Copilot CLI: Nested Bare Repository Can Execute Arbitrary Commands via core.fsmonitor
Real-World Exposure
@github/copilotReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects npm packages — download data is not available via public APIs for these ecosystems.
Description
Summary
A security vulnerability has been identified in GitHub Copilot CLI where a malicious bare git repository nested inside a project directory can achieve arbitrary code execution when the agent performs git operations. By exploiting git's automatic bare repository discovery during directory traversal, an attacker can set core.fsmonitor or other executable config keys to run arbitrary commands without user awareness or approval.
Details
Git supports bare repositories — repositories without a working tree — which can be discovered automatically when git traverses the directory hierarchy looking for a .git directory. When git discovers a bare repository, it reads and applies its configuration, including keys that specify external commands to execute.
The vulnerability arises because git's core.fsmonitor config key (and 15+ similar keys such as core.hookspath, diff.external, merge.tool, etc.) can specify arbitrary shell commands that git will execute as part of normal operations like status, diff, or rev-parse.
Attack Scenario
An attacker can exploit this by:
- Creating a bare git repository nested inside a seemingly normal project directory (e.g.,
vendor/malicious.git/or a deeply nested subdirectory) - Configuring
core.fsmonitor(or similar keys) in that bare repository to execute a malicious command - When GitHub Copilot CLI performs any git operation that traverses into or through that directory, git auto-discovers the bare repository, reads its config, and executes the attacker's command
This can occur when:
- The agent navigates into a subdirectory containing the buried bare repo
- The agent runs
git status,git diff, or other routine git commands - The agent uses tools like
greporglobthat may trigger git operations in subdirectories
Prior to the fix, the CLI had no protection against git auto-discovering bare repositories during directory traversal.
Impact
An attacker who can place a malicious bare repository inside a project — for example, through:
- A pull request adding a directory that contains a bare repository
- A compromised or malicious dependency that includes a bare repository
- A cloned repository that already contains nested bare repositories
— could achieve arbitrary code execution on the user's workstation whenever GitHub Copilot CLI performs git operations in or near the malicious directory.
Successful exploitation could lead to data exfiltration, credential theft, file modification, or further system compromise.
Affected Versions
- GitHub Copilot CLI versions prior to 1.0.42
Remediation and Mitigation
Fix
The fix sets safe.bareRepository=explicit via git's GIT_CONFIG_COUNT / GIT_CONFIG_KEY_* / GIT_CONFIG_VALUE_* environment variable mechanism, which has the highest precedence over all config file sources. This prevents git from automatically discovering and using bare repositories during directory traversal — only explicitly allowlisted bare repositories will be used.
User Actions
- Upgrade GitHub Copilot CLI to 1.0.43 or later.
- Exercise caution when working in repositories that contain nested bare git repositories.
- Review project directories for unexpected bare repositories, especially in
vendor/,third_party/, or deeply nested subdirectories.
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 📦npm | @github/copilot | all versions | 1.0.43 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for @github/copilot. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
Update @github/copilot to 1.0.43 or later, then make sure no transitive (indirect) dependency still pins the vulnerable range — O3 confirms GHSA-9ccr-r5hg-74gf is resolved across your whole dependency graph.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-9ccr-r5hg-74gf is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-9ccr-r5hg-74gf. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-9ccr-r5hg-74gf in your dependencies?
O3 detects GHSA-9ccr-r5hg-74gf across npm dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.