GitLab CVE-2026-110264 CVSS 10.0: Patch 19.5.1 Wajib Sekarang

GitLab merilis patch kritis 21 Oktober 2026 untuk CVE-2026-110264, sebuah integer overflow di regular expression compiler yang dinilai CVSS 10.0, skor maksimum. Dampaknya: pengguna tanpa autentikasi bisa mengeksekusi kode sembarang di server GitLab dengan mengirim regular expression yang disusun khusus. Versi yang diperbaiki adalah 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, dan 18.11.13, dan GitLab menyebut semua instalasi self-managed yang terdampak wajib upgrade segera. GitLab.com sendiri sudah menjalankan versi yang dipatch.

TL;DR

• CVE-2026-110264 dapat skor CVSS 10.0: eksekusi kode dari jarak jauh tanpa perlu login.
• Penyebabnya integer overflow saat kompilasi regular expression di mesin Onigmo.
• Semua versi dari 7.0 sampai sebelum 18.11.13, 19.0.10, 19.1.9, 19.2.9, 19.3.6, 19.4.3, dan 19.5.1 terdampak.
• Rilis ini membawa 12 perbaikan keamanan, satu Critical dan dua High.

Seberapa serius CVE-2026-110264?

Ini kategori paling berat yang bisa dialami sebuah server: CVSS 10.0 dengan vektor AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Artinya bisa dieksploitasi lewat jaringan, kompleksitas rendah, tanpa hak akses apa pun, tanpa interaksi pengguna, dan dampaknya menyentuh seluruh sistem.

Yang membuatnya makin tidak nyaman, eksploitasi tidak butuh akun. Pada instalasi GitLab yang terbuka ke internet, penyerang tidak perlu lebih dulu punya akses developer atau reporter. Cukup mengirim regular expression yang dirancang memicu integer overflow saat dikompilasi, lalu dari kondisi itu menuju eksekusi kode di server. Untuk instance yang menyimpan kode sumber, CI/CD secret, dan token deploy, dampak lanjutannya bisa jauh lebih besar daripada satu server yang jatuh.

Penemunya dilaporkan lewat program bug bounty HackerOne GitLab, dan disebutkan dalam pengumuman patch release GitLab dengan kredit untuk pelapor. Detail teknis lengkap tidak dibuka pada hari rilis, mengikuti kebijakan GitLab yang mempublikasikan issue masing-masing kerentanan 90 hari setelah rilis yang memuat patch-nya.

Versi GitLab mana yang harus di-upgrade?

Semua instalasi GitLab CE maupun EE dengan versi 7.0 sampai sebelum batas patch di tiap jalur wajib di-upgrade. Tujuh versi patch tersedia, satu untuk setiap jalur rilis yang masih didukung.

Perhatikan bahwa jalur 18.11 ikut dipatch meski secara nomor terlihat lebih lama dari 19.x. Ini karena 18.11 masih jalur yang didukung, dan GitLab mem-backport perbaikannya ke sana. Kalau instalasi masih di 18.11, jangan menunggu sampai naik ke 19; patch-nya sudah tersedia di jalur yang sekarang.

Jalur versi	Versi patch	Status
19.5	19.5.1	Wajib upgrade bila di bawah ini
19.4	19.4.3	Wajib upgrade bila di bawah ini
19.3	19.3.6	Wajib upgrade bila di bawah ini
19.2	19.2.9	Wajib upgrade bila di bawah ini
19.1	19.1.9	Wajib upgrade bila di bawah ini
19.0	19.0.10	Wajib upgrade bila di bawah ini
18.11	18.11.13	Wajib upgrade bila di bawah ini

Bagaimana cara mendeteksi percobaan eksploitasi?

GitLab security merilis dua threat detection yang bisa dipakai pemilik instance self-managed: Onigmo native worker crash dan Org mode render error burst. Keduanya menandai pola yang muncul saat percobaan eksploitasi berlangsung.

Nama pertama mengisyaratkan crash pada worker native Onigmo, masuk akal karena integer overflow yang dieksploitasi terjadi di jalur kompilasi regex. Nama kedua menyorot lonjakan error saat render Org mode. Kalau log instance menunjukkan salah satu pola itu secara tiba-tiba dan berulang, perlakukan sebagai indikasi serius, bukan gangguan biasa, lalu cek apakah versi yang berjalan sudah dipatch.

