Vulnerabilitate critică GitLab permite executarea de cod fără autentificare, actualizare obligatorie

GitLab a publicat pe 21 octombrie 2026 șapte actualizări de securitate care remediază o vulnerabilitate cotată cu scorul maxim posibil pe scala CVSS, 10.0. CVE-2026-110264 permite unui utilizator neautentificat să execute cod arbitrar pe serverul GitLab, iar defectul afectează toate versiunile lansate începând din 2014, de la GitLab 7.0 încoace.

Pentru orice organizație din România care rulează GitLab pe infrastructură proprie, acest anunț nu e unul dintre numeroasele avize de securitate care trec neobservate. E genul de vulnerabilitate care, odată ce mecanismul de exploatare devine cunoscut public, de obicei duce la exploatare în masă în câteva zile.

Cum funcționează atacul și de ce e atât de grav

Problema nu se află în codul propriu-zis al GitLab, ci în Onigmo, motorul de expresii regulate folosit de Ruby, limbajul în care e scris GitLab. E un detaliu tehnic important: corecția nu e un patch obișnuit de aplicație, ci un patch pentru runtime-ul Ruby inclus în pachetele de instalare.

Calea de atac trece printr-un fișier aparent banal: un document Org mode (.org), formatul de fișiere text folosit frecvent pentru note și liste de sarcini. Biblioteca pe care GitLab o folosește pentru a reda aceste fișiere construiește o expresie regulată dintr-un cuvânt-cheie scris pe o linie de tip #+TODO:, fără să îi limiteze lungimea. Dacă acel cuvânt se repetă de peste 32.767 de ori, apare o depășire de capacitate (integer overflow) în motorul regex, care provoacă o scriere în afara memoriei alocate programului.

Partea periculoasă: atacatorul nu are nevoie de cont pe instanța GitLab vizată. Îi trebuie doar un proiect public care conține fișierul .org malițios, redat automat de GitLab. Codul rezultat rulează cu privilegiile utilizatorului git, adică exact contul care are acces la toate depozitele găzduite pe server.

GitLab avertizează că o exploatare reușită poate trece neobservată, fără să provoace vreo cădere vizibilă a serverului. Ce poate fi expus în acest scenariu: fișierul gitlab-secrets.json, toate variabilele CI/CD, token-urile de runner și de acces, plus acces de citire și scriere la toate depozitele instanței. Practic, cheile de la întregul mediu de dezvoltare al unei organizații.

Cine trebuie să acționeze și cum

Vulnerabilitatea afectează strict instalările administrate local, self-managed, indiferent de forma de livrare: pachetul Linux Omnibus, Docker, Helm chart sau instalare din surse. GitLab.com rulează deja versiunea corectată, iar clienții GitLab Dedicated pe versiunile internal0 menționate de furnizor nu trebuie să facă nimic suplimentar.

Pentru toți ceilalți, versiunile corectate sunt 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 și 18.11.13. Important de reținut: ramurile 19.4 și 19.3 vin cu migrări de bază de date, ceea ce înseamnă că o instanță single-node nu repornește până la finalizarea lor și trebuie planificată o fereastră de întrerupere a serviciului. Instalările multi-nod pot folosi procedura de actualizare fără întrerupere.

Backport-urile pentru versiunile 19.2, 19.1, 19.0 și 18.11 conțin doar corecția pentru CVE-2026-110264, nu și celelalte 11 vulnerabilități remediate în pachetul complet, printre care două de severitate ridicată: CVE-2026-15723 (preluarea conturilor LDAP prin auto-linking OmniAuth SAML/LDAP, CVSS 8.2) și CVE-2026-112212 (manipularea cache-ului pentru descoperirea OAuth/OIDC, CVSS 7.5). Organizațiile care rulează aceste versiuni mai vechi ar trebui să ia în calcul migrarea la 19.3.6 sau o versiune ulterioară pentru acoperire completă.

O capcană reală pentru cine a actualizat deja recent: instanțele aduse la 19.4.2, 19.3.5 sau 19.2.8 pe 12 octombrie 2026, pentru o vulnerabilitate anterioară (CVE-2026-97229), rămân complet vulnerabile la CVE-2026-110264 și trebuie actualizate din nou. Faptul că o instanță a primit un patch recent nu garantează nimic în acest caz.

Pentru versiunile 7.0 până la 18.10, nu există corecție disponibilă în ramura respectivă. Singura soluție e migrarea la o versiune suportată, ceea ce poate implica mai mulți pași intermediari obligatorii. Până la finalizarea migrării, GitLab recomandă izolarea acestor instanțe de rețeaua publică.

Ce poate face o organizație până aplică patch-ul

Nu există o soluție oficială de ocolire (workaround) din partea GitLab. Măsurile de mai jos reduc expunerea, dar nu elimină vulnerabilitatea, și trebuie tratate ca temporare:

• restrângerea vizibilității publice a proiectelor, pentru că atacul neautentificat are nevoie de un proiect public cu fișierul .org malițios;
• restricționarea accesului la instanță din Internet, prin VPN sau liste de IP-uri permise;
• izolarea temporară de rețeaua publică a instanțelor critice care nu pot fi actualizate imediat, cu oprirea celor neesențiale sau de test.

GitLab a publicat două reguli de detecție în format Sigma, utile pentru verificarea unei compromiteri anterioare actualizării: una pentru căderi anormale ale proceselor Puma sau Sidekiq în motorul regex (vizibile în puma_stderr.log) și alta pentru un volum neobișnuit de erori la redarea fișierelor Org mode de la același client într-un interval scurt (în exceptions_json.log). Echipele tehnice ar trebui să verifice mai întâi dacă aceste surse de jurnal sunt active, pentru că detecția nu funcționează fără ele.

Organizațiile care identifică semne de compromitere trebuie să izoleze serverul, să păstreze jurnalele ca dovezi și să reinstaleze din surse de încredere, revocând toate credențialele posibil expuse: token-uri de acces și de runner, chei de deploy, secretele din fluxurile CI/CD.

Responsabilitatea legală rămâne la deținătorul sistemului

Pentru organizațiile din România, acest tip de incident intră direct sub incidența Legii 58/2023, care stabilește clar că responsabilitatea asigurării securității cibernetice a unui sistem informatic revine persoanei fizice sau juridice care îl deține, organizează, administrează sau utilizează. Pentru entitățile care intră sub OUG 155/2024 (legea de transpunere a directivei NIS2 în România), gestionarea unei vulnerabilități critice precum aceasta nu e doar o chestiune de bune practici tehnice, ci face parte din obligațiile de management al riscului de securitate cibernetică pe care legea le impune: identificarea promptă a expunerii, aplicarea măsurilor de remediere și, acolo unde vulnerabilitatea a fost exploatată, raportarea incidentului conform termenelor prevăzute de lege.

Faptul că nu au fost raportate atacuri până pe 22 octombrie 2026 și că vulnerabilitatea nu figura încă în catalogul CISA KEV nu înseamnă liniște. Mecanismul de exploatare a fost deja descris public prin regulile de detecție, iar pentru vulnerabilitatea similară corectată pe 12 octombrie, cercetătorii au reprodus execuția de cod în mai puțin de o zi de la publicare. Pentru orice instanță GitLab expusă în Internet și neactualizată, fereastra de siguranță e deja foarte scurtă.