GitLab Tutup Lubang CVSS 10.0: Satu Regex Bisa Jadi RCE Tanpa Login

GitLab merilis patch darurat pada 21 Oktober 2026 untuk sebuah bug yang skornya mentok di angka tertinggi, CVSS 10.0. Namanya CVE-2026-110264, dan masalahnya ada di compiler regular expression yang dipakai GitLab. Menurut advisory resmi mereka, kondisi tertentu bisa membuat penyerang tanpa akun menjalankan kode sembarang di server GitLab. Bukan cuma baca data, tapi eksekusi kode.

Yang bikin angka itu masuk akal: vektor serangannya jaringan, kompleksitasnya rendah, tidak butuh privilege, dan tidak butuh interaksi korban. CVSS-nya ditulis CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Diterjemahkan ke bahasa manusia: penyerang tidak perlu login, tidak perlu mengeklik apa pun, dan dampaknya tinggi ke kerahasiaan, integritas, serta ketersediaan layanan.

Apa yang sebenarnya terjadi

Inti bugnya integer overflow saat GitLab mengompilasi sebuah regular expression yang dibuat khusus. Regular expression dipakai di banyak tempat, dari validasi input sampai rendering konten. Ketika sebuah pola membuat penghitungan angka di dalam compiler meluap, hasilnya bukan sekadar error. Dalam kasus ini hasilnya bisa berupa eksekusi kode di server.

GitLab tidak membeberkan jalur serangan lengkap, dan itu wajar untuk advisory yang baru terbit. Mereka juga tidak melaporkan adanya serangan yang sudah terkonfirmasi maupun exploit publik. Tapi ketiadaan bukti eksploitasi bukan alasan untuk santai. Detail teknis advisory ini baru dibuka 90 hari setelah patch, sesuai kebijakan GitLab. Artinya ada jendela tiga bulan di mana penyerang tahu ada lubang besar, tapi belum tahu persis cara membukanya. Setelah 90 hari, semuanya terbuka.

Yang menarik, akar kodenya berumur panjang. Versi terdampak dimulai dari GitLab 7.0, rilis tahun 2014. Rentang itu berarti sekitar 12 tahun kode berjalan dengan asumsi bahwa pola regex yang masuk masih bisa dipercaya. Laporan Cyber Security News menyebut rentang ini sebagai bagian dari cerita, bukan bukti bahwa lubangnya sudah dipakai orang selama 12 tahun.

Versi mana yang harus naik sekarang

GitLab memperbaiki ini di 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, dan 19.5.1. Perhatikan bahwa mereka mem-backport perbaikan ke empat cabang lama di luar jadwal patch normal, yaitu 18.11.13, 19.0.10, 19.1.9, dan 19.2.9. Langkah itu jarang dilakukan kalau bugnya biasa saja.

• Semua versi dari 7.0 sampai sebelum 18.11.13 terdampak.
• Cabang 19.0 sebelum 19.0.10, 19.1 sebelum 19.1.9, dan 19.2 sebelum 19.2.9 terdampak.
• Cabang 19.3 sebelum 19.3.6, 19.4 sebelum 19.4.3, dan 19.5 sebelum 19.5.1 terdampak.
• GitLab.com sudah memakai versi yang dipatch, jadi pengguna SaaS tidak perlu melakukan apa pun.
• GitLab Dedicated dengan 19.3.5-internal0, 19.4.2-internal0, atau lebih baru juga sudah aman.

Kuncinya ada di kata self-managed. Bila kamu menjalankan GitLab sendiri di VPS, di data center, atau di cluster Kubernetes milik perusahaan, kamu adalah pihak yang harus bergerak. Tidak ada tim GitLab yang akan menambal instance kamu.

Bukan cuma satu CVE

Patch 19.5.1 sebenarnya membawa 12 perbaikan keamanan. Beberapa yang perlu dicatat:

• CVE-2026-15723, CVSS 8.2. Saat OmniAuth SAML dan LDAP auto-linking aktif bersamaan, pengguna terautentikasi bisa mengambil alih akun LDAP milik orang lain tanpa interaksi korban. Terdampak sejak versi 10.1.
• CVE-2026-112212, CVSS 7.5. Cache poisoning pada endpoint discovery OAuth/OIDC. Penyerang tanpa login bisa mengarahkan alur autentikasi ke server yang dia kendalikan.
• CVE-2026-12664, CVSS 6.8. Token dengan scope read_api bisa membaca alamat email masuk sebuah proyek dan membuat work item di luar batas izin token.
• CVE-2026-16255, CVSS 5.9, khusus Enterprise Edition. Membership lock SAML/LDAP tidak ditegakkan penuh, jadi anggota bisa ditambahkan di luar kendali identity provider.

