Awarely Monitor
AwarelyMonitor
Toate articolele
Vulnerabilități exploatate7 min

GitLab CVE-2026-110264: patch-ul din 12 octombrie nu ajunge

Pe 21 octombrie 2026, GitLab a lansat corecții pentru CVE-2026-110264, o vulnerabilitate cu scor CVSS 10,0 care, în anumite condiții, permite unui utilizator neautentificat să execute cod arbitrar pe un server GitLab autogăzduit. Potrivit The Hacker News, citând GitLab, afectează toate versiunile până la 7.0, lansată în 2014. Cauza este o depășire de întreg la compilarea unei expresii regulate special construite, în Onigmo, motorul de expresii regulate din Ruby.

Detaliul care contează pentru inventar: GitLab corectase deja pe 12 octombrie o problemă asemănătoare, CVE-2026-97229, dar doar pentru versiunile 19.2 și mai noi. Noile versiuni corectate sunt cu un patch peste cele din 12 octombrie, deci o instanță „patch-uită” atunci trebuie actualizată din nou.

Ce este confirmat

The Hacker News relatează, pe baza anunțului GitLab, că actualizările din 21 octombrie acoperă șapte ramuri: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 și 18.11.13. Versiunile de la 7.0 până la 18.11 înainte de 18.11.13 trebuie să urce la 18.11.13. GitLab a făcut backport la 18.11.13, 19.0.10, 19.1.9 și 19.2.9, ceea ce își rezervă pentru probleme severe; politica normală de suport acoperă doar versiunea curentă și precedentele două lunare.

GitLab.com rulează deja versiunea corectată, iar la GitLab Dedicated, tenanții pe 19.3.5-internal0 și 19.4.2-internal0 sau mai noi au corecția. Pentru instalările autogăzduite, clientul trebuie să acționeze. GitLab nu a spus ce condiții trebuie îndeplinite pentru a ajunge la compilatorul vulnerabil, deci configurația nu poate exclude instanța din risc, și nu oferă o soluție temporară: actualizarea este singura protecție confirmată.

Patch-ul din 12 octombrie nu ajunge

Pe 12 octombrie, GitLab a corectat CVE-2026-97229, tot CVSS 10,0, în 19.2.8, 19.3.5 și 19.4.2. Era o depășire de întreg în compilatorul de expresii regulate din CI/CD, raportat de cercetătorul „joaxcar” prin HackerOne. Rapid7 a reprodus execuția de cod pe o imagine neactualizată GitLab CE 19.4.1, cu precondiția ca atacatorul să poată face commit la un `.gitlab-ci.yml` și la o cale cu caractere UTF-8 într-un proiect public; pe instanțele care permit utilizatorilor să creeze proiecte publice, un cont obișnuit poate îndeplini asta.

Același cercetător a raportat de patru ori în aproximativ o lună execuții de cod în motorul de expresii regulate. Primele trei s-au oprit la 19.2; aceasta ajunge până la 7.0. Instanțele actualizate pe 12 octombrie sunt, conform The Hacker News, vulnerabile din nou și au nevoie de lansarea din 21 octombrie. Nu am putut citi anunțul GitLab; versiunile și detaliile de mai sus sunt cele relatate de The Hacker News și de Help Net Security.

Exploatare și surse care diferă

GitLab nu raportează exploatare, iar CVE-2026-110264 nu era în catalogul CISA KEV la 22 octombrie, în versiunea pe care am verificat-o direct; la fel pentru CVE-2026-97229. Rapid7 spunea la 13 octombrie că nu există exploatare confirmată pentru CVE-2026-97229. The Hacker News nu menționează un PoC public pentru CVE-2026-110264. Absența unei exploatări confirmate nu spune cât timp va rămâne așa.

Sursele diferă ușor: The Hacker News numără 11 probleme de securitate în lansarea din 21 octombrie, un rezumat secundar spune 12. În plus, un rezumat secundar spune că ramurile 18.10 și mai vechi nu au o versiune corectată proprie; tabelul redat de The Hacker News pune toate versiunile de la 7.0 la 18.11 pe 18.11.13. Verifică ramura ta în anunțul GitLab.

Ce faci

  • ▸Găsește toate instanțele GitLab autogăzduite, inclusiv cele de test și ale echipelor. Notează versiunea exactă, ramura și dacă sunt accesibile din Internet.
  • ▸Actualizează la versiunea de pe ramura ta din lista de mai sus, inclusiv instanțele „patch-uite” pe 12 octombrie.
  • ▸Planifică timpul de nefuncționare: lansările 19.4.3 și 19.3.6 includ modificări de bază de date care rulează la upgrade, deci instalările cu un singur nod au întrerupere, iar cele multi-nod pot folosi procedura GitLab fără oprire, potrivit The Hacker News.
  • ▸Dacă nu poți actualiza imediat, nu există o soluție temporară. Limitează accesul la instanță și, dacă permiți proiecte publice create de utilizatori obișnuiți, ia în calcul să închizi această opțiune până la upgrade; Rapid7 a arătat că pentru CVE-2026-97229 această opțiune a făcut ca un cont obișnuit să fie suficient. Pentru CVE-2026-110264, GitLab nu a precizat condițiile, deci aceasta este o reducere de risc, nu o garanție.
  • ▸GitLab a publicat două reguli Sigma pentru jurnalele aplicației: „Onigmo native worker crash” și „Org mode render error burst”. Rulează-le pe jurnalele din ultimele zile.
  • ▸Aplică în aceeași actualizare și celelalte corecții: CVE-2026-15723 (preluare de cont, doar dacă sunt activate împreună SAML și LDAP auto-linking) și CVE-2026-112212 (otrăvire de cache în OAuth și OpenID Connect pe configurații cu cache comun).

Închide alerta cu dovezi

Pentru fiecare instanță, păstrează versiunea înainte, versiunea după fiecare dintre cele două actualizări (12 și 21 octombrie) cu data, ramura, dacă s-a rulat migrarea de bază de date, rezultatul regulilor Sigma pe jurnale și excepțiile rămase, cu motiv și termen. Pentru instanțele rămase neactualizate, notează explicit că nu există soluție temporară.

Două patch-uri într-o săptămână, o singură dovadă

Urmărește în Awarely Monitor versiunea fiecărei instanțe GitLab după fiecare actualizare și dovezile păstrate. Actualizarea și regulile Sigma rămân în sistemele voastre.