GitLab a publicat remedierea pe 10 septembrie. În jurul orei 06:00 UTC în dimineața următoare, rețeaua de honeypot-uri watchTowr vedea deja sondări pentru ea. CISA a adăugat vulnerabilitatea în catalogul breșelor exploatate activ în aceeași zi, cu termen de trei zile pentru agențiile federale.
A marcat-o, de asemenea, ca necesitând triaj criminalistic, conform Directivei Operaționale Obligatorii 26-04.
Ultima parte e motivul pentru care merită citit, nu doar patchuit. Marcarea pentru triaj criminalistic e o agenție guvernamentală care spune, printr-o directivă obligatorie, că instalarea actualizării nu răspunde la întrebare. Întrebarea e dacă era deja cineva înăuntru.
Ce face vulnerabilitatea
CVE-2026-85706 e o eroare de traversare de cale în API-ul de commit-uri al GitLab, cotată 10.0. Se suprapun două probleme: limitarea greșită a căilor și lipsa impunerii autentificării pe acel endpoint.
Rezultatul e că un atacator fără credențiale poate trimite o cerere și primi de la aplicație fișiere pe care nu ar trebui să le expună niciodată — orice poate citi procesul serverului GitLab. O singură cerere HTTP, fără lanț, fără autentificare.
A fost raportată prin HackerOne de un cercetător creditat ca s3ntago. Cod public de demonstrație a apărut la scurt timp după dezvăluire.
Versiuni corectate 19.3.2 19.2.6 19.1.8 Publicate 10 septembrie 2026 Afectate GitLab CE si EE self-managed sub aceste versiuni Neafectate GitLab.com (deja patchuit) si GitLab Dedicated
Aceeași versiune a rezolvat și CVE-2026-87719, o scurgere de informații din ediția Enterprise.
Dacă folosești GitLab.com, nu e problema ta. Dacă rulezi propria instanță, este, iar termenul care se aplica agențiilor federale americane a fost 14 septembrie.
De ce o citire de fișiere e mai gravă aici decât aproape oriunde
Pe majoritatea serverelor, citirea arbitrară de fișiere e o problemă serioasă de divulgare. Pe un server GitLab e o recoltare a credențialelor care ajung la tot ce mai operezi.
O instanță GitLab self-managed conține de regulă variabile CI/CD, chei de deploy, token-uri de acces, credențiale pentru furnizorii de cloud, șiruri de conexiune la baze de date, chei SSH și material de semnare. Astea nu sunt date despre afacerea ta. Sunt cheile către mediul de producție, către registrul de artefacte și către contul tău de cloud.
Patch-ul închide endpointul. Nu face nimic secretelor citite prin el, iar acelea rămân valabile până le rotește cineva.
E aceeași structură ca la incidentul Magento despre care am scris săptămâna trecută, unde îndrumarea Adobe era rotirea cheii de criptare și a tot ce stătea sub ea. Aici nu trebuie să-ți spună nimeni: dacă o parte neautentificată a putut citi fișiere arbitrare de pe mașina care ține secretele pipeline-ului tău, acele secrete sunt incidentul.
Cum cauți
watchTowr a publicat un punct de plecare concret, iar rularea lui nu costă aproape nimic:
`Cauta cereri HTTP POST catre /api/v4/projects/{id}/repository/commits/ care contin parametri file.path
Si valori de cale neobisnuite si siruri de tip traversare cereri neautentificate repetate adrese sursa necunoscute dimensiuni de raspuns neobisnuite`
Două precizări oneste despre căutarea asta.
E o pistă de investigație, nu o regulă de detecție. Iar un rezultat curat nu dovedește că exploatarea nu a avut loc — în special dacă jurnalele erau incomplete, normalizate într-un fel care elimină parametrii, sau pur și simplu nepăstrate suficient în urmă.
Dacă găsești accesări suspecte de fișiere, următoarea întrebare e care fișiere. Stabilește dacă acele căi conțin variabile CI/CD, chei de deploy, token-uri de acces, credențiale de bază de date sau secrete de cloud, și tratează fiecare găsit ca fiind compromis.
Ce ai de făcut
- Treci acum pe 19.3.2, 19.2.6 sau 19.1.8, în afara ciclului obișnuit de patchuire. E o schimbare de urgență, nu una programată.
- Verifică apoi versiunea care rulează, nu tichetul de mentenanță sau inventarul de pachete. Cele două se contrazic mai des decât se așteaptă oricine.
- Inventariază fiecare instanță self-managed. Noduri secundare, sisteme de test și staging, medii de recuperare în caz de dezastru, instalări în containere și instanța pe care a ridicat-o o echipă acum doi ani și pe care n-a mai atins-o nimeni. Instanța uitată e cea expusă.
- Rulează căutarea de mai sus în jurnale pentru intervalul 10 septembrie – data patchuirii, și mai devreme dacă poți: data dezvăluirii nu e neapărat data descoperirii.
- Rotește pornind de la premisa că nu poți dovedi o negație. Dacă o instanță a fost accesibilă din internet și nepatchuită în acel interval, rotește variabilele CI/CD, cheile de deploy, token-urile de acces și orice credențiale de cloud pe care le deținea. E o operațiune care doare și e remedierea propriu-zisă.
- Întreabă-te dacă instanța trebuie să fie expusă în internet. Un GitLab self-managed aflat în spatele unui VPN sau al unui proxy cu autentificare n-a fost niciodată accesibil pentru asta.
Tiparul, a șasea oară
Patch pe 10 septembrie. Sondări pe 11 septembrie. Cod public de demonstrație la scurt timp după.
Am scris despre aceeași secvență de șase ori în două săptămâni — MikroTik, Plex, Chromium, PaperCut, StyleSmuggler, iar acum GitLab. Intervalul dintre publicarea unei remedieri și operaționalizarea ei de către atacatori se măsoară în ore sau zile, și se micșorează.
Consecința practică nu e că patchuirea contează mai mult. E că întrebarea de după patchuire contează mai mult. Fiecare dintre incidentele acelea s-a încheiat la fel: patch-ul a închis ușa, iar cineva tot a trebuit să afle cine trecuse deja prin ea.
Pentru acesta, CISA a scris instrucțiunea într-o directivă.
4Tify analizează expunerea infrastructurii de dezvoltare și a secretelor pe care le conține — inclusiv instanța GitLab expusă în internet pentru că așa a fost mai simplu. Dacă vrei o evaluare, scrie-ne.