Vulnerabilitate GitLab critică: CVE-2026-110264 și patch-ul din 21 octombrie

Pe 21 octombrie 2026, GitLab a publicat un critical patch release pentru toate liniile suportate, de la 19.5 până la 18.11. Cea mai gravă problemă reparată, CVE-2026-110264, e o vulnerabilitate GitLab cu scor CVSS 10.0: un overflow de întreg la compilarea unei expresii regulate care, în anumite condiții, permite unui utilizator neautentificat să ruleze cod pe server. Sunt afectate toate versiunile self-managed începând cu GitLab 7.0, lansat în iunie 2014.

Dacă îți găzduiești singur GitLab, contează și contextul. E a patra vulnerabilitate critică în GitLab self-managed în șase săptămâni, iar serverele actualizate pe 12 octombrie pentru o problemă foarte asemănătoare rămân expuse. Mai jos găsești ce s-a reparat, ce versiune instalezi pe linia ta, ce faci dacă nu poți actualiza azi și cum verifici dacă cineva a ajuns deja pe server.

Ce a reparat GitLab pe 21 octombrie

Anunțul oficial GitLab acoperă versiunile 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 și 18.11.13, pentru Community Edition (CE) și Enterprise Edition (EE). GitLab recomandă insistent upgrade-ul cât mai repede pe orice instalare afectată. Agenția de securitate cibernetică din Singapore a emis a doua zi alerta AL-2026-152, cu aceeași recomandare: actualizare imediată.

GitLab.com rulează deja versiunea reparată. La GitLab Dedicated, tenanții aflați pe 19.3.5-internal0, 19.4.2-internal0 sau mai nou au deja fix-urile și nu trebuie să facă nimic. Problema e strict a celor care administrează propria instanță: pe un server, în Docker sau în Kubernetes.

CVE-2026-110264 pe scurt

• Ce este: un overflow de întreg (CWE-190) în compilatorul de expresii regulate. Titlul oficial: „Integer Overflow issue in Regular Expression Compiler impacts GitLab CE/EE”.
• Impact: execuție de cod arbitrar pe serverul GitLab, de către un utilizator neautentificat, „în anumite condiții” pe care GitLab nu le detaliază public.
• Scor: CVSS 10.0, cu vectorul CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Pe scurt: atac prin rețea, complexitate mică, fără cont, fără interacțiunea unei victime și cu impact care trece dincolo de componenta vulnerabilă.
• Versiuni afectate: toate versiunile de la 7.0 anterioare lui 18.11.13, plus 19.0 înainte de 19.0.10, 19.1 înainte de 19.1.9, 19.2 înainte de 19.2.9, 19.3 înainte de 19.3.6, 19.4 înainte de 19.4.3 și 19.5 înainte de 19.5.1.
• Raportare: cercetătorul joaxcar, prin programul de bug bounty GitLab de pe HackerOne. The Register îl identifică drept Johan Carlsson.

GitLab nu oferă un workaround oficial. Singura remediere completă e versiunea nouă.

Celelalte 11 vulnerabilități din release

Release-ul repară în total 12 probleme: una critică, două de severitate ridicată, cinci medii și patru scăzute. Cele mai importante, după datele din anunț și din rezumatul SecurityOnline:

Cele patru probleme scăzute privesc cache-ul la titlurile de merge request, aplicarea politicilor de aprobare, ștergerea înregistrărilor de vulnerabilități și blocarea setărilor Duo pentru Amazon Q.

Un detaliu contează la planificare. Aceste 11 fix-uri există doar în 19.3.6, 19.4.3 și 19.5.1. Intervalele afectate pentru ele se termină la „înainte de 19.3.6”, deci un server pe 19.2 care instalează 19.2.9 închide RCE-ul, dar rămâne cu CVE-2026-15723 și CVE-2026-112212 deschise.

Starea exploatării

