Git: which client received the fix before checkout?
A Git update needs to reach the client that actually retrieves the code. This analysis proposes evidence for workstations, applications and runners following the recursive-clone fix.
Lire en portugaisBy Pentesty
The decision starts with acquiring code
On November 10, the GitHub announcement presented six Git security fixes. In CVE-2026-111760, submodule metadata can point to malicious configuration or hooks, allowing code execution during a recursive clone. The advisory describes an attacker-hosted repository and says the maintainers believe triggering requires --recurse-submodules.
The release notes identify 2.56.1 and backports 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 and 2.50.2. They document released fixes; when checked, the advisory’s patched-versions field still said none.
Assign an owner to each executable
Organize the inventory around actual operations: a developer terminal, graphical application, approved extension, integration job and service that accepts repositories. For each case, record the owner and the observed executable path. An answer collected in a different terminal does not automatically describe the process being assessed.
Connect the reported version to its package, distributor or approved image. When a vendor applies a fix without adopting the upstream version number, retain the corresponding distribution advisory. The record should let another person check the relationship between the identified installation and the fix, without relying on the memory of whoever made the change.
Review the checkout contract
Select a representative workflow and trace code acquisition through the submodule destinations. Record the revision, checkout configuration, execution identity and intended network permissions. Review shared pipeline templates as well; the repository visible to a developer may not reveal every option that automation uses when it retrieves the project.
Make each additional destination an explicit decision for the workflow owner. If its origin or the need for recursion is unclear, resolve that issue before approval. Authorization for the primary server should have a defined scope, supported by records of the destinations reviewed and any exceptions granted.
Connect the change to the observed process
Plan the update with the owner of each installation or image. Define an initial sample, the expected evidence and when to stop deployment if incompatibilities arise, before expanding delivery. Retain the previous and subsequent identifiers, together with the procedure approved for the product or distributor used in that environment.
After the change, repeat collection inside the job or application context. Check the executable path and version against the delivered package or image identifier. For service assessments, our analysis of running OpenSSL libraries also explains why the observed execution context belongs in the evidence.
Test compatibility with an owned project
Prepare a team-owned repository containing an ordinary submodule, fictional content and reviewed destinations. In an isolated, authorized environment, perform the expected checkout using a synthetic identity without production credentials. Compare files, revisions and job outcome with the approved procedure, retaining the identity of the client used for that run.
This exercise checks workflow compatibility. A successful clone does not demonstrate that the vulnerability is fixed; that conclusion requires evidence of the corresponding release or package. For subsequent stages, the analysis of project opening and building helps define a separate assessment with its own tasks and permissions.
Close by coverage, keeping exceptions visible
Approval should bring together the covered contexts, their owners, fix evidence and functional results. For outstanding installations, document acquisition restrictions, the reason, deadline and exception owner. Check enforcement with benign allowed and denied cases, also recording gaps in observation rather than treating configuration intent as a complete result.
Keep investigation and updating as separate decisions. If unexpected execution is suspected, preserve records and refer the analysis to the incident-response owner. The maintenance ticket should state exactly what was updated; it should not use that fact to conclude whether prior access occurred or which credentials were used.
Frequently asked questions
Does every Git clone execute attacker code?
That is not the described condition. The advisory identifies an attacker-hosted repository and qualifies triggering as associated with recursive cloning.
Does updating the terminal complete the inventory?
Check every identified context. Applications and jobs should have their own evidence of the executable, package or image actually in use.
Does a normal checkout demonstrate the fix?
It demonstrates the functional outcome of that scenario. The fix needs to be associated with official releases or the applicable distributor advisory.
Can temporary restrictions replace the update?
Treat restrictions as a temporary decision with an owner and deadline. Keep the installation outstanding until fix evidence is obtained and checked.
Sources and references
- The Hacker News: editorial reference, November 10, 2026
- GitHub: six Git fixes, November 10, 2026
- Git project: CVE-2026-111760 prerequisites
- Git project: release 2.56.1 and patched maintenance versions
Original Pentesty analysis, published November 10, 2026. The proposed scenarios are editorial guidance, with scope and validation to be defined for each environment.