Acest conținut a fost generat cu ajutorul inteligenței artificiale și publicat fără o verificare umană prealabilă. Poate conține erori și nu constituie consultanță profesională. Semnalați o problemă: info@delionsoft.com.
GitLab a remediat o vulnerabilitate de gravitate maximă în API-ul său de commit-uri din depozit, care permitea atacatorilor neautentificați să citească fișiere arbitrare, inclusiv date de autentificare și informații confidențiale, de pe un server vulnerabil. Conform raportului inițial, CISA a adăugat acum CVE-2026-85706 în catalogul său de vulnerabilități exploatate în mod activ, iar scanarea instanțelor necorectate a fost observată la mai puțin de o zi de la lansarea remedierii. Dacă utilizați GitLab autogestionat, aceasta este o vulnerabilitate care necesită remediere în aceeași zi.
Ce s-a întâmplat
Vulnerabilitatea provine din lipsa aplicării autentificării, combinată cu o delimitare necorespunzătoare a căilor de acces în API-ul de commit-uri. Rezultatul practic este citirea arbitrară a fișierelor printr-o singură cerere HTTP, fără a fi necesar un cont valid. GitLab a lansat remedieri pentru Community Edition și Enterprise Edition în versiunile 19.3.2, 19.2.6 și 19.1 și a recomandat actualizări imediate.
La o zi după lansarea patch-ului, firma de securitate watchTowr a declarat că observa încercări de explorare a vulnerabilității la nivel global pe internet și se aștepta ca exploatarea pe scară largă să urmeze în scurt timp, pe baza modului în care s-au desfășurat bug-urile anterioare ale GitLab. Aceasta a sugerat ca responsabilii cu securitatea să verifice jurnalele în căutarea cererilor HTTP POST către căile /api/v4/projects/{id}/repository/commits/ care includ un parametru file.path.
În aceeași zi, CISA a clasificat vulnerabilitatea CVE ca fiind exploatată activ și a acordat agențiilor civile federale din SUA un termen de trei zile pentru remediere, în conformitate cu Directiva operațională obligatorie 26-04. Acest termen se aplică doar organismelor federale, dar CISA și-a reiterat recomandarea obișnuită ca toți ceilalți să acorde prioritate elementelor din catalogul vulnerabilităților exploatate. Raportul menționează că GitLab nu a etichetat ea însăși vulnerabilitatea ca fiind exploatată în mediul real. De la sfârșitul anului 2021, patru vulnerabilități GitLab au fost marcate de CISA ca fiind exploatate.
De ce este important
O instanță GitLab auto-găzduită este, de obicei, unul dintre cele mai sensibile sisteme pe care le gestionează o echipă mică de ingineri. Aceasta stochează codul sursă, configurația CI/CD, cheile de implementare, datele de autentificare pentru registru, tokenurile de acces la cloud și, adesea, datele clienților în mediile de testare. Citirea neautentificată a unui fișier de pe acel host nu este o problemă izolată: este o colectare de date de autentificare care poate duce la accesul la conturile din cloud, la bazele de date de producție și la însăși pipeline-ul de lansare.
De asemenea, aspectele economice favorizează atacatorii în acest caz. Automatizarea unui exploit cu o singură solicitare este extrem de simplă în întregul spațiu IPv4, astfel încât durata de expunere contează mai mult decât dimensiunea sau profilul organizației. Echipele care expun GitLab la internet pentru contractanți externi sau pentru executori mobili sunt deosebit de vulnerabile. Deoarece vulnerabilitatea nu necesită date de autentificare, autentificarea multifactorială (MFA), autentificarea unică (SSO) și listele de IP-uri permise de pe paginile de autentificare nu oferă nicio protecție.
Ce trebuie făcut
- Actualizați imediat GitLab-ul autogestionat la versiunea 19.3.2, 19.2.6 sau la versiunea 19.1 cu patch-ul aplicat. GitLab.com și GitLab Dedicated sunt operate de furnizor, așa că verificați modelul dvs. de implementare înainte de a presupune că sunteți protejați.
- Căutați în jurnalele de acces cererile POST către API-ul de commit-uri care conțin parametrul
file.path, începând din perioada anterioară datei de lansare a patch-ului. Tratați orice rezultat pozitiv ca pe o potențială divulgare a informațiilor confidențiale. - Presupuneți că orice element care poate fi citit de procesul GitLab a fost compromis dacă ați fost expuși și nu ați aplicat patch-ul: rotiți variabilele CI/CD, token-urile de implementare, token-urile de înregistrare a runner-urilor, cheile SSH, datele de autentificare pentru cloud și orice secrete stocate în setările proiectului.
- Dacă GitLab este expus la internet fără o necesitate de afaceri, plasați-l în spatele unui VPN sau al unui proxy invers cu autentificare și verificați ce alte instrumente de dezvoltare sunt accesibile publicului.