Pe 22 octombrie, nici GitLab, nici The Hacker News, nici analiza SOC Prime nu raportau exploatare în mediul real, iar vulnerabilitatea nu apărea în catalogul CISA Known Exploited Vulnerabilities (KEV). The Register estima că scanările după instanțe vulnerabile vor începe curând.

Tot pe 22 octombrie, baza de date Vulners a indexat un repository GitHub care pretinde un exploit pentru „unauthenticated RCE” prin CVE-2026-110264. Nimic nu confirmă că e funcțional. Repository-urile cu „PoC” apărute la câteva ore după un CVE critic sunt des false, iar unele conțin malware îndreptat chiar spre cei care le rulează. Nu-l descărca pe o mașină de lucru. Ia-l doar ca semnal că atenția asupra vulnerabilității e mare și că fereastra până la primele atacuri se scurtează.

Tratează CVE-2026-110264 ca și cum ar fi deja exploatată. Ce s-a întâmplat în septembrie cu altă vulnerabilitate GitLab de scor maxim, descris mai jos, arată de ce.

Cum funcționează atacul, pe cât se știe

GitLab nu a publicat calea completă de exploatare. SOC Prime notează că GitLab a reținut intenționat detaliile și precondițiile. Ce se știe vine din trei surse: anunțul oficial, numele celor două reguli de detecție publicate de GitLab și analiza Rapid7 pentru vulnerabilitatea înrudită din 12 octombrie.

Onigmo, motorul de expresii regulate din Ruby

GitLab e o aplicație Ruby on Rails, iar Ruby folosește pentru expresii regulate motorul Onigmo, scris în C și inclus în pachetele GitLab. Când aplicația construiește un pattern din date venite de la utilizator, compilatorul Onigmo procesează direct input-ul atacatorului. O greșeală de aritmetică acolo nu produce o excepție Ruby, ci poate produce o scriere în memorie în afara zonei alocate.

Fiindcă problema stă în motor și nu într-o funcționalitate GitLab recentă, ea ajunge până la versiunea 7.0. Konfirmity explică exact așa intervalul de 12 ani.

Pentru vulnerabilitatea din 12 octombrie, Rapid7 a descris mecanismul. Expresia se compilează întâi într-o reprezentare compactă US-ASCII și trece validarea. După verificări, Onigmo o recompilează pentru UTF-8, iar un overflow în calculul mărimii programului compilat produce instrucțiuni invalide. Pierderea integrității fluxului de control permite rularea unei comenzi de sistem ca utilizatorul git. Rapid7 a reprodus execuția de cod pe o imagine GitLab CE 19.4.1 nepatch-uită, cu ASLR activ.

GitLab nu spune dacă cele două vulnerabilități au aceeași cauză. Ambele sunt overflow-uri la compilarea expresiilor regulate și au fost raportate de același cercetător.

Calea prin fișierele Org-mode

Una dintre regulile de detecție publicate de GitLab se numește „Org mode render error burst”. Org-mode e un format de text structurat, venit din Emacs, cu extensia .org. GitLab îl afișează formatat în repository-uri și în wiki, la fel ca Markdown-ul.

Konfirmity, pe baza regulii de detecție, descrie calea astfel:

1. GitLab randează fișierele .org cu gem-ul org-ruby.
2. Gem-ul construiește o expresie regulată din cuvintele-cheie de pe linia #+TODO:, fără să le neutralizeze caracterele speciale (escaping).
3. Un cuvânt-cheie repetat de peste 32.767 de ori depășește capacitatea unui contor și produce o scriere în afara buffer-ului. Nu întâmplător, 32.767 e cea mai mare valoare a unui întreg cu semn pe 16 biți.
4. Scrierea poate fi transformată în execuție de cod ca utilizatorul git.

Precondiția: atacatorul are nevoie de un proiect public care conține fișierul .org construit special. Randarea lui nu cere autentificare. Tot după Konfirmity, o încercare poate fi silențioasă și nu prăbușește serverul în mod sigur, deci lipsa crash-urilor din loguri nu dovedește nimic.

