Git recursive clone risk now needs a workflow decision for repositories your team does not trust. Git’s November 10 advisory says a repository hosted by an attacker, rather than a normal forge site, can trigger remote code execution during a recursive clone. As of November 15, Git lists all versions as affected and no patched version.
The project currently believes the flaw can be triggered only when --recurse-submodules is used. Its direct workaround is to avoid cloning repositories from untrusted sources. Teams that automate recursive clones should review those jobs now, then watch the Git project advisory for a fix.
Which Git recursive clone risk needs action now?
Git says a crafted, attacker-hosted repository can cause a submodule gitfile to be overwritten with a symbolic link. That link can point toward a directory with attacker-specified configuration or hooks, which may contain code. The advisory identifies the recursive clone option as the current trigger condition; it does not describe ordinary clones as exposed in the same way.
The advisory rates CVE-2026-111760 High, with a CVSS 3.1 score of 8.0. It lists no CVSS 4.0 score. This alert focuses on the decision a repository owner makes before cloning; the separate vulnerability profile will cover the flaw and affected scope when published.
| Git advisory field | Status on November 15, 2026 |
|---|---|
| Affected versions | All |
| Patched versions | None listed |
| Interim control | Avoid cloning untrusted sources; review recursive clone use |
What should repository and CI owners change?
Start by locating scripts, CI jobs and developer instructions that run recursive clones against external repositories. Record which source can be changed by an outside party and who approves it. Put that decision in your software supply chain security workflow. This inventory is our operational recommendation drawn from Git’s stated trigger, not a separate claim from the Git project.
For untrusted sources, defer the recursive clone while the project discusses patches. Where work must continue, make source approval an explicit owner decision and document the exception. A vulnerability intelligence platform can help track the advisory alongside affected workflows, while Git and repository owners remain the authority for release and exposure decisions.
- Find recursive clone jobsInclude CI, build scripts and developer instructions.
- Identify repository trustRecord who controls the source and who approves it.
- Pause untrusted recursive clonesRevisit exceptions with a named owner.
- Track the Git advisoryVerify a released fix before changing the policy.
Review recent use of the recursive option in automated jobs and ask owners whether a source came from an attacker-controlled host. Treat that review as a scoping step, not as proof of compromise. Use the patch management workflow to record the pending fix and the person responsible for checking it.
How should teams weigh public attention?
- Brandefense BlackholeYes6 matching dark-chat items, August 17 to November 15, 20262026-11-15
- GitHub repository searchYes3 repositories naming the CVE, contents unvalidated2026-11-15
- CISA KEVNot seenNot listed in catalog 2026.11.132026-11-13
Brandefense Blackhole counted six matching dark-chat items about CVE-2026-111760 from August 17 through November 15, 2026. The unit is matching chat items, and the count can overlap with other source sets. It shows discussion around the CVE, not a confirmed incident or proof of active exploitation.
A GitHub repository search on November 15 returned three public repositories whose names match the CVE. The unit is repository search results; their contents were not validated as working exploit code. CISA’s November 13 KEV catalog version did not list the CVE, which is a dated catalog observation rather than an exposure verdict.
Git says patches were still under discussion when its advisory was checked on November 15. Assign an owner to recheck the advisory and any subsequent release notes before scheduling an update. Until a fixed version exists, the practical control is the decision to avoid recursive cloning of untrusted repositories.
Frequently Asked Questions
Should teams stop every Git clone?
Git currently believes the flaw can be triggered only with the recursive submodule option. Its workaround is to avoid cloning repositories from untrusted sources.
Is a fixed Git version available?
The Git advisory listed no patched version when checked on November 15, 2026. Git said patches were under discussion.
What should a CI owner check first?
Locate jobs that recursively clone external repositories, identify who controls each source and decide whether untrusted jobs should pause pending a fix.