Deteksi ini pelengkap, bukan pengganti patch. Selama versi masih di bawah batas aman, deteksi hanya memberi tahu bahwa sesuatu sedang terjadi, tanpa menghentikannya. Urutan yang benar tetap: patch dulu, baru analisis log untuk melihat apakah ada percobaan sebelum patch terpasang.

Apakah GitLab.com dan GitLab Dedicated juga perlu tindakan?

Tidak. GitLab.com sudah berjalan di versi yang dipatch, dan tenant GitLab Dedicated yang berjalan di 19.3.5-internal0 serta 19.4.2-internal0 atau lebih baru sudah memuat perbaikan ini. Tidak ada tindakan yang diperlukan untuk dua layanan tersebut.

Yang perlu bertindak adalah pengguna self-managed, termasuk yang menjalankan GitLab di server sendiri, VM, atau cluster Kubernetes dengan Helm chart. Pengumuman GitLab menyebut bahwa bila tipe deployment tidak disebutkan secara spesifik untuk sebuah isu, berarti semua tipe deployment terdampak. Untuk rilis ini, tidak ada pengecualian tipe deployment yang disebutkan.

Kalau instalasi dikelola pihak ketiga, pastikan pihak itu menerima informasi ini. Patch release GitLab biasanya dijadwalkan dua kali sebulan pada Rabu kedua dan keempat, tapi rilis ini adalah patch kritis ad-hoc yang keluar di luar jadwal karena tingkat keparahannya.

Perbaikan keamanan lain apa yang ikut di rilis ini?

Total ada 12 perbaikan keamanan dalam rilis ini. Selain satu Critical, ada dua isu High dan sisanya Medium sampai Low.

Dua isu High adalah improper authentication pada pencarian email auto-linking OmniAuth ke LDAP, tercatat sebagai CVE-2026-15723, dan cache poisoning pada endpoint discovery OAuth/OIDC. Keduanya relevan untuk instance yang memakai SSO. Isu Medium mencakup improper access control pada field alamat email work item di GraphQL, penegakan yang tidak lengkap pada membership lock SAML/LDAP tingkat instance, eksposur kredensial internal di response header, serta authorization bypass lewat user-controlled key di API milestone grup. Sisanya isu Low di area AI Gateway, render judul merge request, penegakan approval policy, security findings, dan pengaturan Amazon Q.

Daftar lengkap beserta tingkat keparahannya ada di halaman release GitLab, dan mekanisme pelaporan kerentanannya dijelaskan lewat program bug bounty GitLab di HackerOne. Bagi tim yang mengelola instance, membaca tabel lengkapnya berguna untuk menentukan prioritas bila upgrade harus bertahap.

Langkah praktis setelah patch terpasang

Setelah upgrade, ada tiga hal yang layak dikerjakan berurutan: verifikasi versi, periksa log untuk pola percobaan eksploitasi, dan rotasi kredensial bila ada indikasi kompromi.

Verifikasi versi penting karena upgrade yang gagal di tengah jalan bisa meninggalkan instance pada versi lama sementara proses lain tampak normal. Cek nomor versi dari antarmuka admin atau dari paket yang terpasang, bukan dari keberhasilan perintah upgrade. Setelah itu, tinjau log untuk dua pola deteksi yang disebutkan GitLab pada rentang waktu sejak instance terakhir dipatch. Kalau ditemukan indikasi, anggap token CI, kunci deploy, dan secret variabel sebagai berpotensi bocor, lalu rotasi sesuai urutan kepentingan.

Untuk instance yang belum bisa langsung upgrade, langkah sementara yang masuk akal adalah membatasi akses jaringan ke antarmuka web, misalnya hanya dari VPN atau alamat kantor. Ini mengurangi permukaan serangan, tapi tidak menghilangkan kerentanannya, jadi tetap bukan pengganti patch.

Bagaimana urutan upgrade yang aman untuk instance produksi?

Urutannya: ambil backup, upgrade di lingkungan uji dengan data yang menyerupai produksi, jalankan pemeriksaan versi, baru terapkan ke produksi. Untuk patch keamanan, jeda antar langkah sebaiknya dihitung dalam jam, bukan hari.