Tradus în practică: pe o instanță cu înregistrare deschisă și cu voie de a crea proiecte publice, oricine își face un cont, urcă fișierul și declanșează apoi randarea fără să fie logat. Pe o instanță unde doar angajații au conturi, atacatorul are nevoie de un cont compromis sau de acces de scriere la un proiect public existent.

GitLab nu a confirmat oficial acești pași. Tratează-i ca pe cea mai detaliată descriere publică de până acum, nu ca pe lista completă a căilor de atac.

Ce obține atacatorul

Într-o instalare standard Omnibus, utilizatorul git rulează procesele aplicației: Puma, care servește interfața web și API-ul, și Sidekiq, care execută job-urile din fundal. Cod rulat ca git are, practic, acces la tot ce are aplicația:

• toate repository-urile de pe disc, inclusiv proiectele private;
• fișierul de secrete al aplicației, cu cheile care decriptează variabilele CI/CD păstrate în baza de date;
• conexiunea la baza de date, cu utilizatorii, token-urile și configurația;
• posibilitatea de a modifica cod și pipeline-uri, adică un atac pe lanțul de aprovizionare (supply chain) spre tot ce construiește și livrează instanța.

De aici vine S:C din vectorul CVSS. Componenta vulnerabilă e un parser de text, dar impactul ajunge la cheile de cloud, la credențialele de deployment și la producție.

Patru vulnerabilități critice în șase săptămâni

CVE-2026-110264 nu e un incident izolat. Între 10 septembrie și 21 octombrie, GitLab a reparat patru vulnerabilități cu scor de cel puțin 9.9 în produsele self-managed, iar una dintre ele a fost exploatată la o zi după patch.

10 septembrie: CVE-2026-85706, exploatată în mai puțin de o zi

Patch-ul din 10 septembrie a reparat un path traversal în API-ul de commit-uri al repository-ului. Un utilizator neautentificat putea citi fișiere arbitrare de pe server. Scor CVSS 10.0, versiuni afectate de la 18.7. Fix-ul a venit în 19.3.2, 19.2.6 și 19.1.8, iar backport-urile pentru 19.0.9 și 18.11.12 au apărut abia pe 23 septembrie.

Potrivit BleepingComputer, watchTowr a observat primele încercări în mediul real la circa o zi după patch, iar CISA a adăugat vulnerabilitatea în KEV. Pe 17 septembrie, alerta CSA AL-2026-123 semnala exploatarea activă raportată și un exploit public disponibil. Citirea de fișiere arbitrare pe un server GitLab înseamnă, de regulă, configurația și secretele lui.

2 octombrie: CVE-2026-90970 în AI Gateway

A doua vulnerabilitate, cu scor 9.9, a lovit AI Gateway, componenta pe care o rulezi când folosești GitLab Duo cu modele găzduite de tine. Potrivit The Hacker News, permitea execuție de comenzi pe serverele self-hosted și afecta gateway-ul de la 18.1.6 până înainte de 19.2.4, linia 19.3 înainte de 19.3.2 și linia 19.4 înainte de 19.4.1. Te privește doar dacă rulezi AI Gateway separat.

12 octombrie: CVE-2026-97229, prima problemă de regex

Patch-ul din 12 octombrie a reparat un overflow de întreg în compilatorul de expresii regulate din configurația CI/CD. Scor CVSS 10.0, raportat tot de joaxcar, afectând doar liniile 19.2, 19.3 și 19.4. Fix-ul: 19.4.2, 19.3.5 și 19.2.8.

Calea demonstrată de Rapid7 cere un fișier .gitlab-ci.yml malițios și o cale de repository cu caractere UTF-8, urcate pe o ramură dintr-un proiect public. Rapid7 notează că pe instanțele care permit crearea de proiecte publice, un cont obișnuit îndeplinește această condiție. Recomandarea lor a fost upgrade urgent, în afara ciclului normal de patch-uri.

