Kuusi Git-haavoittuvuutta: päivitä muutakin kuin komentorivi

Jos päivitit Gitin terminaalissa, työ ei ole vielä valmis: erilliset sovellukset ja koontiympäristöt saattavat käyttää omaa Git-kopiota. 10. marraskuuta 2026 Git-projekti julkaisi korjaukset kuuteen haavoittuvuuteen — rekursiivisen kloonauksen koodinsuorituksesta yhdistämisen yhteydessä tapahtuvaan muistivaurioon. Siksi on tarkistettava jokainen ympäristö, joka käsittelee arkistoja tai niiden sisältöä, eikä vain sitä, mitä komento git --version näyttää komentotulkissa.

Mitä päivitys muuttaa

Korjaukset sisältyvät Git-versioon 2.56.1, ja ne on siirretty ylläpidettyihin haaroihin: versioihin 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 ja 2.50.2. Päivitys korjaa kuusi ongelmaa Gitin eri osissa: polkujen, linkkien, allekirjoitusten, binäärikorjausten, yhdistämisten ja tuontivirtojen käsittelyssä. GitHub julkaisi 10. marraskuuta haavoittuvuuksien kuvauksen ja päivityssuosituksen; Git 2.56.1:n julkaisutiedoissa luetellaan tässä julkaisusarjassa korjatut CVE-tunnukset.

Käytännössä Git on päivitettävä kolmessa paikassa: työasemissa, automaatiossa ja sovellusten sisällä, jos niihin sisältyy oma Git-versio. Viimeinen kohta unohtuu helposti: järjestelmäpaketin päivitys ei päivitä automaattisesti jokaisen asiakkaan tai koontiympäristön levykuvan versiota.

Miksi rekursiivinen kloonaus ansaitsee huomiota

Selkein hyökkäysketju alkaa epäluotetun arkiston rekursiivisesta kloonauksesta. Polun pituuden katkaisun vuoksi erittäin pitkä polku saattoi läpäistä tarkistuksen yhdellä nimellä ja päätyä sitten levylle lyhennettynä. Gitin kuvaamassa tilanteessa tämä mahdollisti aliprojektin .git-tiedoston korvaamisen symbolisella linkillä hakemistoon, jossa oli haitallinen asetustiedosto tai koukkuja. Kun Git myöhemmin käsitteli sitä, se saattoi suorittaa hyökkääjän määrittämää koodia.

Käytännössä on tärkeää huomata, että kyseessä on tarkoituksella valmisteltu arkisto ja siihen liittyvä toiminto. Tiimien, jotka kloonaavat säännöllisesti ulkoisista lähteistä projekteja valitsimella --recurse-submodules, kannattaa päivittää asiakasohjelmat ja automaatioympäristöt ensisijaisesti. Korjaus hylkää liian pitkät polut ennen kuin niiden pituus katkaistaan.

Muut kohdat, joissa Git käsittelee epäluotettuja tietoja

Toinen ongelma liittyy tyhjän arkiston kloonaamiseen Git protocol v2:n kautta. Palvelin saattoi toimittaa HEAD-viitteen, jonka haaran nimessä oli hakemistosta poistumisen mahdollistavia osia; myöhempi haaran päivitys saattoi kirjoittaa tiedoston odotetun viitehakemiston ulkopuolelle. Korjatuissa Git-versioissa tarkistetaan tällainen kohde ja muut protokollan kautta saadut viitteiden nimet.

Erilliset haavoittuvuudet koskivat yhdistämisiä ja korjaustiedostoja. Allekirjoituksia käsiteltäessä kiinteän kokoiseen taulukkoon oli varattu tilaa enintään kahdelle allekirjoitukselle. Erityisesti muodostettu viesti, jossa oli enemmän allekirjoituksia, saattoi aiheuttaa kirjoituksen taulukon rajojen ulkopuolelle ja vaurioittaa muistia. Binäärikorjausta sovellettaessa koon tarkistus huomioi alkuperäisen esitysmuodon, vaikka pakatut tiedot voivat purkautua huomattavasti suuremmaksi. Nyt Git tarkistaa ilmoitetun pakkaamattoman koon ennen käsittelyä.

Suuret yhdistämiset saattoivat myös aiheuttaa ylivuodon tarvittavan puskurin koon laskennassa ja sen seurauksena kirjoituksen puskurin rajojen ulkopuolelle. Tämä koskee myös palveluita ja sovelluksia, jotka yhdistävät epäluotettua sisältöä. Lisäksi kolme git fast-import-toimintoa sai rajoituksia syötevirran komentoihin: rewrite-submodules-from ja rewrite-submodules-to saattoivat lukea mielivaltaisia tiedostoja, ja export-pack-edges saattoi luoda tiedostoja tai lisätä tietoja olemassa oleviin tiedostoihin. Nyt nämä toiminnot estetään, ellei valitsinta --allow-unsafe-features ole annettu erikseen. Sitä tulee käyttää vain luotetun virran tuottajan kanssa.

Mistä erilliset Git-kopiot löytyvät

Kehittäjä voi aloittaa kartoittamalla, missä Git käynnistetään. Tarkista versio terminaalissa ja käytä IDE:n ja työpöydän Git-asiakasohjelmien omaa päivitysten tarkistusta. Tarkista sen jälkeen CI-levykuvat, kontit, runnerit ja palvelintehtävät, jotka kloonaavat tai yhdistävät arkistoja, soveltavat binäärikorjauksia tai suorittavat fast-import-komentoa. Se, että palvelimelle on asennettu uusin Git, ei takaa, että sovellus käyttää juuri sitä.

Organisaatioiden kannattaa tarkistaa lähdelevykuvien lisäksi myös jo käyttöönotetut ympäristöt: pysyvä runner tai sisäinen palvelu on voinut säilyttää vanhan binaaritiedoston peruslevykuvan päivityksen jälkeen. GitHub ilmoittaa GitHub Enterprise Serverin korjatuiksi versioiksi 3.19.15, 3.20.11, 3.21.9 ja 3.22.4. Yhtiö kertoo ottaneensa korjaukset jo käyttöön github.comissa ja GitHub Enterprise Cloudissa, myös tietojen omassa sijainnissa ylläpidettävissä vaihtoehdoissa. Korjattua Gitiä sisältävien GitHub Desktop- ja GitHub Copilot app -julkaisujen käyttöönottoa koordinoidaan; korjatut versiot Codespacesiin ja GitHub Actionsiin ovat myös vielä tulossa.

Näin pienennät riskiä ennen päivitystä

Jos korjausta ei voi asentaa heti, rajoita väliaikaisesti epäluotettujen tietojen käsittelyä: kloonaa arkistoja vain luotetuilta palvelimilta, vältä tarkistamattomien projektien rekursiivista kloonaamista, älä yhdistä niiden sisältöä äläkä sovella niistä saatuja binäärikorjauksia tai fast-import-virtoja. Näillä toimilla vähennät altistumista tietyille haavoittuville tilanteille, mutta ne eivät korvaa päivitystä.

Käytännön johtopäätös on yksinkertainen: Gitin korjaus on asennettava siellä, missä ohjelma todella suorittaa Gitiä. Terminaalin komento on vain yksi tällainen paikka; kehitystyökalut, CI ja arkistoja käsittelevät palvelut on tarkistettava erikseen.