GitLab Tambal Celah CVSS 10 Tanpa Login, Segera Update

Masih menjalankan GitLab sendiri di server kantor atau VPS? Kalau belum update sejak pertengahan Oktober, instance-mu kemungkinan besar rentan. GitLab merilis critical patch release pada 21 Oktober 2026 untuk menambal CVE-2026-110264, celah dengan skor CVSS 10.0 yang menurut GitLab bisa membuat penyerang tanpa login menjalankan kode di server, dalam kondisi tertentu.

Jawaban singkatnya: segera naikkan GitLab ke salah satu versi perbaikan, yaitu 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, atau 18.11.13. Pengguna GitLab.com tidak perlu berbuat apa-apa karena layanan itu sudah memakai versi yang ditambal.

Apa sebenarnya celah CVE-2026-110264?

Menurut catatan rilis resmi GitLab, celah ini berupa integer overflow saat GitLab mengompilasi regular expression (regex). Penyerang yang mengirim regex yang dirancang khusus bisa memicu overflow itu dan, dalam kondisi tertentu, mengeksekusi kode sembarang di server GitLab. GitLab tidak merinci kondisi tersebut.

Vektor CVSS-nya AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Artinya bisa diserang lewat jaringan, mudah dilakukan, tidak perlu akun, tidak perlu interaksi pengguna, dan dampaknya bisa meluas ke luar komponen yang diserang. Badan Keamanan Siber Singapura (CSA) juga menerbitkan peringatan pada 22 Oktober 2026 dan menekankan bahwa celah ini bisa dieksploitasi tanpa autentikasi.

Per 12 November 2026, sumber yang kami rujuk tidak menyebut adanya eksploitasi aktif. Tetapi celah dengan skor maksimal di aplikasi yang sering terbuka ke internet biasanya cepat jadi sasaran, jadi jangan menunggu kabar itu.

Celah ini juga bukan satu-satunya. Rilis yang sama menambal 12 masalah keamanan: 1 kritis, 2 tinggi, 5 sedang, dan 4 rendah. Salah satu yang tinggi, CVE-2026-15723 (CVSS 8.2), memungkinkan pengguna yang sudah login mengambil alih akun berbasis LDAP bila OmniAuth SAML dan auto-linking LDAP sama-sama aktif.

Versi mana yang terdampak dan apa perbaikannya?

Ada catatan penting. Perbaikan CVE-2026-110264 sebenarnya berupa patch untuk Ruby, dan hanya ikut di paket Linux resmi serta image container resmi GitLab. Kalau kamu memasang GitLab dari source dengan Ruby sendiri, update GitLab saja tidak cukup. Ruby juga harus dinaikkan ke 3.3.13, 3.4.12, 4.0.9, atau yang lebih baru.

Langkah update GitLab self-managed

Langkah di bawah untuk instalasi paket Linux (Omnibus) dan Docker. Sesuaikan nama paket gitlab-ee menjadi gitlab-ce bila kamu memakai Community Edition.

1. Cek versi yang sedang berjalan

sudo gitlab-rake gitlab:env:info

Lihat baris versi GitLab di bagian "GitLab information". Versi juga terlihat di menu Help di antarmuka web bila kamu login sebagai admin.

2. Buat backup lebih dulu

sudo gitlab-backup create
sudo cp /etc/gitlab/gitlab.rb /etc/gitlab/gitlab-secrets.json /root/

File gitlab-secrets.json tidak ikut di backup bawaan, padahal tanpanya data terenkripsi tidak bisa dipulihkan. Simpan salinan backup di luar server, sesuai prinsip di aturan backup yang tahan ransomware.

3. Pasang versi perbaikan di jalur yang sama

Tetap di seri yang sama agar tidak melompati jalur upgrade wajib GitLab. Contoh untuk server Ubuntu/Debian yang memakai 19.3:

sudo apt update
sudo apt install gitlab-ee=19.3.6-ee.0

Untuk AlmaLinux/Rocky, pakai sudo dnf install gitlab-ee-19.3.6 lalu pastikan versi yang terpasang benar. Untuk Docker, ganti tag image ke versi perbaikan (misalnya gitlab/gitlab-ee:19.3.6-ee.0), lalu buat ulang container dengan volume yang sama.

4. Perhitungkan downtime

Versi 19.4.3 dan 19.3.6 membawa migrasi database. Di instance satu node, GitLab baru bisa jalan setelah migrasi selesai, jadi umumkan jeda singkat ke tim. Instance multi-node bisa memakai prosedur upgrade tanpa downtime.

5. Verifikasi dan pantau

Jalankan lagi sudo gitlab-rake gitlab:env:info untuk memastikan versi sudah benar, lalu sudo gitlab-rake gitlab:check untuk memeriksa kesehatan instance. GitLab juga merilis dua aturan deteksi untuk instance self-managed, yaitu "Onigmo native worker crash" dan "Org mode render error burst". Lonjakan crash atau error semacam itu di log sebelum update layak diselidiki.

Kalau belum bisa update hari ini?

GitLab tidak menyebut mitigasi resmi selain update. Sambil menyiapkan jadwal, langkah umum yang mengurangi paparan adalah membatasi akses ke instance dari internet, misalnya hanya lewat VPN atau daftar IP kantor. Ini menurunkan risiko, bukan menggantikan patch.

Celah GitLab berskor maksimal sudah beberapa kali muncul dalam dua bulan terakhir, jadi ada baiknya proses patch management untuk GitLab dibuat rutin, bukan hanya saat ada berita.

Ringkasnya, sebelum menutup hari:

• Cek versi GitLab di semua server yang kamu kelola.
• Backup data plus gitlab.rb dan gitlab-secrets.json.
• Naikkan ke versi perbaikan di seri yang sama.
• Bila memasang dari source, naikkan juga Ruby.
• Batasi akses publik ke GitLab bila memang tidak perlu terbuka.