De ce patch-ul din 12 octombrie nu te acoperă

CVE-2026-110264 e o vulnerabilitate separată, cu acoperire mult mai largă: de la 7.0, nu doar de la 19.2. Un server pe 19.4.2, 19.3.5 sau 19.2.8 a închis problema din CI/CD, dar rămâne vulnerabil la cea nouă și are nevoie de 19.4.3, 19.3.6 sau 19.2.9. Dacă ai actualizat acum zece zile și ai considerat subiectul închis, redeschide-l.

Ce versiune instalezi și cum faci upgrade-ul

Alegerea depinde de linia pe care ești acum. Diagrama de mai jos rezumă ce primește fiecare.

Liniile 19.3, 19.4 și 19.5

Instalează 19.3.6, 19.4.3 sau 19.5.1. Primești toate cele 12 fix-uri. Anunțul avertizează că 19.4.3 și 19.3.6 conțin migrări de bază de date, iar 19.4.3 are și migrări post-deploy. Pe o instalare cu un singur nod, asta înseamnă downtime, pentru că migrările trebuie să se termine înainte ca GitLab să pornească. Pe instalările cu mai multe noduri poți folosi procedura GitLab de upgrade fără downtime.

Liniile 18.11, 19.0, 19.1 și 19.2

Instalează 18.11.13, 19.0.10, 19.1.9 sau 19.2.9. Aceste backport-uri conțin doar fix-ul critic, după cum arată și tabelul Konfirmity. Închizi RCE-ul azi, dar cele două vulnerabilități de severitate ridicată rămân. Pune în plan mutarea pe 19.3 sau mai nou în săptămânile următoare.

18.10 și mai vechi

Nu există patch. Trebuie să urci pe o linie suportată, iar GitLab impune un traseu de upgrade cu opriri obligatorii între versiuni majore. De pe o versiune veche de câțiva ani, drumul până la 18.11.13 poate dura ore sau zile, cu backup-uri și verificări la fiecare oprire. Până termini, aplică măsurile temporare din secțiunea următoare.

Comenzile, pe tip de instalare

Începe prin a afla versiunea exactă. Pe o instalare Omnibus o citești direct de pe disc, iar pentru mai multe instanțe e mai comod să întrebi API-ul:

1# Omnibus: the exact version that is installed
2cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
3
4# Any installation type: ask the API (needs a personal access token)
5curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" "https://gitlab.example.com/api/v4/version"

1# Omnibus: the exact version that is installed
2cat /opt/gitlab/embedded/service/gitlab-rails/VERSION
3
4# Any installation type: ask the API (needs a personal access token)
5curl -s --header "PRIVATE-TOKEN: $GITLAB_TOKEN" "https://gitlab.example.com/api/v4/version"

Fă backup înainte de upgrade. Backup-ul GitLab nu include fișierele de configurare și secrete, așa că le copiezi separat:

1# Application data: repositories, database, uploads
2sudo gitlab-backup create
3
4# Configuration and secrets are not part of the backup above
5sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /root/

1# Application data: repositories, database, uploads
2sudo gitlab-backup create
3
4# Configuration and secrets are not part of the backup above
5sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /root/

Pe Debian și Ubuntu fixezi versiunea exactă de pe linia ta, ca managerul de pachete să nu sară pe alta:

1# Enterprise Edition on the 19.4 line; use gitlab-ce=19.4.3-ce.0 for Community Edition
2sudo apt-get update
3sudo apt-get install gitlab-ee=19.4.3-ee.0

1# Enterprise Edition on the 19.4 line; use gitlab-ce=19.4.3-ce.0 for Community Edition
2sudo apt-get update
3sudo apt-get install gitlab-ee=19.4.3-ee.0

