Michael JohnsonOm du har uppdaterat Git i terminalen är arbetet inte klart: vissa appar och byggmiljöer kan köra en egen kopia. Den 10 november 2026 släppte Git-projektet korrigeringar för sex sårbarheter – från kodkörning vid rekursiv kloning till minneskorruption vid sammanslagning. Därför behöver du kontrollera varje miljö som hanterar repositorier eller deras innehåll, inte bara resultatet av kommandot git --version i ditt skal.
Vad uppdateringen ändrade
Åtgärderna ingår i Git 2.56.1 och har bakporterats till de grenar som fortfarande stöds: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 och 2.50.2. Uppdateringen åtgärdar sex problem i olika delar av Git – hantering av sökvägar, länkar, signaturer, binära patchar, sammanslagningar och importströmmar. GitHubs genomgång av sårbarheterna och rekommendation om att uppdatera publicerades den 10 november; versionsinformationen för Git 2.56.1 listar de CVE:er som åtgärdats i serien.
Rent praktiskt innebär det att uppdatera Git på tre ställen: arbetsdatorer, automatisering och appar som innehåller en egen Git-version. Det är lätt att missa den sista punkten: en uppdatering av systempaketet ändrar inte automatiskt versionen i varje klient eller byggavbild.
Varför rekursiv kloning är värd uppmärksamhet
Det tydligaste scenariot börjar med rekursiv kloning av ett opålitligt repositorium. På grund av att sökvägens längd trunkerades kunde en mycket lång sökvägspost passera kontrollen under ett namn och sedan hamna på disken i förkortad form. I det Git-scenario som beskrivs kunde detta ersätta en undermoduls .git-fil med en symbolisk länk till en katalog med skadlig konfiguration eller skadliga hooks. När Git sedan användes kunde det köra kod som angriparen hade angett.
Viktigt i praktiken: det krävs ett särskilt förberett repositorium och en motsvarande operation. Team som regelbundet klonar projekt från externa källor med parametern --recurse-submodules bör prioritera att uppdatera klient- och automatiseringsmiljöer. Korrigeringen avvisar alltför långa sökvägar innan de trunkeras.
Andra ställen där Git hanterar opålitliga data
Ett annat problem uppstår när ett tomt repositorium klonas via Git protocol v2. Servern kunde skicka en HEAD-referens med ett grennamn som innehöll katalogtraverseringskomponenter. Senare kunde en uppdatering av grenen skriva en fil utanför den förväntade referenskatalogen. I de korrigerade versionerna kontrollerar Git detta mål och andra referensnamn som tas emot via protokollet.
Separata sårbarheter påverkade sammanslagningar och patchar. Vid hantering av signaturer var en fast array dimensionerad för högst två signaturer. Ett särskilt utformat meddelande med fler signaturer kunde orsaka en skrivning utanför arrayens gränser och minneskorruption. Vid tillämpning av en binär patch tog storlekskontrollen hänsyn till den ursprungliga representationen, trots att komprimerade data kan expanderas till en betydligt större mängd. Nu kontrollerar Git den angivna okomprimerade storleken innan data behandlas.
Stora sammanslagningar kunde också leda till överspill vid beräkningen av den nödvändiga bufferten och efterföljande skrivning utanför dess gränser. Det berör bland annat värdtjänster och appar som sammanfogar opålitligt innehåll. Slutligen har tre funktioner i git fast-import fått begränsningar för kommandon från indataströmmen: rewrite-submodules-from och rewrite-submodules-to kunde läsa godtyckliga filer, medan export-pack-edges kunde skapa filer eller lägga till data i befintliga filer. Nu blockeras dessa funktioner om inte flaggan --allow-unsafe-features uttryckligen anges. Den bör bara användas med en betrodd strömgenerator.
Var du hittar separata Git-kopior
Som utvecklare kan du börja med att kartlägga var Git startas. Kontrollera versionen i terminalen och använd den inbyggda uppdateringskontrollen i IDE:er och Git-klienter för skrivbordet. Kontrollera sedan CI-avbilder, containrar, runners och serverjobb som klonar, sammanfogar, tillämpar binära patchar eller kör fast-import. Att det finns en aktuell Git-version på värden garanterar inte att appen faktiskt använder den.
Organisationer bör kontrollera inte bara ursprungliga avbilder utan även redan driftsatta miljöer: en beständig runner eller intern tjänst kan ha behållit en gammal binärfil efter att basavbilden uppdaterats. För GitHub Enterprise Server anger GitHub de korrigerade versionerna 3.19.15, 3.20.11, 3.21.9 och 3.22.4. Företaget uppger att korrigeringarna redan har driftsatts på github.com och GitHub Enterprise Cloud, även i varianter med datalokaliseringsalternativ. Utgåvor av GitHub Desktop och GitHub Copilot app med den korrigerade Git-versionen samordnas; korrigerade versioner för Codespaces och GitHub Actions ska också komma.
Så minskar du risken före uppdateringen
Om du inte kan installera korrigeringen omedelbart bör du tillfälligt begränsa operationer med opålitliga data: klona repositorier endast från betrodda servrar, undvik rekursiv kloning av okontrollerade projekt, sammanfoga inte deras innehåll och tillämpa inte binära patchar eller fast-import-strömmar från dem. Åtgärderna minskar exponeringen för de specifika sårbara scenarierna, men ersätter inte en uppdatering.
Den viktigaste praktiska slutsatsen är enkel: leta efter Git-korrigeringen där programmet faktiskt kör Git. Terminalkommandot är bara en av dessa platser; utvecklingsklienter, CI och tjänster som hanterar repositorier behöver kontrolleras separat.