Backup adalah langkah pertama karena upgrade yang gagal di tengah jalan bisa meninggalkan instance pada kondisi yang tidak konsisten. Setelah backup tersedia, lakukan upgrade di lingkungan uji dengan versi sumber yang sama seperti produksi, bukan langsung dari versi yang jauh lebih lama. GitLab punya jalur upgrade yang mengharuskan melewati versi tertentu sebelum naik ke jalur berikutnya, jadi membaca catatan rilis untuk jalur yang dipakai lebih aman daripada melompat langsung ke versi terbaru.

Setelah upgrade, verifikasi nomor versi dari antarmuka admin atau dari paket yang terpasang. Ini penting karena perintah upgrade yang selesai tanpa error belum tentu menghasilkan versi yang diharapkan, terutama pada instalasi yang memakai paket sistem. Baru setelah versi terkonfirmasi, lanjutkan ke produksi dengan langkah yang sama.

Apa risiko menunda patch untuk kerentanan ini?

Risikonya tinggi karena eksploitasi tidak butuh autentikasi dan tidak butuh interaksi pengguna. Setiap instance yang terbuka ke internet dan belum dipatch berada pada kondisi yang bisa dieksploitasi tanpa hambatan berarti.

Pola yang umum terjadi pada kerentanan sekelas ini: setelah pengumuman resmi, waktu menuju eksploitasi publik menjadi sangat singkat, karena detail teknis mulai beredar dan alat otomatis menyusul. Instance yang terlambat dipatch bukan hanya berisiko pada satu celah, tapi pada seluruh isi yang bisa dijangkau dari celah itu, termasuk repositori kode, variabel CI/CD, dan token yang tersimpan.

Kalau upgrade penuh belum bisa dilakukan hari ini, langkah mitigasi sementara yang masuk akal adalah membatasi akses jaringan ke antarmuka web, misalnya hanya dari VPN atau rentang alamat kantor, dan memantau dua pola deteksi yang disediakan GitLab. Keduanya mengurangi peluang dan memberi peringatan lebih awal, tapi tidak menutup celah, sehingga tetap harus disusul patch.

Apakah versi 18.11 juga harus naik ke 19?

Tidak harus untuk saat ini. Patch 18.11.13 sudah memuat perbaikan CVE-2026-110264, jadi jalur 18.11 aman tanpa harus pindah ke 19 lebih dulu. Yang penting adalah nomor patch di jalur yang sedang dipakai.

Ini pola yang khas pada patch kritis: perbaikan dibawa ke semua jalur yang masih didukung, bukan hanya jalur terbaru. Tim yang sedang menahan diri di 18.11 karena alasan kompatibilitas tidak perlu memaksa upgrade besar di tengah keadaan darurat keamanan. Cukup naik ke patch yang tepat, lalu rencanakan perpindahan jalur sesuai jadwal normal.

Apakah patch ini juga berlaku untuk instalasi Helm chart?

Ya. Pengumuman GitLab menyatakan bahwa bila tipe deployment tidak disebutkan secara spesifik untuk sebuah isu, berarti semua tipe deployment terdampak, termasuk omnibus, instalasi dari source, dan Helm chart. Jadi pengguna Kubernetes tidak dikecualikan dan tetap perlu menaikkan versi chart ke rilis yang memuat patch ini.

FAQ

Apakah CVE-2026-110264 butuh autentikasi untuk dieksploitasi?

Tidak. Vektor CVSS-nya PR:N, yang berarti penyerang tidak butuh hak akses apa pun di instance. Ini yang membuat skornya mencapai 10.0 dan membuat patch menjadi urusan mendesak.

Apakah GitLab.com terdampak?

Tidak. GitLab.com sudah berjalan pada versi yang sudah dipatch saat pengumuman dirilis. Yang perlu bertindak adalah pengguna self-managed yang menjalankan instance sendiri.

Kapan detail teknis kerentanannya dipublikasikan?

Issue yang menjelaskan masing-masing kerentanan dibuka 90 hari setelah rilis yang memuat patch-nya. Sampai waktu itu, informasi teknis terbatas pada ringkasan di pengumuman patch release.

Apakah cukup menutup akses web sebagai ganti upgrade?

Membatasi akses hanya mengurangi peluang eksploitasi dari jaringan luar, bukan menutup kerentanannya. Instance yang masih di bawah versi patch tetap rentan bila akses bisa didapat dari jalur lain.