În Docker, schimbi tag-ul imaginii și recreezi containerul cu aceleași volume:

1# Pull the patched image, set the same tag in docker-compose.yml, then recreate the container
2docker pull gitlab/gitlab-ee:19.4.3-ee.0
3docker compose up -d gitlab

1# Pull the patched image, set the same tag in docker-compose.yml, then recreate the container
2docker pull gitlab/gitlab-ee:19.4.3-ee.0
3docker compose up -d gitlab

În Kubernetes, chart-ul Helm are numerotare proprie, diferită de versiunea GitLab. Caută în documentația chart-ului versiunea care livrează 19.4.3 sau echivalentul de pe linia ta și fă upgrade la ea.

După upgrade, verifică din nou versiunea și deschide în zona de administrare pagina Monitoring, apoi Background migrations. Nu porni alt upgrade cât timp mai sunt migrări în așteptare acolo.

Dacă nu poți actualiza azi

Uneori upgrade-ul nu se poate face în aceeași zi: instanța e veche, migrările cer o fereastră de mentenanță sau echipa care o administrează e indisponibilă. Măsurile de mai jos îngustează calea de atac. Niciuna nu repară vulnerabilitatea.

Scoate GitLab de pe internetul public

Atacul cere acces de rețea la interfața web. Dacă instanța e folosită doar de echipa ta, pune-o în spatele unui VPN sau al unui proxy zero-trust ori restrânge accesul la adresele IP ale birourilor. E cea mai eficientă măsură temporară, pentru că elimină complet atacatorul anonim de pe internet. Verifică și ce mai e expus: runner-ele și integrările care apelează GitLab au nevoie de acces, deci fă lista lor înainte să închizi.

Închide înregistrarea și proiectele publice

Ambele căi cunoscute, cea prin .org și cea prin CI/CD, trec printr-un proiect public în care atacatorul poate scrie. Din zona de administrare, la Settings, General:

• la Sign-up restrictions, dezactivează înregistrarea liberă de conturi noi;
• la Visibility and access controls, bifează Public în Restricted visibility levels, ca utilizatorii fără drepturi de administrator să nu mai poată crea proiecte publice.

Setarea a doua nu schimbă proiectele publice existente. Fă lista lor și verifică cine are drept de scriere în fiecare:

1# Public projects on the instance (first 100; follow the X-Next-Page header for more)
2url="https://gitlab.example.com/api/v4/projects?visibility=public&per_page=100&simple=true"
3curl -s --header "PRIVATE-TOKEN: $GITLAB_ADMIN_TOKEN" "$url" | jq -r '.[].web_url'

1# Public projects on the instance (first 100; follow the X-Next-Page header for more)
2url="https://gitlab.example.com/api/v4/projects?visibility=public&per_page=100&simple=true"
3curl -s --header "PRIVATE-TOKEN: $GITLAB_ADMIN_TOKEN" "$url" | jq -r '.[].web_url'

Dacă un proiect public nu are motiv să fie public, mută-l pe Internal sau Private.

Ce nu rezolvă măsurile temporare

Un cont intern compromis rămâne un risc, pentru că vulnerabilitatea e în motor, nu în setarea de vizibilitate. Iar calea prin Org-mode e doar cea mai bine documentată public. GitLab nu a confirmat că e singura, iar orice loc în care aplicația compilează un pattern din text venit de la utilizator e, teoretic, o altă intrare. Măsurile temporare îți cumpără ore sau zile, nu săptămâni.

Cum verifici dacă ai fost deja atacat

Patch-ul închide ușa, dar nu spune dacă a intrat cineva între timp. Merită o verificare chiar și pe serverele actualizate în aceeași zi. Pe liniile 19.2-19.4, vulnerabilitatea din 12 octombrie are un PoC public din 13 octombrie, așa că un server rămas de atunci fără patch are motive în plus.

Regulile de detecție GitLab și logurile

