Ruby corectează trei bug-uri din motorul regex Onigmo, cauza a patru vulnerabilități RCE critice în GitLab

Ruby a lansat versiunile 4.0.9, 3.4.12 și 3.3.13 pentru a elimina trei erori de siguranță a memoriei din Onigmo, motorul de expresii regulate integrat în limbaj. Aceleași bug-uri stau la baza a patru vulnerabilități critice de execuție de cod la distanță (RCE) pe care GitLab le-a corectat între sfârșitul lui septembrie și sfârșitul lui octombrie 2026.

Ce s-a întâmplat

Problemele apar în etapa în care Ruby compilează o expresie regulată. Un șablon construit special poate corupe memoria în timpul compilării, iar în anumite condiții această corupere poate fi transformată în execuție de cod pe server.

GitLab a fost primul afectat, pentru că platforma compilează șabloane furnizate chiar de utilizatori, de exemplu expresiile regulate din configurațiile CI/CD. Compania a remediat problema de patru ori, de fiecare dată livrând o copie corectată de Ruby:

Două CVE-uri publicate pe 23 septembrie – ambele necesită un cont autentificat și au scorul CVSS 9,9.
CVE-2026-97229 (12 octombrie) și CVE-2026-110264 (21 octombrie) – ambele pot fi atinse fără autentificare și au scorul maxim, 10,0. CVE-2026-110264 afectează toate versiunile GitLab începând cu 7.0.

La data de 23 octombrie, niciuna dintre cele patru nu fusese inclusă în catalogul CISA Known Exploited Vulnerabilities și nu avem cunoștință de exploatări confirmate în mediul real.

De ce contează dincolo de GitLab

Este o problemă a Ruby, nu doar a GitLab. Orice aplicație Ruby este expusă dacă construiește o expresie regulată dintr-un șir de caractere controlat de un atacator – de exemplu, dacă transmite date de la utilizator către Regexp.new, Regexp.union sau Regexp.compile, ori le interpolează într-un șablon de tipul /#{input}/. Aplicațiile care folosesc doar expresii regulate scrise de propriii dezvoltatori nu sunt afectate.

Două măsuri care par logice nu ajută aici:

Regexp.timeout limitează durata potrivirii, dar aceste bug-uri se declanșează la compilare, înainte ca vreun timeout să intre în joc.
Limitarea lungimii șablonului nu e de încredere, pentru că și șabloanele scurte pot declanșa bug-urile.

Există și un punct orb pentru echipele de securitate. Ruby nu a solicitat, deocamdată, identificatori CVE proprii pentru aceste remedieri și îi îndrumă pe utilizatori către cele patru CVE-uri GitLab. Acele înregistrări menționează doar GitLab ca produs afectat, așa că un scanner care compară datele CVE cu versiunile Ruby instalate nu va găsi nimic de semnalat. Documentația Ruby încă tratează șabloanele nesigure în principal ca un risc de tip denial-of-service, deși proiectul a emis în trecut CVE-uri pentru bug-uri similare ale motorului.

Ce trebuie făcut

Pentru aplicațiile Ruby:

Actualizați: Ruby 4.0 → 4.0.9, Ruby 3.4 → 3.4.12, Ruby 3.3 → 3.3.13. Versiunea 4.0.8, lansată în aceeași săptămână, nu conține una dintre remedieri, așa că treceți direct la 4.0.9. Versiunile 3.4.12 și 3.3.13 sunt primele din ramurile lor care includ vreuna dintre cele trei corecturi.
Ruby 3.2 și versiunile mai vechi nu vor primi corecturi – 3.2 a ajuns la sfârșitul ciclului de viață pe 1 aprilie 2026. Planificați migrarea la 3.4 sau 4.0.
Până la actualizare, nu mai compilați expresii regulate din date nesigure. Căutați în cod Regexp.new, Regexp.union, Regexp.compile și șabloane interpolate alimentate din datele cererilor.
Nu vă bazați pe alertele de dependențe bazate pe CVE pentru acest caz – verificați direct versiunea de Ruby, inclusiv cea inclusă în imaginile de containere.

Pentru GitLab găzduit intern (self-managed):

Instalați o versiune care corectează CVE-2026-110264: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10 sau 18.11.13. Deoarece GitLab vine cu propria versiune de Ruby, actualizarea GitLab aplică și remedierea.
GitLab.com este deja corectat, iar clienții GitLab Dedicated aflați pe versiuni interne recente nu trebuie să facă nimic.
Folosiți regulile de detecție publicate de GitLab pentru a verifica jurnalele în căutarea unor tentative de exploatare, mai ales pe instanțele expuse la internet.

Astfel de bug-uri trăiesc în spațiul dintre codul vostru și mediul de execuție de dedesubt – exact acolo unde fluxurile de CVE tac. Serviciul nostru de code review asistat de AI urmărește unde ajung datele controlate de utilizator în operații periculoase, precum compilarea dinamică a expresiilor regulate, astfel încât această clasă de probleme să fie identificată direct în codul vostru, nu abia după ce un furnizor publică un avertisment.