Atacatorii au început să exploateze o vulnerabilitate GitLab de severitate maximă, potrivit Agenției pentru Securitate Cibernetică și Infrastructură din Statele Unite (CISA). Vulnerabilitatea fusese remediată de GitLab la începutul acestei luni, iar exploatarea activă a fost semnalată vineri, 30 octombrie 2026. Pentru organizațiile care folosesc GitLab, existența patch-ului nu înseamnă eliminarea riscului cât timp actualizarea nu a fost aplicată.
Avertizarea CISA
Potrivit CISA, vulnerabilitatea GitLab de severitate maximă este deja utilizată în atacuri. Aceasta este informația centrală a materialului consultat. Sursa nu oferă detalii despre vectorul de atac, amploarea campaniei sau identitatea atacatorilor. Lipsa acestor detalii nu reduce gravitatea semnalului: faptul că exploatarea a început justifică o reacție imediată.
Exploatarea nu mai este o ipoteză: o vulnerabilitate GitLab de severitate maximă, deja remediată, este folosită în atacuri, potrivit CISA.
Natura vulnerabilității
Sursa califică problema drept „maximum severity”, adică severitate maximă. Este o formulare care indică un risc ridicat, dar materialul nu oferă un scor CVSS, un scor EPSS sau un identificator CVE. Prin urmare, articolul nu atribuie vulnerabilității un număr pe care sursa nu îl menționează. Elementul esențial este cronologia: remedierea exista la începutul lunii, însă exploatarea a fost semnalată abia acum. Un patch disponibil nu protejează sistemele care nu îl instalează, iar atacatorii pot exploata exact această diferență.
Cine este expus
Orice organizație care rulează GitLab și nu a aplicat remedierea menționată trebuie să considere că sistemele sale pot fi vizate. Riscul nu privește doar echipa tehnică: o compromitere poate avea consecințe asupra activității și asupra încrederii clienților. Decizia de actualizare aparține și nivelului de conducere, nu doar administratorilor.
Materialul nu precizează versiunile afectate, configurațiile vizate sau condițiile exacte în care exploatarea reușește. De aceea, prima verificare trebuie făcută în inventarul intern, nu pe baza unor presupuneri. Fiecare instanță GitLab trebuie identificată, iar starea ei de actualizare confirmată cu dovezi.
Plan de remediere
- Identificați toate instanțele GitLab, inclusiv cele din medii de testare și proiecte interne.
- Aplicați actualizarea care conține remedierea publicată de GitLab la începutul acestei luni.
- Verificați versiunea instalată și confirmați că remedierea este activă pe fiecare sistem.
- Restrângeți accesul la interfețele GitLab expuse și revizuiți conturile administrative.
- Păstrați jurnalele și investigați activitatea anormală din perioada de expunere.
Aceste măsuri reduc fereastra de expunere, dar nu înlocuiesc o evaluare completă. Sursa nu oferă dovezi că o anumită configurație este sigură în lipsa patch-ului. Prioritatea este clară: aplicarea remedierii, verificarea ei și monitorizarea consecințelor. Organizațiile care nu pot confirma că au făcut acest lucru ar trebui să trateze vulnerabilitatea ca pe un incident potențial, nu ca pe o simplă actualizare întârziată.
