Blog Keamanan Siber

Celah GitLab Kini Dieksploitasi: Periksa Juga Versi Ruby

Ditulis oleh Merakit Indonesia

31 Oktober 2026 7 menit baca

Celah GitLab Kini Dieksploitasi: Periksa Juga Versi Ruby

Daftar isi· 7 bagian

1Dari tambalan ke serangan nyata
2Akar masalahnya ada di mesin regex Ruby
3Pelajaran dari insiden Alpine Linux
4Apa artinya bagi tim pengembang?
5Pertanyaan yang sering muncul
6Penutup
7Sumber

Celah GitLab CVE-2026-97229 berskor CVSS 10.0 kini dipakai dalam serangan nyata. CISA memasukkannya ke katalog celah yang sudah dieksploitasi pada 29 Oktober 2026, setelah Alpine Linux melaporkan percobaan serangan ke server GitLab miliknya. Bagi GitLab yang dipasang dengan Ruby sendiri, memperbarui GitLab saja belum menutup celah ini.

Dari tambalan ke serangan nyata

GitLab merilis perbaikan untuk CVE-2026-97229 pada 12 Oktober 2026 lewat versi 19.4.2, 19.3.5, dan 19.2.8. Menurut catatan rilis GitLab, celah ini berupa integer overflow di compiler ekspresi reguler (regex) untuk CI/CD. Pengguna tanpa autentikasi dapat memakainya untuk menjalankan kode di server GitLab. Kami sudah membahas versi terdampak dan langkah pembaruannya dalam artikel celah kritis GitLab skor 10 yang terbit 14 Oktober.

Saat artikel itu terbit, belum ada laporan eksploitasi. Status tersebut kini berubah. Pada 29 Oktober 2026, CISA menambahkan CVE-2026-97229 ke katalog Known Exploited Vulnerabilities (KEV), daftar celah yang terbukti dipakai penyerang. Menurut The Hacker News, instansi sipil federal Amerika Serikat diminta menerapkan perbaikan paling lambat 1 November 2026.

Di antara dua tanggal itu, GitLab juga merilis perbaikan kedua pada 21 Oktober untuk celah sejenis, CVE-2026-110264, yang juga berskor 10.0. Menurut catatan rilis 19.5.1, celah kedua ini memengaruhi semua versi sejak GitLab 7.0. Versi perbaikannya adalah 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, dan 18.11.13. Karena itu, sasaran pembaruan yang aman saat ini adalah rilis 21 Oktober atau yang lebih baru, sesuai cabang yang Anda pakai.

Akar masalahnya ada di mesin regex Ruby

Hal yang membuat kasus ini berbeda dari celah biasa adalah letak kesalahannya. Alpine Linux menjelaskan bahwa sumber masalahnya ada di Onigmo, mesin regex bawaan bahasa pemrograman Ruby. GitLab ditulis dengan Ruby, sehingga regex dari berkas konfigurasi CI ikut diproses oleh mesin tersebut.

Perbaikannya berupa serangkaian tambalan untuk Ruby. GitLab memasang tambalan itu ke dalam salinan Ruby yang dibawa paket dan image resminya. Organisasi yang memasang GitLab dari kode sumber, atau membangun kontainer sendiri dengan Ruby standar, tidak otomatis mendapatkan perbaikan tersebut.

Proyek Ruby baru merilis perbaikannya sendiri pada 23 Oktober 2026 lewat Ruby 4.0.9, 3.4.12, dan 3.3.13, seperti diumumkan di milis oss-security. Menurut The Hacker News, Ruby 4.0.8 belum memuat seluruh perbaikan, dan Ruby 3.2 ke bawah tidak akan mendapat perbaikan karena masa dukungannya berakhir pada 1 April 2026.

Risikonya juga menjangkau aplikasi Ruby lain. Pengumuman Ruby menyebut aplikasi terdampak bila menyusun regex dari teks yang dapat dikendalikan penyerang, misalnya lewat Regexp.new atau dengan menyisipkan masukan pengguna ke dalam pola. Aplikasi yang hanya memakai pola tulisan pengembangnya sendiri tidak terdampak. Pembatasan waktu Regexp.timeout dan batas panjang pola juga tidak dapat diandalkan untuk menahan celah ini.

Pelajaran dari insiden Alpine Linux

Alpine Linux, distribusi Linux yang banyak dipakai sebagai dasar kontainer Docker, menerbitkan laporan insiden pada 28 Oktober 2026. Laporan itu memperlihatkan bagaimana organisasi yang sudah berusaha memperbarui pun dapat tetap terbuka.

Linimasa insiden GitLab Alpine Linux: pembaruan keliru ke 19.3.4, serangan 20 dan 21 Oktober, versi 19.3.6 masih rentan, server dibangun ulang 28 Oktober

Pada 13 Oktober, tim Alpine keliru memasang versi 19.3.4, padahal perbaikan ada di 19.3.5. Pada 20 Oktober, penyerang mendaftarkan akun baru dan mulai menyelidiki server. Serangan utama terjadi pada 21 Oktober lewat konfigurasi CI yang dirancang khusus. Proses pekerja GitLab mogok delapan kali, dan dalam empat di antaranya serangan sempat melewati tahap awal sebelum gagal di tahap berikutnya. Penyerang juga mengunduh image kontainer GitLab milik Alpine, yang menurut Alpine menandakan upaya menyesuaikan serangan dengan versi yang persis sama.

Pada 22 Oktober, Alpine memperbarui GitLab ke 19.3.6. Pembaruan itu ternyata belum cukup karena image mereka memakai Ruby standar yang belum ditambal. Tim baru menyadarinya pada 26 Oktober, setelah penyerang kembali mencoba masuk pada 25 dan 26 Oktober tanpa hasil.

