GitLab a publicat pe 10 septembrie 2026 patch-uri urgente pentru CVE-2026-85706, o problemă de path traversal în API-ul repository commits. Furnizorul spune că, în anumite condiții, un utilizator neautentificat putea citi fișiere arbitrare de pe server. GitLab a evaluat problema la CVSS 10,0 și a lansat versiunile 19.1.8, 19.2.6 și 19.3.2.
Pe 11 septembrie, CISA a inclus CVE-2026-85706 în catalogul Known Exploited Vulnerabilities pe baza dovezilor de exploatare activă. Aceasta confirmă un semnal important de prioritate, nu faptul că fiecare organizație cu GitLab a fost compromisă. Identitatea țintelor, amploarea atacurilor și eventuala exfiltrare nu sunt publice în sursele verificate.
Ce sisteme intră în domeniu
Conform GitLab, sunt afectate instanțele CE și EE de la 18.7 până înainte de 19.1.8, ramura 19.2 înainte de 19.2.6 și ramura 19.3 înainte de 19.3.2. GitLab.com rulează deja versiunea corectată, iar clienții GitLab Dedicated nu trebuie să intervină, potrivit furnizorului. Verificarea de mai jos privește în special GitLab self-managed, inclusiv instanțe administrate de un MSP sau ascunse în laboratoare, subsidiare și proiecte de achiziție.
Nu presupune că un repository privat elimină riscul. Problema este în serverul GitLab, iar raportarea independentă menționează sonde observate în internet. Expunerea reală depinde de versiune, existența unui proiect public, accesibilitatea serviciului și configurația locală; acestea trebuie validate intern, nu ghicite dintr-un scor CVSS.
Ce este confirmat și ce rămâne necunoscut
- Confirmat de GitLab: ocolirea confinării de cale și lipsa autentificării în API-ul repository commits puteau permite citirea unor fișiere arbitrare, în anumite condiții.
- Confirmat de CISA: vulnerabilitatea are dovezi de exploatare activă suficiente pentru includerea în KEV.
- Raportat independent: watchTowr a observat sonde după divulgare; acest lucru nu identifică automat o victimă, un autor sau conținutul accesat în fiecare organizație.
- Necunoscut public: lista organizațiilor afectate, numărul incidentelor reușite și dacă au fost accesate secrete sau cod sursă într-o anumită instalație.
Plan de 24 de ore pentru proprietarul serviciului
- Găsește toate instanțele GitLab self-managed, inclusiv cele operate pentru echipe de dezvoltare, CI/CD sau de un furnizor. Notează URL-ul, proprietarul, versiunea, mediul și dacă serviciul este expus internetului.
- Actualizează fiecare instanță afectată la versiunea corectată pentru ramura sa sau la o versiune suportată mai nouă. Dacă actualizarea nu poate avea loc imediat, restrânge accesul public după evaluarea impactului asupra serviciului și documentează excepția, proprietarul și termenul.
- Caută proporțional în logurile aplicației și ale proxy-ului cereri neobișnuite către API-ul de commits din fereastra de expunere. O absență a logurilor nu dovedește absența accesului; consemnează limita de retenție și decizia de investigație.
- Evaluează rotația token-urilor, cheilor, variabilelor CI/CD și credențialelor care ar fi putut fi accesibile de pe server. Rotația trebuie să fie o decizie bazată pe expunere și investigație, nu o acțiune automată fără proprietar sau impact analizat.
Dovada care contează pentru conducere
Un mesaj că „am aplicat patch-ul” nu este un dosar de închidere. Păstrează inventarul care arată ce instanțe au fost evaluate, versiunea înainte și după, momentul actualizării, responsabilul, rezultatul verificării și orice excepție. Leagă această evidență de serviciile și repository-urile critice care depind de instanță.
Pentru o organizație orientată spre NIS2, această trasabilitate susține managementul vulnerabilităților, securitatea lanțului de aprovizionare și continuitatea, fără a echivala automat cu conformitatea legală. Awarely Monitor poate ajuta la urmărirea semnalelor CVE/KEV, activelor, responsabililor și dovezilor de închidere; actualizarea, investigația și decizia de risc rămân responsabilitatea organizației.
Surse și verificare
Deschide sursele originale pentru context, actualizări și formularea exactă a afirmațiilor.