Git wordt wekelijks in diverse omgevingen gebruikt: van CI/CD tot developer laptops. Nu is er een specifieke Git 2.56.1 kwetsbaarheid bekend waarbij een kwaadaardige repository tijdens het recursief clonen met submodules code kan laten uitvoeren op de machine die de clone verwerkt. Het is precies het soort scenario waar teams liever niet op wachten: zodra je een niet-vertrouwde repo automatisch verwerkt, kan de schade al zijn gebeurd vóór je het doorhebt.
In dit artikel zetten we de kern van het probleem op een rij, welke versies zijn bijgewerkt, waarom submodules ertoe doen, en welke tijdelijke maatregelen je kunt nemen tot de fix ook bij jouw tooling beschikbaar is.
Wat is de Git 2.56.1 kwetsbaarheid?
De kwetsbaarheid die deze update adresseert is geregistreerd als CVE-2026-111760. De fout zit in hoe Git een integer truncation verwerkt in de manier waarop het systeem met de index omgaat.
Concreet kan een extreem lang pad uit een repository de interne veiligheidscontrole passeren. Daarna schrijft Git dat pad echter weg naar disk onder een ingekorte naam—en juist dat verschil tussen controle en opslag opent de deur voor misbruik.
Hoe kan een attacker code laten draaien?
Het misbruik draait om het manipuleren van de manier waarop Git met submodules omgaat. In de kwetsbare situatie kan een aanvaller een submodule-.git-verwijzing vervangen door een symbolic link die wijst naar een map die kwaadaardige hooks of configuratie bevat.
Hooks zijn programma’s die Git op specifieke momenten uitvoert. Zodra Git de aangepaste map gebruikt, krijgt de aanvaller de mogelijkheid om zijn code te laten draaien binnen het proces dat de clone afhandelt.
Waarom is dit extra relevant? Omdat Git bij submodules anders omgaat met .git-structuren: Git weigert namelijk om een .git-folder direct te vervangen door een symbolic link, maar bij een vers gekloonde submodule is .git een bestand. Dat verschil maakt het aanvalspad haalbaar.
Welke versies zijn gepatcht?
De fixes zijn deze week door het Git-project uitgebracht. De belangrijkste versie is Git 2.56.1. Daarnaast zijn er ook patches uitgebracht voor oudere onderhoudslijnen, zodat je niet per se tot de allerlaatste major release hoeft te gaan.
De update is beschikbaar gemaakt voor de reeksen 2.50 t/m 2.55 met bijpassende versies: 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1 en 2.55.1.
De Git-releasenotities geven aan dat de aangepaste versies extreem lange paden niet meer accepteren voordat de lengte kan worden teruggebracht tot iets dat een attacker kan sturen.
GitHub en andere distributies: wat is er al gedaan?
GitHub heeft de fix al toegepast voor github.com en GitHub Enterprise Cloud. Voor GitHub Enterprise Server zijn de relevante versies genoemd: 3.19.15, 3.20.11, 3.21.9 en 3.22.4.
Daarnaast is aangegeven dat GitHub Desktop en de GitHub Copilot-app de fix voorbereiden. GitHub Codespaces en GitHub Actions krijgen ook bijgewerkte Git-versies.
Voor Git for Windows gold op het moment van de controle dat er nog geen release-tag werd gezien die direct op Git 2.56.1 was gebaseerd. Dat betekent: controleer niet alleen je besturingssysteem, maar ook de Git-versie die daadwerkelijk door je tooling wordt gebruikt.
Ook nog meerdere andere Git-fixes
Naast CVE-2026-111760 zijn er in de Git-releases nog vijf andere kwesties opgelost. Voor het team dat verantwoordelijk is voor patchmanagement is dit belangrijk, omdat één update meerdere risico’s kan verlagen.
- CVE-2026-113408: bij het klonen van een leeg repository via Git protocol v2 kan een kwaadwillende server een branchnaam met path traversal sturen; een latere update kan dan buiten de Git reference-map schrijven.
- CVE-2026-114467: bij het mergen van een tag met meer dan twee GPG-handtekeningen kan Git stack memory beschadigen en een denial of service veroorzaken.
- CVE-2026-114469: een binary patch die sterk uitzet kan voorbij de patchgroottelimiet (ongeveer 1 GiB) gaan en Git laten crashen via een out-of-bounds read.
- CVE-2026-105437: een erg grote merge met veel conflicts en een groot conflict-marker-size attribuut kan ervoor zorgen dat Git voorbij het einde van een te kleine buffer schrijft en heap memory aantast.
- CVE-2026-114466: drie git fast-import features konden worden misbruikt om arbitraire bestanden te lezen of bestanden te maken en gegevens toe te voegen. Git gaat die input nu weigeren, tenzij een expliciete vlag wordt gebruikt (–allow-unsafe-features).
Voor CVE-2026-105437 gaf GitLab aan dat code-hosting servers waarschijnlijk worden geraakt via git merge-tree. Servers kunnen dat command uitvoeren om te bepalen of een pull of merge request kan worden gemerged.
Tijdelijke maatregelen zolang je niet kunt updaten
Een update installeren is de beste route. Maar als je nog niet direct kunt patchen—bijvoorbeeld vanwege governance, validatie-omgevingen of vendor-updates—dan helpen onderstaande maatregelen om de blootstelling te verlagen.
GitHub adviseert om, totdat de fix is geïnstalleerd, onder meer:
- alleen te clonen vanaf servers die je vertrouwt;
- geen recursieve clones te doen van repositories die je niet vertrouwt;
- geen content of tags te mergen die je niet vertrouwt;
- geen binary patches of fast-import streams te verwerken van onbetrouwbare bronnen.
Daarnaast worden er voor een server-side workaround twee opties genoemd voor situaties waarin upgraden niet direct kan:
- voor elk repository een instelling toevoegen: conflict-marker-size=7 in het bestand info/attributes;
- of merge-checks voor niet-vertrouwde repositories uitschakelen.
Wat betekent dit voor jouw dagelijkse workflow?
Veel organisaties clonen automatisch: via CI pipelines, dependency bots of interne tooling die pull requests beoordeelt. De kernvraag wordt dan: kan een aanvaller een repository afdwingen die jouw omgeving recursief clonet of submodules verwerkt?
Concreet helpt het om in je proces afspraken te maken over betrouwbaarheid en beperkingen, zoals:
- beperk recursieve cloning (met submodules) tot gecontroleerde bronnen;
- zorg dat agents/CI-runners steeds de nieuwste Git-versie gebruiken;
- log welke Git-versie in elke pipeline wordt gestart, zodat je patchstatus aantoonbaar is.
Als je software supply chain en transparantie al gebruikt (bijvoorbeeld met SBOM/VEX), dan kun je dit soort Git-updates ook koppelen aan je “known fixed versions”-registratie. Voor achtergrond over transparantie in de supply chain kun je bijvoorbeeld ook kijken naar software transparency: SBOM, AI BOMs en VEX uitgelegd.
Snelle checklist voor beveiligingsteams
Wil je vandaag al actie ondernemen? Gebruik dan deze korte checklist.
- Inventariseer welke Git-versie je gebruikt in desktops, CI, containers en Git-gerelateerde tooling.
- Prioriteer omgevingen die recursief clonen met submodules doen (of waar submodule verwerking automatisch loopt).
- Update naar Git 2.56.1 of de bijpassende onderhoudsversies voor jouw releasebranch.
- Beperk verwerking van niet-vertrouwde content (clonen, mergen, patches, fast-import streams).
- Controleer server-side merge-checks en instellingen rond conflict-marker-size waar een workaround mogelijk is.
Conclusie
De Git 2.56.1 kwetsbaarheid (CVE-2026-111760) laat zien hoe complex “repository processing” kan worden: een lange padwaarde, een index-afhandeling en het gedrag rondom submodules leiden samen tot een route voor code-uitvoering via kwaadwillende hooks. Omdat dit risico vooral speelt zodra je onbetrouwbare repositories (recursief) verwerkt, is snel patchen de belangrijkste stap.
Heb je nog niet kunnen updaten? Zet dan direct de tijdelijke beschermingsmaatregelen in, tot de fix ook bij jouw OS, distributies en CI-tools beschikbaar is.
Bron: https://thehackernews.com/2026/11/git-patches-flaw-that-lets-malicious.html