Alpine tidak menemukan bukti bahwa penyerang berhasil menjalankan kode, tetapi juga tidak dapat memastikannya. Menurut laporan tersebut, serangan yang berhasil tidak meninggalkan proses mogok maupun jejak di log web. Karena itu, server GitLab mereka diperlakukan sebagai sudah disusupi. Server dibangun ulang dari nol, semua kata sandi pengguna diatur ulang, dan kunci rahasia GitLab diganti pada 28 Oktober. GitLab Alpine kemudian dibuka kembali dengan versi 19.3.7.

Alpine juga memeriksa hal yang paling dikhawatirkan pengguna: apakah paket dan rilisnya diubah. Riwayat repositori aports dicocokkan dengan salinan milik pengembang dan 45 mesin build. Hasilnya, paket yang dibangun 20 hingga 24 Oktober serta rilis 21 Oktober dinyatakan tidak berubah. Kunci penandatangan paket juga tidak pernah disimpan di server GitLab.

Laporan itu juga terbuka soal batas kepastiannya. Sebagian log dari hari serangan sudah hilang, dan koneksi keluar dari server tidak dicatat. Alpine kini berencana mencatat koneksi keluar dari server GitLab dan menyimpan log lebih dari 14 hari.

Apa artinya bagi tim pengembang?

Banyak kampus, dinas, rumah sakit, dan perusahaan perangkat lunak di Indonesia memasang GitLab di server sendiri agar kode sumber tetap di infrastruktur internal. Server itu biasanya juga menyimpan variabel CI/CD, token runner, dan kredensial integrasi. Alpine mencatat bahwa data semacam itu, beserta repositori privat dan hash kata sandi, berpotensi terbuka bila serangan berhasil.

Langkah pertama adalah memastikan cara GitLab Anda dipasang, karena hal itu menentukan apa yang perlu diperbarui.

Tabel cara pemasangan GitLab: paket resmi cukup diperbarui ke rilis 21 Oktober, instalasi dari kode sumber juga butuh Ruby 3.3.13, 3.4.12, atau 4.0.9, image Alpine perlu ditarik ulang

Pengguna GitLab.com tidak perlu bertindak karena layanan itu sudah ditambal. Untuk instalasi mandiri, lakukan langkah berikut.

Perbarui GitLab ke rilis 21 Oktober atau yang lebih baru, misalnya 19.5.1, 19.4.3, atau 19.3.6 sesuai cabang Anda. Periksa versi di semua node aplikasi.
Periksa versi Ruby bila GitLab tidak dipasang dari paket resmi. Instalasi dari kode sumber atau kontainer buatan sendiri memerlukan Ruby 3.3.13, 3.4.12, 4.0.9, atau rilis yang lebih baru di seri yang sama. Pengguna image alpinelinux/gitlab perlu menarik ulang tag 19.3.6, karena menurut Alpine image yang diunduh sebelum 27 Oktober masih rentan.
Telusuri tanda percobaan serangan. GitLab menerbitkan aturan deteksi “Onigmo native worker crash” untuk instalasi mandiri. Proses pekerja yang mogok berulang, galat 502, dan job CI yang gagal tanpa sebab dari akun baru layak diperiksa.
Ganti rahasia bila server lama tertinggal dan terbuka ke internet. Prioritaskan variabel CI/CD, token runner, token akses pribadi, serta kredensial webhook dan mirror. Bila ada tanda serangan, pertimbangkan membangun ulang server seperti yang dilakukan Alpine.

Untuk jangka panjang, Alpine menyarankan agar rilis keamanan kritis GitLab dipasang dalam satu hari, sekaligus memeriksa apakah rilis itu membawa tambalan komponen seperti Ruby yang harus diterapkan sendiri. Pelajaran ini berlaku bagi aplikasi apa pun yang dibangun dari banyak komponen. Tim yang merawat aplikasi Ruby sendiri juga perlu memeriksa kode yang menyusun regex dari masukan pengguna. Bila tim internal belum sempat menata alur pembaruan seperti ini, layanan keamanan siber dan pengembangan aplikasi web dapat membantu meninjau server dan pipeline yang Anda kelola.

Pertanyaan yang sering muncul

Apakah server GitLab kami pasti sudah disusupi?

Tidak ada dasar untuk menyimpulkan itu. Alpine sendiri tidak menemukan bukti keberhasilan serangan. Namun, bila server Anda terbuka ke internet dan masih memakai versi rentan setelah 12 Oktober, perlakukan rahasia di dalamnya sebagai berisiko dan ganti secara bertahap.

Kami sudah memasang GitLab 19.3.6. Apakah sudah aman?

Bila GitLab dipasang dari paket atau image resmi GitLab, versi itu sudah membawa Ruby yang ditambal. Kasus Alpine menunjukkan 19.3.6 tetap rentan bila dijalankan dengan Ruby standar yang belum diperbarui. Periksa versi Ruby di server Anda.

Apakah aplikasi Ruby on Rails kami ikut terdampak?

Hanya bila aplikasi menyusun regex dari teks yang dapat dikendalikan pengguna. Aplikasi yang hanya memakai pola tetap tulisan pengembang tidak terdampak. Memperbarui Ruby ke versi perbaikan tetap langkah yang paling aman.

Penutup

Kasus GitLab dan Alpine menunjukkan bahwa nomor versi aplikasi belum tentu menggambarkan keamanan seluruh sistem. Komponen di bawahnya, seperti bahasa pemrograman dan pustaka, perlu didata dan diperbarui dengan disiplin yang sama. Bila Anda ingin meninjau kesiapan server pengembangan di organisasi Anda, tim Merakit siap berdiskusi lewat halaman kontak.