Pada 21 Oktober 2026, GitLab merilis perbaikan untuk celah yang memungkinkan penyerang menjalankan kode di server self-managed tanpa perlu login. Yang membuatnya luar biasa bukan skornya, meski skornya maksimal: 10,0. Yang membuatnya luar biasa adalah jangkauannya, yaitu setiap versi GitLab sejak 7.0 yang dirilis pada 2014.

Bagi tim yang menganggap "kami sudah update bulan lalu, jadi aman", ada satu detail yang perlu dibaca dua kali. Pembaruan 12 Oktober hanya mencakup versi 19.2 ke atas. Versi perbaikan yang baru berada satu patch di atasnya, sehingga instalasi yang diupdate sembilan hari sebelumnya masuk rentang terdampak lagi.

Apa yang Rusak

CVE-2026-110264 dinilai 10,0 pada skala CVSS. Menurut GitLab, pada kondisi tertentu celah ini memungkinkan pengguna tanpa autentikasi menjalankan kode sembarang di server akibat integer overflow saat kompilasi ekspresi reguler yang dibuat khusus. GitLab tidak menjelaskan kondisi apa yang dimaksud.

Bagian yang gagal adalah kompiler ekspresi reguler Ruby bawaan, bernama Onigmo, yang dikemas dan dipatch GitLab di dalam paketnya sendiri. Karena GitLab mengirim mesin itu di setiap rilisnya, kelemahannya ikut di setiap rilis sejak 7.0. Ini juga alasan perbaikan harus di-backport sejauh itu, sesuatu yang biasanya hanya dilakukan GitLab untuk masalah paling berat.

Menarik dicatat: ini celah keempat di mesin regex yang sama dalam sebulan, dilaporkan peneliti dengan handle joaxcar. Tiga celah sebelumnya berhenti di versi 19.2. Yang ini tidak.

Versi Perbaikan

GitLab memperbaiki celah ini di tujuh versi sekaligus:

Empat versi terakhir (18.11.13, 19.0.10, 19.1.9, 19.2.9) lebih tua dari kebijakan patch normal GitLab, yang biasanya hanya mencakup rilis saat ini dan dua rilis bulanan sebelumnya. Artinya instalasi lama wajib naik ke versi backport tersebut.

Siapa yang Tidak Perlu Panik

Hanya instalasi self-managed yang perlu bertindak. GitLab.com sudah menjalankan versi yang diperbaiki. Pelanggan GitLab Dedicated pada rilis internal 19.3.5-internal0 dan 19.4.2-internal0 atau lebih baru juga sudah mendapat perbaikan.

Kalau kamu memakai GitLab.com untuk menyimpan repositori, tidak ada yang perlu kamu lakukan untuk celah ini. Kalau kamu menjalankan GitLab di server sendiri, di VM, atau di Kubernetes milikmu, kamu masuk kategori yang harus bertindak.

Biaya Update yang Perlu Direncanakan

Rilis 19.4.3 dan 19.3.6 membawa perubahan basis data yang dijalankan saat upgrade. Di server single-node, itu berarti downtime selama migrasi selesai. Untuk instalasi multi-node, GitLab menyediakan prosedur zero-downtime.

Praktisnya, jangan menjadwalkan upgrade ini di jam sibuk tanpa memberi tahu pengguna. Siapkan juga backup basis data sebelum memulai, karena migrasi yang gagal di tengah jalan jauh lebih mahal daripada downtime 20 menit yang direncanakan.

Mendeteksi Kalau Sudah Ada yang Mencoba

GitLab menerbitkan dua aturan deteksi untuk membantu admin mencari jejak percobaan eksploitasi, bernama "Onigmo native worker crash" dan "Org mode render error burst". Keduanya bagian dari framework open-source TLDR milik GitLab, ditulis dalam format Sigma dan dibaca terhadap log aplikasi GitLab sendiri.

Aturan itu penting karena GitLab belum menjelaskan prasyarat apa yang dibutuhkan penyerang untuk mencapai kompiler tersebut. Tanpa penjelasan itu, admin tidak bisa menyingkirkan diri dari risiko lewat konfigurasi. Selama itu belum jelas, patch adalah satu-satunya perlindungan yang pasti; advisory GitLab juga tidak menawarkan workaround sementara.

Kalau kamu ingin melihat pola serupa pada perangkat lunak lain, baca kasus PHP2Shell yang rilis sehari sebelumnya, kenapa jendela patch justru paling berbahaya, dan urutan patch gabungan.

Urutan Kerja yang Disarankan

  1. Cek versi GitLab setiap instalasi self-managed, termasuk yang dianggap "sudah tidak dipakai".
  2. Prioritaskan yang bisa dijangkau internet, terutama yang punya jalur login publik.
  3. Backup, lalu upgrade ke versi perbaikan sesuai cabang.
  4. Setelah upgrade, pasang dua aturan deteksi TLDR dan periksa log 30 hari terakhir untuk pola crash worker Onigmo.
  5. Catat versi akhir dan tanggal upgrade per instalasi.

Pertanyaan yang Sering Muncul

Kalau GitLab hanya dipakai internal, apakah tetap perlu dipatch? Ya. Celah tanpa autentikasi pada layanan internal tetap berbahaya, karena jaringan internal jarang seketat yang diperkirakan.

Apakah cukup menutup jalur pendaftaran? Tidak. Celah ini tidak membutuhkan akun.

Apakah sudah ada eksploitasi di alam liar? GitLab menyatakan belum ada tanda celah ini dipakai dalam serangan, dan per 22 Oktober belum masuk katalog CISA KEV. Tapi lihat pembahasan soal arti "belum ada laporan" sebelum memakai itu sebagai alasan menunda.

Penutup

Celah yang menjangkau 12 tahun rilis adalah pengingat bahwa "kami tidak mengubah apa pun sejak lama" bukan tanda aman, melainkan tanda bahwa kelemahan lama masih ikut berjalan. Perbaikannya tersedia di tujuh cabang sekaligus, termasuk untuk versi yang biasanya tidak lagi dipatch GitLab. Yang perlu disiapkan hanya jendela downtime dan backup. Selebihnya soal disiplin mengecek, bukan soal keberanian mengambil risiko.