Seks sårbarheter i Git: Oppdater mer enn bare kommandolinjen

Selv om du har oppdatert Git i terminalen, er du ikke ferdig: separate apper og byggemiljøer kan kjøre sin egen kopi. 10. november 2026 ga Git-prosjektet ut rettelser for seks sårbarheter – fra kjøring av kode ved rekursiv kloning til minnekorrupsjon ved sammenslåing. Derfor må du kontrollere hvert miljø som behandler repositorier eller innholdet deres, ikke bare resultatet av kommandoen git --version i skallet ditt.

Dette er endret i oppdateringen

Rettelsene er inkludert i Git 2.56.1 og tilbakeført til vedlikeholdte versjoner: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 og 2.50.2. Oppdateringen løser seks problemer i ulike deler av Git – knyttet til stier, lenker, signaturer, binærpatcher, sammenslåinger og importstrømmer. GitHub publiserte gjennomgangen av sårbarhetene og rådet om å oppdatere 10. november; versjonsnotatene for Git 2.56.1 lister opp CVE-ene som er rettet i denne serien.

I praksis betyr dette at du må oppdatere Git på tre steder: arbeidsmaskiner, automatisering og apper som inkluderer sin egen Git-versjon. Det siste er lett å overse: en oppdatering av systempakken endrer ikke automatisk versjonen i hver klient eller hvert byggmiljø.

Derfor bør rekursiv kloning tas på alvor

Det tydeligste angrepsforløpet starter med rekursiv kloning av et repositorium du ikke stoler på. På grunn av avkorting av stilengden kunne en svært lang sti passere kontrollen under ett navn og deretter bli skrevet til disk i avkortet form. I det beskrevne Git-scenarioet kunne dette gjøre det mulig å erstatte undermodulens .git-fil med en symbolsk lenke til en katalog med skadelig konfigurasjon eller hooks. Når Git senere tok kontakt med den, kunne kode valgt av angriperen bli kjørt.

Viktig i praksis: Dette krever et spesiallaget repositorium og en tilsvarende operasjon. Team som jevnlig kloner prosjekter fra eksterne kilder med parameteren --recurse-submodules, bør prioritere å oppdatere klienter og automatiserte miljøer. Rettelsen avviser altfor lange stier før lengden blir avkortet.

Andre steder der Git behandler data du ikke stoler på

Et annet problem oppstår når et tomt repositorium klones via Git protocol v2. Serveren kunne sende en HEAD-referanse med et branchnavn som inneholdt katalogtraverseringskomponenter; senere kunne en oppdatering av branchen skrive en fil utenfor den forventede referansekatalogen. I de rettede Git-versjonene kontrolleres dette målet og andre referansenavn som mottas via protokollen.

Separate sårbarheter berørte sammenslåinger og patcher. Ved behandling av signaturer var en fast matrise dimensjonert for maksimalt to signaturer; en spesiallaget melding med flere signaturer kunne føre til skriving utenfor matrisens grenser og minnekorrupsjon. Ved bruk av en binærpatch tok størrelseskontrollen utgangspunkt i den opprinnelige representasjonen, selv om komprimerte data kan pakkes ut til en betydelig større mengde. Nå kontrollerer Git den oppgitte ukomprimerte størrelsen før behandlingen.

Store sammenslåinger kunne også føre til overløp ved beregning av nødvendig bufferstørrelse og påfølgende skriving utenfor bufferens grenser. Dette gjelder blant annet vertstjenester og apper som slår sammen innhold de ikke stoler på. Til slutt er tre funksjoner i git fast-import blitt begrenset for kommandoer fra inndatastrømmen: rewrite-submodules-from og rewrite-submodules-to kunne lese vilkårlige filer, mens export-pack-edges kunne opprette filer eller legge data til eksisterende filer. Nå blokkeres disse funksjonene med mindre flagget --allow-unsafe-features er angitt; bruk det bare med en betrodd strømgenerator.

Slik finner du separate Git-kopier

Som utvikler kan du begynne med å kartlegge hvor Git startes fra. Kontroller versjonen i terminalen, og bruk den innebygde oppdateringskontrollen i IDE-er og Git-klienter for skrivebordet. Kontroller deretter CI-avbildninger, containere, runner-instanser og serverjobber som utfører kloning eller sammenslåing, bruker binærpatcher eller kjører fast-import. At vertsmaskinen har en oppdatert Git-versjon, garanterer ikke at appen bruker den.

Organisasjoner bør kontrollere både de opprinnelige avbildningene og miljøer som allerede er tatt i bruk: en vedvarende runner-instans eller intern tjeneste kan ha beholdt en gammel binærfil etter at basisavbildningen ble oppdatert. For GitHub Enterprise Server oppgir GitHub de rettede versjonene 3.19.15, 3.20.11, 3.21.9 og 3.22.4. Selskapet opplyste at rettelsene allerede var tatt i bruk på github.com og GitHub Enterprise Cloud, også for varianter med datalagring. Utgivelser av GitHub Desktop og GitHub Copilot-appen med rettet Git koordineres; rettede versjoner for Codespaces og GitHub Actions skal også komme.

Slik reduserer du risikoen før oppdatering

Hvis du ikke kan installere rettelsen umiddelbart, bør du midlertidig begrense operasjoner med data du ikke stoler på: klon bare repositorier fra betrodde servere, unngå rekursiv kloning av ubekreftede prosjekter, ikke slå sammen innholdet deres, og ikke bruk binærpatcher eller fast-import-strømmer du har mottatt fra dem. Disse tiltakene reduserer eksponeringen for de konkrete sårbarhetsscenarioene, men erstatter ikke oppdateringen.

Den viktigste praktiske konklusjonen er enkel: Finn ut hvor programmet faktisk kjører Git, og sørg for at det er rettet. Terminalkommandoen er bare ett av stedene; utviklingsklienter, CI og tjenester som behandler repositorier må kontrolleres separat.