GitLab a publicat două reguli de detecție pentru instanțele self-managed: „Onigmo native worker crash” și „Org mode render error burst”. SOC Prime subliniază că ele semnalează comportament suspect, nu confirmă o compromitere. Dacă nu ai un SIEM în care să le importi, poți căuta aceleași semnale direct în loguri:

1# Ruby prints "[BUG] Segmentation fault" when native code crashes a Puma or Sidekiq worker
2sudo zgrep -n "Segmentation fault" /var/log/gitlab/puma/puma_stderr.log* /var/log/gitlab/sidekiq/current
3
4# Requests for .org content that ended in a server error
5sudo zcat -f /var/log/gitlab/gitlab-rails/production_json.log* |
6  jq -c 'select(.status >= 500 and ((.path // "") | test("[.]org($|[?])"))) | {time, path, status, remote_ip}'

1# Ruby prints "[BUG] Segmentation fault" when native code crashes a Puma or Sidekiq worker
2sudo zgrep -n "Segmentation fault" /var/log/gitlab/puma/puma_stderr.log* /var/log/gitlab/sidekiq/current
3
4# Requests for .org content that ended in a server error
5sudo zcat -f /var/log/gitlab/gitlab-rails/production_json.log* |
6  jq -c 'select(.status >= 500 and ((.path // "") | test("[.]org($|[?])"))) | {time, path, status, remote_ip}'

Corelează rezultatele cu telemetria sistemului de operare. Semnalele pe care le recomandă SOC Prime: procese copil neașteptate pornite de Puma, Sidekiq sau Ruby, cum ar fi sh, bash, curl, wget sau nc, comenzi de shell sub conturile de serviciu, conexiuni de ieșire neobișnuite și chei SSH sau conturi de administrator noi.

Fișiere .org suspecte în repository-uri

O linie #+TODO: legitimă are câteva zeci de caractere. Una care declanșează overflow-ul are zeci de mii. Poți căuta astfel de linii direct în repository-urile de pe server, fără să clonezi nimic:

1# Default Omnibus storage path; inside Docker, run this in the container
2# Looks for very long #+TODO lines in .org files on branches, tags and merge request refs
3cd /var/opt/gitlab/git-data/repositories/@hashed || exit 1
4find . -type d -name '*.git' -prune -print | while read -r repo; do
5  git -c safe.directory='*' -C "$repo" for-each-ref --format='%(refname)' refs/heads refs/tags refs/merge-requests |
6  while read -r ref; do
7    git -c safe.directory='*' -C "$repo" grep -l -E '^#[+](SEQ_|TYP_)?TODO:.{1000,}' "$ref" -- '*.org' 2>/dev/null |
8      sed "s|^|$repo |"
9  done
10done

1# Default Omnibus storage path; inside Docker, run this in the container
2# Looks for very long #+TODO lines in .org files on branches, tags and merge request refs
3cd /var/opt/gitlab/git-data/repositories/@hashed || exit 1
4find . -type d -name '*.git' -prune -print | while read -r repo; do
5  git -c safe.directory='*' -C "$repo" for-each-ref --format='%(refname)' refs/heads refs/tags refs/merge-requests |
6  while read -r ref; do
7    git -c safe.directory='*' -C "$repo" grep -l -E '^#[+](SEQ_|TYP_)?TODO:.{1000,}' "$ref" -- '*.org' 2>/dev/null |
8      sed "s|^|$repo |"
9  done
10done

Repository-urile wiki apar în aceeași căutare, cu sufixul .wiki.git. Un rezultat îți dă calea internă și ramura. Proiectul căruia îi aparține îl afli din consola Rails (sudo gitlab-rails console), cu ProjectRepository.find_by(disk_path: '@hashed/ab/cd/<hash>').project.full_path, unde scrii calea fără sufixul .git sau .wiki.git. Un fișier aflat pe o ramură ștearsă între timp nu mai apare, deci căutarea e un indiciu, nu o dovadă de absență.

