Wat de Git-beveiligingsupdate van november betekent voor engineeringteams

Een beveiligingsupdate voor Git is makkelijk te missen, omdat Git vaak op meer plekken staat dan alleen op de laptop van een ontwikkelaar. Op 10 november 2026 kondigde het Git-project oplossingen aan voor zes kwetsbaarheden rond recursieve clones, referenties, merges, binaire patches en imports. De praktische taak: vind elke Git-installatie waarop je vertrouwt, werk die bij en controleer het resultaat.

De oplossingen betreffen onder andere het uitvoeren van willekeurige code bij het recursief clonen van een kwaadaardige repository, schrijven naar onbedoelde bestanden en geheugencorruptie bij het verwerken van merges of binaire patches. Dat zijn verschillende bewerkingen. Het betekent niet dat iedere gewone clone kwetsbaar is. Het risico hangt af van het geraakte codepad, de Git-versie en de vraag of een applicatie onbetrouwbare repositories verwerkt.

Wat het beveiligingsbericht meldt

Het Git-project bracht gepatchte releases uit in meerdere onderhoudsreeksen: 2.56.1, 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 en 2.50.2. Het advies is Git 2.56.1 te installeren of de gepatchte versie van de onderhoudsreeks die je gebruikt. De aankondiging noemt ook applicaties waarin Git is ingebouwd. Die zijn makkelijk te vergeten wanneer je alleen de pakketbeheerder van een laptop controleert.

De inventaris is dus groter dan de laptops van ontwikkelaars. Git kan onderdeel zijn van IDE’s, CI-runners, build-images, deploysystemen, desktopsoftware en servers die repositories verwerken. Een vastgezette container-image kan een oude Git-versie blijven gebruiken, ook nadat het hostsysteem is bijgewerkt.

Een kort en bruikbaar stappenplan

1. Vind versies en eigenaren. Controleer laptops, zelf gehoste runners, build-containers, IDE-integraties en producten waarin Git is ingebouwd. Noteer welk team verantwoordelijk is.
2. Werk bij via de ondersteunde bron. Volg het proces van het besturingssysteem, de leverancier of het imagebeheer. Controleer voor ingebouwde Git ook de release-informatie van de applicatie.
3. Vernieuw onveranderlijke images. Bouw container- en runner-images opnieuw en rol ze uit. Het hostsysteem bijwerken verandert een bestaande image niet.
4. Controleer services die repositories verwerken. Accepteert een service onbetrouwbare repositories of voert die namens gebruikers clone-, merge-, import- of patchbewerkingen uit? Bevestig dan dat het Git-proces is bijgewerkt voordat er nieuw werk wordt verwerkt.
5. Controleer de omgeving zelf. Voer de versiecontrole uit op de plek waar het werk gebeurt en bekijk daarna de image of runner die is uitgerold. Een bijgewerkte laptop bewijst niet dat CI ook is bijgewerkt.

Houd de reactie proportioneel. Een releasebericht is aanleiding om de betrokken tool te inventariseren en bij te werken, geen bewijs dat een repository al is gecompromitteerd. Heeft een Git-service kwaadaardige invoer verwerkt met een getroffen release, volg dan het incidentproces en beoordeel de logs en blootstellingsperiode van dat systeem.

Maak de volgende toolchain-update eenvoudiger

Een duurzame oplossing is een beheerde inventaris van ontwikkel- en buildtools. Zet basis-images vast, leg versies van onderdelen vast en bouw images volgens een voorspelbaar schema opnieuw. Neem ingebouwde tools mee in dependencyreviews; ze staan niet altijd in een lockfile van een programmeertaal.

In CI kan een eenvoudige controle verouderde versies zichtbaar maken: schrijf git --version naar het joblog en vergelijk die met de afgesproken minimumversie. Beheer die controle samen met de image, zodat de verwachte versie meeverandert wanneer de image wordt vernieuwd. Het vervangt updates niet, maar laat wel zien welke runners zijn achtergebleven.

De aankondiging van het Git-project en de lijst met gepatchte releases zijn de primaire bronnen voor de betrokken versies. Controleer het bericht opnieuw voordat je de herstelactie afrondt, vooral wanneer je besturingssysteem beveiligingspatches terugport zonder het upstream-versienummer zichtbaar te wijzigen.

Bronnen: GitHub Security · Git-release