Pengembang bahasa pemrograman Ruby telah meluncurkan pembaruan versi 4.0.9, 3.4.12, dan 3.3.13 guna membenahi tiga masalah teknis pada Onigmo, mesin ekspresi reguler bawaan di dalamnya. Ketiga kerusakan tersebut menjadi akar dari empat celah keamanan berisiko tinggi yang ditambal oleh platform GitLab selama sebulan belakangan.
Pihak GitLab menemukan bahwa pola ekspresi reguler yang dirancang khusus dapat merusak alokasi memori ketika Ruby mengompilasinya. Kelemahan ini berisiko membuka jalan bagi pihak luar untuk mengeksekusi kode perintah arbitrary secara ilegal langsung pada server pengelola.
Tim Ruby menegaskan bahwa bahaya ini mengancam setiap aplikasi yang menyusun pola ekspresi reguler menggunakan string masukan yang dikendalikan oleh penyerang, bukan terbatas pada sistem GitLab semata.
Aplikasi Mana Saja yang Terkena Dampak
Dalam rilis imbauan keamanannya, tim Ruby memaparkan bahwa program baru dianggap rentan apabila memproses kompilasi regex memakai data teks yang dapat dimanipulasi peretas. Kondisi tersebut tercipta saat aplikasi memasukkan teks tersebut ke dalam Regexp.new, Regexp.union, maupun Regexp.compile, atau menyisipkannya melalui interpolasi sintaks seperti /#{input}/.
Adapun perangkat lunak yang hanya menggunakan pola ekspresi reguler statis ciptaan pengembangnya sendiri sepenuhnya berada di posisi aman dari ancaman ini.
Ruby resmi membenahi kesalahan sistem ini pada varian 4.0.9, 3.4.12, dan 3.3.13. Rilis edisi 3.4.12 dan 3.3.13 tercatat sebagai versi perdana di lini masing-masing yang menyertakan perbaikan untuk ketiga galat tersebut.
Versi terdahulu yang dirilis pada pekan yang sama, yakni 4.0.8, rupanya belum mencakup solusi bagi salah satu cacat berkode CVE-2026-110264. Oleh sebab itu, seluruh pemakai seri 4.0 sangat disarankan langsung beralih memasang edisi 4.0.9.
Sementara itu, seri Ruby 3.2 beserta edisi sebelumnya tidak akan memperoleh tambalan pengaman apa pun. Masa dukungan untuk Ruby 3.2 telah resmi berakhir pada 1 April 2026, ditandai dengan rilis 3.2.11 sebagai varian penutup. Pihak pengembang menyarankan pengguna untuk segera bermigrasi menuju versi 3.4 atau 4.0.
Bagi pengelola sistem yang belum dapat menerapkan peningkatan versi dalam waktu dekat, imbauan resmi meminta penghentian seluruh aktivitas kompilasi regex yang bersumber dari masukan tak tepercaya.
Dua metode mitigasi umum yang kerap dianggap efektif ternyata tidak mampu membendung masalah ini. Penyetelan batas durasi melalui parameter Regexp.timeout terbukti gagal menangkis gangguan. Selain itu, pembatasan panjang karakter regex juga tidak menjamin keamanan, mengingat rangkaian pola yang berukuran sangat pendek pun terbukti mampu memicu terjadinya eror.
Kronologi Masuknya Galat ke Platform GitLab
Platform GitLab memproses kompilasi pola regex kiriman pengguna secara rutin, contohnya pada sintaks pengaturan sistem otomasi CI/CD. Pengelola menemukan manipulasi pola ini sanggup merusak struktur memori selama fase kompilasi Ruby berlangsung, memicu terbitnya empat catatan CVE antara tanggal 23 September hingga 21 Oktober yang masing-masing diperbaiki melalui paket distribusi Ruby tertambal.
Dua celah perdana diumumkan pada 23 September, mengharuskan akun pengguna melakukan login terlebih dahulu, dan memperoleh skor keparahan 9,9 dari skala 10. Dua masalah berikutnya menyusul pada Oktober, yaitu CVE-2026-97229 pada tanggal 12 dan CVE-2026-110264 pada tanggal 21, yang keduanya dapat dieksploitasi tanpa kepemilikan akun dengan raihan skor maksimal 10,0. Cacat CVE-2026-110264 berdampak langsung pada seluruh edisi GitLab mulai versi 7.0 ke atas.
Seorang peneliti keamanan siber dengan identitas akun joaxcar melaporkan keempat kelemahan sistem tersebut via program pemburu bug GitLab. Sampai dengan 23 Oktober, belum ada satu pun dari keempatnya yang dimasukkan ke daftar Known Exploited Vulnerabilities kepunyaan instansi CISA.
Status Penomoran CVE dari Pihak Ruby
Hingga saat ini, pihak Ruby belum mengajukan nomor identitas CVE khusus atas pembaruan ini, “setidaknya untuk saat ini,” terang mereka sembari mengarahkan para administrator untuk memantau status perkembangan melalui empat kode CVE milik GitLab.
Langkah penundaan ini memunculkan celah teknis bagi pengelola yang memakai alat pemindai keamanan berbasis katalog CVE. Dokumen resmi catatan kerentanan GitLab hanya mengidentifikasi GitLab sebagai perangkat lunak terdampak, sehingga pemindai otomatis yang memeriksa kesesuaian instalasi Ruby tidak menemukan keterkaitan data yang cocok.
Padahal di masa lalu, Ruby sempat memperlakukan jenis gangguan serupa ini sebagai isu kerentanan formal, terbukti dengan pemberian kode identitas CVE pada perbaikan di tahun 2022 serta 2024, kendati praktik memproses pola masukan luar sudah lama dianggap berisiko.
Buku panduan dokumentasi resminya saat ini masih mengelompokkan risiko masukan teks tidak tepercaya semata-mata sebagai bahaya penolakan layanan (denial of service). Tim Ruby memastikan akan memperbarui buletin mereka bila pengajuan kode identitas CVE dilakukan di kemudian hari.
Instruksi Khusus Pengelola Layanan GitLab
Seluruh instalasi peladen GitLab mandiri (self-managed) diwajibkan memperbarui paket ke edisi yang memperbaiki celah CVE-2026-110264. GitLab telah meluncurkan tambalan tersebut pada 21 Oktober dan menerapkannya mundur hingga versi pendukung 18.11.13.
Layanan berbasis cloud GitLab.com dipastikan telah memakai versi aman terkini, sedangkan penyewa GitLab Dedicated pada rilis internal baru tidak memerlukan penyesuaian tambahan apa pun, jelas perwakilan GitLab. Berhubung platform mengemas bundel Ruby miliknya sendiri dan menambalnya langsung di sana, pemasangan versi GitLab terbaru ini otomatis menuntaskan kerentanan.
Selain pembaruan kode, pengembang GitLab juga membagikan aturan deteksi keamanan resmi yang dapat diimplementasikan administrator mandiri guna mengenali potensi indikasi percobaan eksploitasi di lingkungan masing-masing.