Celah Kritis GitLab Skor 10: Segera Perbarui Server

GitLab merilis tambalan untuk celah keamanan kritis berskor CVSS 10.0, nilai tertinggi yang mungkin, pada 12 Oktober 2026. Celah ini hanya menyasar GitLab yang Anda kelola sendiri di server sendiri. Jika tim IT sekolah, kampus, dinas, atau perusahaan Anda memakainya, cek versinya hari ini.

Apa yang diumumkan GitLab

Menurut catatan rilis patch GitLab yang terbit 12 Oktober 2026, celah ini bernomor CVE-2026-97229. Penyebabnya adalah integer overflow di compiler ekspresi reguler (regex) untuk CI/CD. Singkatnya, validasi terhadap regex yang dibuat khusus dinilai kurang memadai. Dalam kondisi tertentu, pengguna tanpa autentikasi bisa menjalankan kode di server GitLab.

CI/CD sendiri adalah jalur otomatis yang membangun, menguji, dan merilis aplikasi setiap kali tim programmer mengunggah perubahan. Konfigurasinya biasanya ditulis dalam satu berkas, dan di dalamnya boleh ada regex untuk menyaring cabang atau tag tertentu.

Skor 10.0 itu datang dari vektor CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:C/C:H/I:H/A:H. Dibaca pelan-pelan: bisa dijangkau lewat jaringan, tidak rumit, tidak butuh akun, tidak butuh klik dari korban, dan dampaknya tinggi pada kerahasiaan, keutuhan, serta ketersediaan. GitLab mencatat peneliti bernama joaxcar sebagai pelapor lewat program HackerOne.

Tambalan tersedia untuk tiga cabang rilis, dan hanya yang berada di bawah angka berikut yang rentan:

Edisi yang terdampak adalah Community Edition (CE) dan Enterprise Edition (EE). Dua kabar baiknya: GitLab.com sudah menjalankan versi yang ditambal, dan pelanggan GitLab Dedicated tidak perlu melakukan apa pun. Pekerjaan rumah ada di pihak yang memasang GitLab sendiri.

Satu catatan kecil soal versi. Menurut dokumen yang sama, rilis 19.3.4 sempat bermasalah di halaman merge request pada instalasi yang mengaktifkan integrasi Ona, dan masalah itu diperbaiki di 19.3.5. Jadi untuk cabang 19.3, sasarannya 19.3.5, bukan 19.3.4.

Kenapa celah di jalur CI/CD terasa serius

Banyak organisasi di Indonesia memilih memasang GitLab di server sendiri. Alasannya masuk akal: kode sumber dan data proyek tetap berada di infrastruktur yang dikendalikan sendiri, hal yang sering dipertimbangkan instansi pemerintah, sekolah, dan perusahaan yang sensitif soal data. Konsekuensinya, urusan pembaruan juga menjadi tanggung jawab tim internal, bukan vendor.

Server GitLab jarang berdiri sendirian. Ia menyimpan kode sumber, mengatur siapa boleh mengubah apa, dan memerintah para runner (mesin pekerja) untuk menjalankan proses build. Di jalur itu sering ada kunci akses, token cloud, atau kredensial basis data, supaya proses rilis bisa berjalan tanpa campur tangan manusia.

Penulis analisis di Penligent menegaskan bahwa advisori resmi menyebut produk yang terdampak adalah GitLab CE/EE, bukan GitLab Runner sebagai program tersendiri. Meski begitu, menurut analisis tersebut, server yang berhasil dikuasai tetap bisa menimbulkan risiko bagi infrastruktur CI/CD yang terhubung dengannya. Jadi runner tetap layak masuk daftar periksa Anda.

Bayangkan sebuah dinas yang memasang GitLab di server kantor untuk mengelola aplikasi layanan publiknya. Atau kampus yang memakainya untuk tugas mahasiswa sekaligus sistem informasi akademik. Jika server itu terbuka ke internet dan versinya tertinggal, risikonya bukan cuma kode yang terbaca, tetapi juga rahasia di dalam pipeline-nya.

Yang belum diketahui, dan kenapa itu bukan alasan menunda

Untuk adilnya, kita perlu jujur soal batas informasi. Per 13 Oktober 2026, analisis Penligent menyebut advisori GitLab dan CERT-EU tidak melaporkan eksploitasi yang terkonfirmasi di dunia nyata. Sumber yang sama juga tidak menemukan proof of concept yang terverifikasi publik. Detail teknis lengkap biasanya baru dibuka GitLab sekitar 90 hari setelah rilis.

Kabar itu menenangkan, tapi jangan dibaca sebagai “aman untuk ditunda”. Begitu tambalan terbit, pihak lain bisa membandingkan versi lama dan baru untuk menebak letak celahnya. Karena itu jendela waktu antara rilis tambalan dan pemasangannya adalah masa paling rawan. Kita pernah mengulas hal ini di artikel tentang serangan siber berbasis AI dan jendela patch yang makin sempit, dan kasus GitLab ini contoh yang pas.