Chei SSH, conturi admin și cron

Cineva care a rulat cod ca git are motive să-și păstreze accesul. Trei locuri simple de verificat:

1# GitLab-managed keys start with command="..."; a bare key here gives a direct shell as git
2sudo grep -vE '^(command=|#|$)' /var/opt/gitlab/.ssh/authorized_keys
3
4# Scheduled jobs for the git user; a standard Omnibus install has none
5sudo crontab -l -u git
6
7# Administrator accounts, newest first
8url="https://gitlab.example.com/api/v4/users?admins=true&order_by=created_at&sort=desc"
9curl -s --header "PRIVATE-TOKEN: $GITLAB_ADMIN_TOKEN" "$url" | jq -r '.[] | .created_at + " " + .username'

1# GitLab-managed keys start with command="..."; a bare key here gives a direct shell as git
2sudo grep -vE '^(command=|#|$)' /var/opt/gitlab/.ssh/authorized_keys
3
4# Scheduled jobs for the git user; a standard Omnibus install has none
5sudo crontab -l -u git
6
7# Administrator accounts, newest first
8url="https://gitlab.example.com/api/v4/users?admins=true&order_by=created_at&sort=desc"
9curl -s --header "PRIVATE-TOKEN: $GITLAB_ADMIN_TOKEN" "$url" | jq -r '.[] | .created_at + " " + .username'

Dacă folosești căutarea rapidă a cheilor SSH în baza de date, fișierul authorized_keys poate fi gol sau lipsă, ceea ce e normal. Verifică în acest caz cheile noi din profilurile utilizatorilor și token-urile de acces personale create recent.

Dacă găsești urme

Nu repara serverul pe loc. Un atacator cu acces ca git poate lăsa modificări greu de găsit în codul aplicației, așa că varianta sigură e o instalare curată, la versiunea reparată, cu datele restaurate dintr-un backup anterior compromiterii.

Apoi rotește secretele, începând cu cele care deschid producția:

• variabilele CI/CD: chei de cloud, credențiale de deployment, token-uri de API;
• token-urile de autentificare ale runner-elor;
• deploy keys și deploy tokens;
• token-urile de acces personale, de grup și de proiect;
• secretele aplicațiilor OAuth configurate în instanță.

Dacă repository-urile sau variabilele conțineau date personale, cum ar fi dump-uri de baze de date sau exporturi de clienți, ai probabil și obligația de a notifica ANSPDCP în cel mult 72 de ore de când afli de incident, conform articolului 33 din GDPR, dacă încălcarea prezintă un risc pentru persoanele vizate.

Ce înseamnă pentru echipele care își găzduiesc GitLab

Aceeași zi, 21 octombrie, a adus și PHP2Shell în PHP și vulnerabilitatea Brotli din Node.js, la o săptămână după patch-ul critic Next.js din 14 octombrie. Tiparul e același: problema stă sub codul tău, într-un runtime sau într-o dependență, și ajunge în urmă ani întregi. Pentru GitLab, câteva concluzii rămân valabile și după patch.

Ritmul de patch-uri se măsoară acum în zile

Patru vulnerabilități critice în șase săptămâni și o exploatare la o zi după patch înseamnă că o fereastră de mentenanță lunară nu mai ajunge. Ai nevoie de un proces prin care o instanță de producție poate fi actualizată în 24-48 de ore: backup automat, mediu de test, procedura de upgrade scrisă. Abonează-te la fluxul RSS al patch release-urilor GitLab, ca anunțul să ajungă la tine, nu la un cititor de știri a doua zi.

Secretele din CI/CD sunt ținta reală

