Git 2.56.1 repară șase vulnerabilități, iar runnerele voastre de CI au nevoie de el mai mult decât laptopul

Pe 10 noiembrie, proiectul Git a lansat Git 2.56.1, plus versiuni corectate pentru liniile de mentenanță mai vechi: 2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 și 2.50.2. Împreună, acestea închid șase CVE-uri: CVE-2026-111760, CVE-2026-113408, CVE-2026-114467, CVE-2026-114469, CVE-2026-105437 și CVE-2026-114466. Proiectul le numește versiuni coordonate de remediere a securității și cere utilizatorilor să actualizeze cât mai curând. Bug-urile au fost găsite de Luke Martin și pwn2addr.

Cel care contează este CVE-2026-111760, evaluat High, cu scor CVSS 8,0 în avizul de securitate al proiectului. Pe scurt: codul de index din Git are un bug de trunchiere a numerelor întregi. O cale foarte lungă este verificată sub numele complet, apoi ajunge pe disc sub unul mai scurt. Un atacator poate folosi această nepotrivire ca să înlocuiască fișierul .git al unui submodul cu un symlink către un director controlat de el, plin cu configurații sau hook-uri proprii. Hook-urile sunt cod. Așadar, un clone recursiv al repository-ului nepotrivit se poate termina cu rularea codului altcuiva pe mașina voastră. Avizul spune că se crede că vulnerabilitatea poate fi exploatată doar dacă folosiți --recurse-submodules.

GitHub a actualizat deja github.com, GitHub Enterprise Cloud și Enterprise Cloud with data residency. Dacă rulați singuri GitHub Enterprise Server, versiunile corectate sunt 3.19.15, 3.20.11, 3.21.9 și 3.22.4.

Scorul subestimează riscul pentru majoritatea echipelor

Ciți vectorul CVSS și v-ați putea relaxa puțin. Complexitate ridicată a atacului, privilegii reduse, interacțiune cu utilizatorul necesară. Pe laptopul unui dezvoltator, e corect: cineva trebuie să facă un clone recursiv al unui repository ostil.

Dar gândiți-vă cine rulează de fapt git clone în organizația voastră. De obicei nu oamenii. Ci runnerele de CI, de sute de ori pe zi, fără ca cineva să se uite, având chei de deploy și credențiale cloud în variabile de mediu. „Interacțiune cu utilizatorul necesară” nu înseamnă mare lucru când utilizatorul este un fișier YAML.

Când construim aplicații cloud-native pentru clienți enterprise, Git-ul care contează rareori e cel de pe laptopul cuiva. Este cel inclus într-o imagine de bază Docker aleasă acum un an și jumătate, cel de pe un runner self-hosted, cel din containerul de deploy. Un update de pachete pe Mac nu atinge niciuna dintre acestea. Din experiența noastră cu PHP și Docker, bănuiala mea sinceră e că majoritatea echipelor au trei sau patru versiuni diferite de Git pe căile de build și deploy și nu le-ar putea enumera fără să se uite.

Echipele mobile au propria versiune a acestei probleme. În proiectele noastre native iOS și Android, submodulele sunt încă o metodă frecventă de a integra SDK-uri comune, biblioteci native vendorizate sau un kit UI intern. Mașinile de build sunt adesea Mac-uri vechi, pe care nu le-a reinstalat nimeni de mult. Iar proiectul Git recomandă explicit să actualizați orice aplicație care include propria copie de Git, ceea ce acoperă destule IDE-uri și clienți desktop. Actualizarea Git-ului din sistem nu le rezolvă.

Pe partea de securitate, se potrivește cu un tipar pe care îl vedem mereu. În testele noastre de penetrare, pipeline-ul de build este deseori cea mai ușoară cale de intrare, pentru că are încredere în lucruri pe care nimeni nu le-ar lăsa lângă producție: fork-ul unui contractor, proiectul-exemplu al unui furnizor, o dependență open-source adusă ca submodul. Oamenii uită că hook-urile sunt executabile. Atacatorii nu.

Admit că am sentimente amestecate. Șase CVE-uri deodată, într-un instrument atât de vechi și de încredere, sunt puțin neliniștitoare. În același timp, remedieri coordonate pe șapte linii de versiuni sunt exact mentenanța plictisitoare și competentă pe care o vrei de la un proiect de care depind toți. Remedierea există. Partea grea e la noi: să găsim fiecare copie.

Ce aș face săptămâna aceasta

1. Inventariați fiecare binar Git, nu doar laptopurile. Rulați git --version în imaginile de CI, Dockerfile-uri, runnerele self-hosted și Mac-urile de build. Vreți 2.56.1 sau versiunea corectată pentru seria voastră (2.55.1, 2.54.1, 2.53.1, 2.52.1, 2.51.3 sau 2.50.2).
2. Reconstruiți intenționat imaginile de bază. Nu presupuneți că următorul rebuild programat va include un Git corectat. Verificați versiunea din imaginea construită.
3. Dacă găzduiți singuri GitHub Enterprise Server, treceți la 3.19.15, 3.20.11, 3.21.9 sau 3.22.4.
4. Căutați în configurația pipeline-ului checkout-uri recursive de submodule. Acolo unde repository-ul părinte sau vreun submodul nu e complet sub controlul vostru, dezactivați recursivitatea până la actualizarea runnerului.
5. Până se actualizează totul, urmați recomandările provizorii ale proiectului: faceți clone doar de pe servere de încredere, evitați clone-urile recursive ale oricărui lucru nesigur și fiți atenți când integrați conținut sau tag-uri externe, aplicați patch-uri binare ori încărcați fluxuri fast-import din surse pe care nu le controlați.

Pentru clienții noștri elvețieni cu cerințe de conformitate, aș adăuga un al șaselea pas: notați ce ați actualizat și când. Auditorilor le plac dovezile, iar pentru un patch atât de răspândit e bine să le aveți gata, nu reconstituite mai târziu. Tratăm acest gen de igienă a pipeline-urilor când configurăm infrastructura de build și deploy și apare constant în analizele noastre de securitate.

Dacă nu sunteți siguri câte copii de Git se ascund în pipeline-ul vostru de build, hai să vorbim.