Hopp til innholdet
Centoculus
no

Sikkerhetsvarsel · Høy

Git: ondsinnede repositorier kan kjøre kode under rekursiv kloning (CVE-2026-111760)

· 4 minutter å lese · Centoculus Security Team

Kjent siden

Berørt: Git før 2.56.1 (rettet i 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, 2.55.1, 2.56.1)

Hva skjedde

Den 11. november 2026 ga Git-prosjektet ut nye versjoner som retter seks sikkerhetsfeil. Den alvorligste er CVE-2026-111760. Kloning av et ondsinnet repositorium rekursivt, altså sammen med submodulene, kan kjøre angriperens kode på maskinen som utfører klonen.

Årsaken er en heltallstrunkering i måten Git håndterer indeksen sin på. En svært lang sti passerer Gits sikkerhetskontroll, men Git skriver den deretter til disk under et kortere navn. En angriper kan velge det kortere navnet. Dermed kan angriperen erstatte en submodul sin .git-fil med en symbolsk lenke til en katalog som inneholder ondsinnede hooks eller konfigurasjon. Når Git så bruker katalogen, kjøres angriperens kode. Rettelsen gjør at Git avviser slike svært lange stier før lengden kan kuttes ned.

De samme utgivelsene retter fem andre feil:

  • CVE-2026-113408: Når noen kloner et tomt repositorium over Git-protokoll v2, kan en ondsinnet server sende et grennavn som inneholder path traversal. Med files-referansebackenden kan en senere oppdatering av den grenen skrive utenfor Gits referansekatalog.
  • CVE-2026-114467: Sammenslåing av en tag som har mer enn to GPG-signaturer ødelegger stackminne og kan føre til tjenestenekt. Hosting-tjenester som kjører slike sammenslåinger for brukerne sine, kan også være berørt.
  • CVE-2026-114469: En binær patch som utvides til en svært stor størrelse, kan komme forbi Gits grense for patchstørrelse på omtrent 1 GiB og få Git til å krasje med en lesing utenfor grensene.
  • CVE-2026-105437: En svært stor sammenslåing med mange konflikter og et stort conflict-marker-size-attributt kan få Git til å skrive forbi slutten av en heap-buffer. GitLab sier at kodehostingservere er de mest sannsynlige målene, gjennom git merge-tree, som servere kjører for å sjekke om en pull- eller merge-forespørsel kan slås sammen.
  • CVE-2026-114466: Tre funksjoner i git fast-import (rewrite-submodules-from, rewrite-submodules-to og export-pack-edges) kunne brukes til å lese vilkårlige filer, eller til å opprette filer og legge data til i dem. Git avviser nå disse i en inndatastrøm med mindre --allow-unsafe-features er satt.

Ingen av kildene rapporterer angrep så langt.

Hvem er berørt

Berørt er alle systemer som kjører en Git-versjon eldre enn disse rettede utgivelsene: 2.56.1, 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 og 2.50.2. På servere gjelder dette særlig:

  • Bygg-, CI- og distribusjonsservere som kloner repositorier rekursivt (git clone --recursive, --recurse-submodules eller git submodule update --init), særlig repositorier eller submoduler fra tredjeparter. For at CVE-2026-111760 skal fungere, må det klonede repositoriet være ondsinnet. Hvis du bare kloner dine egne pålitelige repositorier, er risikoen mye lavere, men du bør likevel oppdatere.
  • Selvdrevne Git-hostingservere som kjører sammenslåinger eller sammenslåingskontroller på innhold brukere har pushet (CVE-2026-105437, CVE-2026-114467).
  • GitHub Enterprise Server: rettelsene finnes i versjonene 3.19.15, 3.20.11, 3.21.9 og 3.22.4.
  • Applikasjoner som leveres med sin egen kopi av Git. De må oppdateres av leverandøren.

Ikke berørt: github.com og GitHub Enterprise Cloud. GitHub har allerede satt inn rettelsene der. Webservere som har Git installert, men aldri kloner eller slår sammen innhold utenfra, er i praksis ikke utsatt for klonefeilen. Oppdater dem likevel under neste vedlikehold.

Git for Windows hadde per 10. november 2026 kl. 19:09 UTC ikke sluppet en versjon basert på Git 2.56.1. Windows-administratorer bør følge med på den utgivelsen.

Hva du bør gjøre nå

  1. Sjekk installert versjon på hver server med git --version.
  2. Installer en rettet versjon fra operativsystemets pakkehåndterer (for eksempel apt update && apt install --only-upgrade git eller dnf upgrade git). Distribusjoner bakporterer vanligvis rettelser til sine egne pakkeversjoner, så sjekk distribusjonens sikkerhetsvarsel for å finne den rettede pakken. Hvis du bygger Git selv, oppgrader til 2.56.1 eller til den rettede utgivelsen i din serie.
  3. Oppdater GitHub Enterprise Server til 3.19.15, 3.20.11, 3.21.9 eller 3.22.4, avhengig av hvilken utgivelseslinje du bruker. Oppdater eventuelle andre applikasjoner som leveres med sin egen kopi av Git, så snart leverandøren slipper en rettelse.
  4. Til alle systemer er oppdatert, følg GitHubs midlertidige råd. Disse stegene erstatter ikke oppdateringen:
    • Klon bare fra servere du stoler på.
    • Ikke klon repositorier du ikke stoler på rekursivt.
    • Ikke slå sammen innhold eller tagger du ikke stoler på.
    • Ikke behandle binære patcher eller fast-import-strømmer fra kilder du ikke stoler på.
  5. På Git-hostingservere som ikke kan oppdateres ennå, beskytt mot CVE-2026-105437. Legg til conflict-marker-size=7 i info/attributes-filen til hvert repositorium, eller slå av sammenslåingskontroller for repositorier du ikke stoler på.
  6. Start på nytt langtkjørende tjenester som kaller Git, for eksempel CI-runnere eller Git-hostingdemoner, slik at de bruker den nye binærfilen.

Slik sjekker du om du er berørt

  • Kjør git --version. Versjoner eldre enn den rettede utgivelsen i sin serie er berørt: 2.50.2, 2.51.3, 2.52.1, 2.53.1, 2.54.1, 2.55.1 eller 2.56.1. For pakker fra distribusjonen bør du sammenligne pakkeversjonen med distribusjonens varsel i stedet for versjonsnummeret fra upstream.
  • Søk i bygge- og distribusjonsskript og CI-konfigurasjoner etter --recursive, --recurse-submodules og submodule update. Sjekk hvilke av repositoriene de kloner som kommer fra tredjeparter.
  • Se etter Git-kopier utenfor pakkehåndtereren, for eksempel med which -a git. Sjekk også Git som følger med CI-runnere, containere og andre applikasjoner.

Kilder

Relaterte innlegg