Pentru un atacator, serverul GitLab e drumul spre ce e în variabilele CI/CD. Cu cât acolo stau mai puține chei statice cu durată lungă, cu atât o compromitere costă mai puțin. Folosește variabile protejate, limitate la ramurile protejate, și înlocuiește cheile de cloud fixe cu credențiale de scurtă durată obținute prin OIDC, cu id_tokens în pipeline. Rotirea de secrete după un incident devine atunci o listă scurtă.

GitLab self-managed sau GitLab.com

La release-urile din 12 și 21 octombrie, GitLab.com era deja reparat când a apărut anunțul. Self-managed înseamnă că fereastra dintre anunț și patch e a ta. Ai motive întemeiate să rămâi pe propria instanță, cum ar fi rezidența datelor, rețelele izolate sau costul. Dar decizia trebuie să includă și capacitatea reală a echipei de a aplica patch-uri critice în aceeași zi. Dacă GitLab-ul tău stă pe internet doar din comoditate, mutarea lui în spatele unui VPN reduce expunerea la următoarea vulnerabilitate, nu doar la aceasta.

Întrebări frecvente

Ce este CVE-2026-110264?

E o vulnerabilitate critică în GitLab CE și EE self-managed, cu scor CVSS 10.0. Un overflow de întreg la compilarea unei expresii regulate permite, în anumite condiții, execuție de cod pe server fără autentificare. Afectează toate versiunile de la 7.0 și e reparată în 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 și 18.11.13, publicate pe 21 octombrie 2026.

Am instalat patch-ul din 12 octombrie. Sunt protejat?

Nu. Patch-ul din 12 octombrie a reparat CVE-2026-97229, o problemă asemănătoare din configurația CI/CD. CVE-2026-110264 e separată și afectează și versiunile 19.4.2, 19.3.5 și 19.2.8. Ai nevoie de 19.4.3, 19.3.6 sau 19.2.9.

Folosesc GitLab.com. Trebuie să fac ceva?

Nu pentru această vulnerabilitate. GitLab.com rulează deja versiunea reparată, iar tenanții GitLab Dedicated pe 19.3.5-internal0, 19.4.2-internal0 sau mai nou au fix-ul. Componentele pe care le rulezi tu lângă GitLab.com, cum ar fi runner-ele sau un AI Gateway self-hosted, au advisory-uri proprii, pe care le urmărești separat.

Am GitLab 17 sau mai vechi. Ce fac?

Nu există patch pentru liniile mai vechi de 18.11. Urci pe 18.11.13 sau pe o versiune 19.x reparată, respectând opririle obligatorii din traseul de upgrade GitLab. Până termini, scoate instanța de pe internetul public și blochează înregistrarea și proiectele publice.

Există un exploit public pentru CVE-2026-110264?

Pe 22 octombrie a apărut pe GitHub un repository care pretinde un exploit, dar nimic nu confirmă că funcționează, iar astfel de repository-uri sunt des false sau conțin malware. Nu rula cod de acest tip pe mașini de lucru. Pentru vulnerabilitatea înrudită din 12 octombrie, Rapid7 a reprodus execuția de cod.

Cum aflu rapid ce versiune de GitLab rulez?

Pe o instalare Omnibus, rulează cat /opt/gitlab/embedded/service/gitlab-rails/VERSION. Pe orice tip de instalare, apelează /api/v4/version cu un token valid sau deschide, ca administrator, panoul Components din zona de administrare.

Următorul pas

Fă azi inventarul instanțelor GitLab self-managed, cu versiunea exactă a fiecăreia, și începe cu cele accesibile de pe internet. Actualizează, apoi rulează verificările de urme chiar și pe serverele patch-uite rapid. Pe instanțele de pe liniile 19.2-19.4 rămase fără patch-ul din 12 octombrie, verificarea e obligatorie: pentru acea vulnerabilitate exista un PoC public din 13 octombrie. Pentru alte analize de vulnerabilități și pașii de remediere, vezi categoria Securitate aplicații web, eticheta Securitatea datelor și articolele despre produse SaaS.