Bagi tim yang memakai SSO, dua CVE pertama lebih relevan daripada yang ketiga dan keempat. Tapi urutan prioritas upgrade tetap sama, karena semuanya dibawa oleh patch yang sama.

Cara memeriksa apakah kamu sudah kena

GitLab merilis dua panduan deteksi untuk pemilik instance self-managed, berjudul Onigmo native worker crash dan Org mode render error burst. Keduanya tersedia di repositori gitlab-security-oss/tldr. Nama pertamanya memberi petunjuk: Onigmo adalah library regex yang dipakai Ruby, dan crash pada worker native bisa jadi jejak percobaan eksploitasi.

Perlu ditegaskan, keberadaan panduan deteksi bukan berarti serangan sudah terjadi. Dokumen itu dibuat supaya tim keamanan punya titik awal saat menyisir log. Bila menemukan crash berulang pada worker yang berhubungan dengan regex, atau lonjakan error rendering Org mode yang tidak wajar, itu layak diperiksa lebih dalam.

Langkah yang harus diambil minggu ini

1. 1Cek versi sekarang. Jalankan cat /opt/gitlab/version-manifest.txt untuk instalasi Omnibus, atau lihat halaman Admin Area, Settings, General di panel web.
2. 2Tentukan target versi. Masih di 18.x berarti naik ke 18.11.13. Di 19.3 berarti ke 19.3.6. Jangan melompati cabang utama tanpa membaca jalur upgrade.
3. 3Baca catatan migrasi. Rilis 19.3.6 dan 19.4.3 membawa migrasi database reguler. Instalasi single node akan mengalami downtime, sedangkan setup multi node bisa memakai prosedur zero downtime kalau arsitekturnya mendukung.
4. 4Backup dulu. Backup database dan file konfigurasi sebelum menjalankan upgrade, terutama kalau ada migrasi yang tidak bisa dibatalkan.
5. 5Aktifkan WAF atau aturan pemblokiran sementara untuk pola request yang mencurigakan ke endpoint yang memproses konten, sebagai lapisan tambahan selama jendela upgrade.
6. 6Audit log setelah upgrade. Cari tanda akses tidak wajar, pembuatan token baru, atau perubahan izin yang tidak kamu kenali.
7. 7Bila instance kamu terekspos langsung ke internet tanpa VPN atau IP allowlist, prioritaskan ini di atas pekerjaan lain minggu ini.

Satu hal yang sering terlewat: memastikan runner dan komponen pendamping ikut terupdate. GitLab punya beberapa produk terpisah, dan laporan sebelumnya soal AI Gateway menunjukkan bahwa satu patch GitLab belum tentu menutup semua komponen yang kamu jalankan.

Konteks: minggu yang berat untuk tim ops

Patch GitLab ini datang di tengah gelombang perbaikan keamanan yang cukup padat. Node.js merilis pembaruan untuk sepuluh kerentanan di cabang 26.x, 24.x, dan 22.x dengan versi 26.12.1, 24.22.1, dan 22.23.4. PHP juga menambal dua lubang kritis yang dikenal sebagai PHP2Shell, CVE-2026-109618 dan CVE-2026-109619.

Bagi tim kecil yang mengelola sendiri semuanya, ini berarti daftar pekerjaan bertambah dalam hitungan hari. Realistisnya, tidak semua bisa dikerjakan bersamaan. Urutannya sederhana: dahulukan yang bisa dieksploitasi tanpa login dan punya dampak eksekusi kode. CVE-2026-110264 masuk kategori itu, jadi tempatnya di paling atas.

Kenapa ini penting untuk portofolio dan bisnis

GitLab sering dianggap sebagai alat internal, padahal isinya justru aset paling sensitif: kode sumber, kredensial CI/CD, konfigurasi deployment, dan akses ke seluruh infrastruktur. Begitu penyerang bisa menjalankan kode di server GitLab, dia tidak perlu menembus production secara langsung. Dia cukup membaca variabel rahasia di pipeline, lalu memakai kredensial itu untuk masuk ke sistem lain.

Itu sebabnya dampak sebuah RCE di GitLab tidak berhenti di satu server. Dalam banyak kasus, runner CI memegang token yang bisa melakukan deploy. Satu eksekusi kode di host yang salah bisa berubah jadi perjalanan horizontal ke seluruh lingkungan produksi.

Catatan penutup

Belum ada bukti eksploitasi di lapangan, dan itu kabar baik yang sempit. Yang lebih menentukan adalah seberapa cepat instance self-managed dinaikkan ke versi patch. Untuk yang menjalankan GitLab di infrastruktur sendiri, langkah paling berguna hari ini adalah membuka terminal, mengecek versi, dan menjadwalkan upgrade sebelum akhir pekan.