Michael JohnsonAls u Git in de terminal hebt bijgewerkt, bent u nog niet klaar: afzonderlijke toepassingen en buildomgevingen kunnen een eigen kopie uitvoeren. Op 10 november 2026 bracht het Git-project oplossingen uit voor zes kwetsbaarheden — van code-uitvoering bij recursief klonen tot geheugenbeschadiging bij het samenvoegen. Controleer daarom elke omgeving die repositories of hun inhoud verwerkt, en niet alleen de uitvoer van de opdracht git --version in uw shell.
Wat er in de update is veranderd
De oplossingen zijn opgenomen in Git 2.56.1 en overgezet naar ondersteunde branches: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 en 2.50.2. De update verhelpt zes problemen in verschillende onderdelen van Git, bij het werken met paden, koppelingen, handtekeningen, binaire patches, samenvoegingen en importstromen. GitHub publiceerde op 10 november een analyse van de kwetsbaarheden en het advies om bij te werken; de releaseopmerkingen voor Git 2.56.1 vermelden de CVE’s die in deze reeks zijn verholpen.
In de praktijk betekent dit dat u Git op drie plekken moet bijwerken: op werkcomputers, in automatisering en in toepassingen met een eigen Git-build. Vooral dat laatste punt wordt gemakkelijk over het hoofd gezien: een update van het systeempakket wijzigt niet automatisch de versies in elke client of buildimage.
Waarom recursief klonen aandacht verdient
Het meest inzichtelijke scenario begint met het recursief klonen van een niet-vertrouwde repository. Door afkapping van de padlengte kon een zeer lange invoer onder de ene naam door de controle komen en vervolgens onder een ingekorte naam op schijf belanden. In het beschreven Git-scenario maakte dit het mogelijk om het bestand .git van een submodule te vervangen door een symbolische koppeling naar een map met schadelijke configuratie of hooks. Bij een volgende Git-bewerking kon de code van de aanvaller worden uitgevoerd.
Praktisch gezien gaat het om een speciaal geprepareerde repository en een bijbehorende bewerking. Teams die regelmatig projecten van externe bronnen klonen met de optie --recurse-submodules, doen er goed aan client- en automatiseringsomgevingen met voorrang bij te werken. De oplossing weigert te lange paden voordat hun lengte wordt afgekapt.
Andere plekken waar Git niet-vertrouwde gegevens verwerkt
Een ander probleem doet zich voor bij het klonen van een lege repository via Git protocol v2. De server kon een HEAD-verwijzing doorgeven met een branchnaam die padcomponenten voor maptraversal bevatte; een latere branchupdate kon daardoor een bestand buiten de verwachte verwijzingsmap schrijven. In de gepatchte versies controleert Git dit doel en andere verwijzingsnamen die via het protocol worden ontvangen.
Afzonderlijke kwetsbaarheden troffen samenvoegingen en patches. Bij het verwerken van handtekeningen rekende een vaste array op maximaal twee handtekeningen; een speciaal samengesteld bericht met meer handtekeningen kon een schrijfactie buiten de arraygrenzen en geheugenbeschadiging veroorzaken. Bij het toepassen van een binaire patch controleerde Git de grootte van de oorspronkelijke representatie, hoewel gecomprimeerde gegevens na uitpakken aanzienlijk groter kunnen zijn. Git controleert nu de opgegeven ongecomprimeerde grootte voordat het de gegevens verwerkt.
Ook grote samenvoegingen konden een overflow veroorzaken bij de berekening van de benodigde buffer, gevolgd door een schrijfactie buiten de buffergrenzen. Dit kan onder meer gevolgen hebben voor hostingdiensten en toepassingen die niet-vertrouwde inhoud samenvoegen. Tot slot zijn er beperkingen toegevoegd aan drie mogelijkheden van git fast-import voor opdrachten uit de invoerstroom: rewrite-submodules-from en rewrite-submodules-to konden willekeurige bestanden lezen, terwijl export-pack-edges bestanden kon aanmaken of gegevens aan bestaande bestanden kon toevoegen. Deze mogelijkheden worden nu geblokkeerd tenzij expliciet de optie --allow-unsafe-features is opgegeven; gebruik die alleen voor een vertrouwde stroomgenerator.
Waar u afzonderlijke Git-kopieën kunt vinden
Voor ontwikkelaars is het handig om te beginnen met een inventarisatie van alle plekken waar Git wordt gestart. Controleer de versie in de terminal en gebruik de ingebouwde updatecontrole van IDE’s en desktop-Git-clients. Controleer vervolgens CI-images, containers, runners en servertaken die klonen, samenvoegen, binaire patches toepassen of fast-import uitvoeren. Een recente Git-versie op de host garandeert niet dat een toepassing die versie ook gebruikt.
Organisaties doen er goed aan niet alleen de basisimages te controleren, maar ook de omgevingen die al zijn uitgerold: een permanente runner of interne service kan een oud binair bestand hebben behouden nadat de basisimage is bijgewerkt. Voor GitHub Enterprise Server noemt GitHub de gepatchte versies 3.19.15, 3.20.11, 3.21.9 en 3.22.4. Het bedrijf meldde dat de oplossingen al zijn uitgerold op github.com en GitHub Enterprise Cloud, ook voor opties met dataresidency. Releases van GitHub Desktop en de GitHub Copilot-app met de gepatchte Git-versie worden gecoördineerd; gepatchte versies voor Codespaces en GitHub Actions moeten ook nog verschijnen.
Hoe u het risico vóór de update verkleint
Als u de oplossing niet meteen kunt installeren, beperk dan tijdelijk bewerkingen met niet-vertrouwde gegevens: kloon repositories alleen vanaf vertrouwde servers, vermijd recursief klonen van niet-gecontroleerde projecten, voeg hun inhoud niet samen en pas geen binaire patches of fast-import-stromen toe die daaruit afkomstig zijn. Deze maatregelen beperken blootstelling aan de specifieke kwetsbare scenario’s, maar vervangen de update niet.
De belangrijkste praktische conclusie is eenvoudig: zoek de Git-oplossing op de plekken waar een programma Git daadwerkelijk uitvoert. De opdracht in de terminal is maar één zo’n plek; ontwikkelclients, CI en services die repositories verwerken moeten afzonderlijk worden gecontroleerd.