Satu hal lagi dari analisis tadi: menghapus regex dari berkas konfigurasi CI bukan perbaikan. Pembaruan versi tetap jalan utamanya, dan tidak ada solusi sementara yang diverifikasi vendor.

Apa artinya bagi organisasi Anda?

Pertama, pastikan dulu apakah Anda terdampak. Kalau tim Anda memakai GitLab.com atau layanan Dedicated, sebagian besar urusan sudah ditangani vendor. Kalau Anda memasang GitLab sendiri, ikuti alurnya di bawah ini.

Beberapa catatan dari langkah-langkah itu. Untuk mengecek versi, Penligent menyarankan menjalankan sudo gitlab-rake gitlab:env:info di semua node aplikasi, bukan hanya satu. Pembaruan ini juga membawa migrasi basis data. Pada instalasi satu node, GitLab akan mati sementara sampai migrasi selesai, jadi umumkan jendela perawatan ke tim. Instalasi multi-node dapat memakai prosedur zero-downtime dari GitLab.

Sebelum menekan tombol upgrade, siapkan cadangan basis data dan konfigurasi, lalu catat versi yang sedang berjalan. Ini kebiasaan baik untuk setiap pembaruan, terlebih karena kali ini ada migrasi basis data. Jika ada lingkungan uji, coba di sana dulu, tetapi jangan sampai uji coba itu membuat server produksi menunggu berhari-hari.

Setelah naik versi, luangkan waktu untuk meninjau hal di sekitarnya. Siapa saja yang punya akses admin? Rahasia apa yang tersimpan sebagai variabel CI? Apakah ada kunci yang sebaiknya diganti, terutama bila server Anda terbuka ke internet dan lama tertinggal? Ini langkah pencegahan yang masuk akal, meski sumber belum menyebut adanya eksploitasi.

Anda juga tidak perlu menunggu insiden untuk memperbaiki cara kerja. Jadikan kejadian ini bahan latihan: berapa lama waktu yang dibutuhkan tim dari membaca kabar sampai server selesai diperbarui? Kalau jawabannya lebih dari beberapa hari untuk celah berskor 10, di situlah proses Anda perlu dirapikan.

Untuk jangka menengah, kebiasaan ini yang paling menolong: punya daftar sistem yang menghadap internet, ada satu orang yang bertanggung jawab atas pembaruan, dan berlangganan pemberitahuan keamanan dari vendor. Organisasi yang belum punya tim khusus bisa memulai dari audit sederhana, misalnya lewat layanan keamanan siber atau penataan infrastruktur di cloud yang pembaruannya lebih mudah dikelola.

Pertanyaan yang sering muncul

Apakah GitLab.com yang kami pakai ikut terdampak?

Tidak perlu tindakan dari Anda. Catatan rilis GitLab menyebut GitLab.com sudah menjalankan versi yang ditambal, dan pelanggan GitLab Dedicated tidak perlu bertindak. Celah ini menjadi urusan bagi yang memasang GitLab CE atau EE secara mandiri.

Kami masih di versi 19.1 atau lebih lama. Apakah aman?

Catatan rilis hanya menyebut tiga cabang yang terdampak: 19.2, 19.3, dan 19.4, sebelum versi tambalannya. Namun versi yang jauh tertinggal biasanya menyimpan celah lain yang sudah dikenal. Pastikan Anda memeriksa advisori resmi GitLab untuk cabang yang Anda pakai, lalu rencanakan pembaruan ke versi yang masih didukung.

Apakah celah ini sudah dipakai menyerang?

Per 13 Oktober 2026, belum ada eksploitasi terkonfirmasi yang dilaporkan menurut analisis Penligent yang merujuk pada GitLab dan CERT-EU. Status itu bisa berubah, jadi pantau kabar terbarunya dari GitLab.

Penutup: kecil di konfigurasi, besar di dampak

Celah seperti ini mengingatkan kita bahwa alat bantu developer pun bagian dari permukaan serangan. Pembaruan yang rutin, daftar aset yang jelas, dan satu orang yang menjaga jadwal patch sering lebih ampuh daripada membeli alat baru. Jika Anda ingin ditemani menilai kesiapan infrastruktur pengembangan di organisasi Anda, tim kami senang berdiskusi lewat halaman kontak.

Sumber

• GitLab: Patch release 19.4.2, 19.3.5, 19.2.8, 12 Oktober 2026
• Penligent: CVE-2026-97229, Critical GitLab CI/CD RCE Vulnerability, 13 Oktober 2026
• DEV Community: GitLab’s CVSS 10 fix lives in the CI config parser, 13 Oktober 2026