Celah Keamanan GitLab CVE-2026-97229: Cek Versi Server

Celah keamanan GitLab CVE-2026-97229 adalah celah dengan skor CVSS 10.0, skor bahaya tertinggi. Lewat celah ini, penyerang tanpa login bisa menjalankan perintah di server GitLab self-managed, yang dipasang dan dikelola sendiri. Celah ini sudah dipakai menyerang, dan CISA, badan keamanan siber Amerika Serikat, mencatatnya pada 29 Oktober 2026. Server yang belum di-upgrade perlu segera ditambal.

Masalahnya belum selesai. Pada 2 November 2026, BleepingComputer mengutip data Shadowserver, yang memantau sekitar 39 ribu instance GitLab setiap hari. Instance di sini artinya satu server GitLab yang sedang berjalan. Hasilnya, lebih dari 1.000 instance masih rentan terhadap CVE-2026-97229. Lebih dari 11.300 instance juga masih rentan terhadap celah kedua, CVE-2026-110264.

GitLab adalah tempat tim menyimpan source code (kode program aplikasi) dan menjalankan CI/CD, yaitu proses otomatis yang menguji lalu memasang aplikasi ke server. Artikel ini untuk perusahaan, software house, dan tim IT yang memakai GitLab milik sendiri. Kita bahas siapa yang terdampak, cara cek versi, versi minimum yang aman, dan apa yang perlu diperiksa setelah patch.

Apa itu celah keamanan GitLab CVE-2026-97229 dan CVE-2026-110264?

Keduanya adalah celah eksekusi kode jarak jauh tanpa autentikasi. Artinya, orang luar bisa menjalankan perintah di server Anda dari jauh tanpa perlu login. Keduanya mendapat skor CVSS 10.0, skor tertinggi. Akar masalahnya sama: integer overflow saat GitLab mengolah regular expression (regex) yang sengaja dibuat untuk menyerang.

• CVE-2026-97229 ada di bagian CI/CD Regular Expression Compiler. Menurut catatan rilis resmi GitLab (12 Oktober 2026), pemeriksaan regex di konfigurasi CI/CD kurang ketat. Akibatnya, pengguna yang tidak login bisa menjalankan kode di server GitLab. Versi yang terdampak adalah cabang 19.2, 19.3, dan 19.4 sebelum patch.
• CVE-2026-110264 ada di bagian Regular Expression Compiler. Catatan rilis GitLab (21 Oktober 2026) menyebut dampaknya sama. Bedanya, rentang versinya jauh lebih luas: semua versi sejak 7.0 sebelum patch di tiap cabang.

Regex adalah pola teks untuk mencocokkan tulisan, misalnya aturan penamaan branch di pipeline. Integer overflow terjadi saat sebuah angka di dalam program melewati batas maksimalnya. Bayangkan odometer motor yang kembali ke nol setelah penuh. Hitungan memori jadi salah, dan penyerang bisa membelokkan kesalahan itu untuk menjalankan kode.

Celah pertama sudah dipakai untuk menyerang. CISA menambahkan CVE-2026-97229 ke katalog Known Exploited Vulnerabilities, yaitu daftar celah yang terbukti dieksploitasi, pada 29 Oktober 2026. Untuk CVE-2026-110264, sumber yang kami baca tidak menyebut eksploitasi. Namun, jumlah server yang belum ditambal jauh lebih banyak.

Siapa yang terdampak?

Yang terdampak hanya GitLab self-managed, baik Community Edition (CE) maupun Enterprise Edition (EE). Self-managed artinya GitLab dipasang di server kantor atau di cloud yang Anda kelola sendiri. Pengguna layanan yang dikelola langsung oleh GitLab tidak perlu bertindak.

• GitLab.com: menurut GitLab, layanan ini sudah berjalan di versi yang ditambal.
• GitLab Dedicated: tenant yang menjalankan 19.3.5-internal0 dan 19.4.2-internal0 atau lebih baru sudah memuat perbaikan dan tidak perlu bertindak.
• Self-managed: Anda wajib upgrade sendiri. Ini termasuk server GitLab yang dipasang vendor atau freelancer untuk proyek Anda.

Risikonya besar karena server GitLab biasanya menyimpan seluruh kode program dan riwayat perubahannya. Di sana juga ada variabel CI/CD berisi password database atau API key, serta akses untuk memasang aplikasi ke server produksi. Jadi, satu server GitLab yang diambil alih bisa membuka jalan ke sistem lain.

Cara cek versi server GitLab Anda

Bagian ini untuk tim IT atau vendor Anda. Versi GitLab bisa dicek dalam beberapa menit lewat tampilan web atau terminal server. Pilih salah satu cara berikut.

1. Halaman Help: buka https://alamat-gitlab-anda/help setelah login. Nomor versi tampil di bagian atas halaman.
2. Admin Area: masuk sebagai administrator, buka Admin Area, lalu lihat panel komponen yang menampilkan versi GitLab.
3. Terminal server (untuk instalasi paket resmi): jalankan perintah di bawah ini, lalu lihat baris Version di bagian GitLab information.

sudo gitlab-rake gitlab:env:info

Bila GitLab dipasang dari source code sendiri, jalankan perintah yang sama dari folder instalasi GitLab dengan RAILS_ENV=production. Catat juga versi GitLab Runner di setiap mesin runner. Runner adalah mesin yang menjalankan pipeline, dan versinya diperbarui terpisah.

Versi minimum yang aman dari kedua celah

Server Anda aman dari kedua celah bila versinya sama dengan atau lebih tinggi dari angka di bawah ini, sesuai cabangnya. Daftar ini kami susun dari catatan rilis resmi GitLab tanggal 12 dan 21 Oktober 2026.

• Cabang 18.11: minimal 18.11.13
• Cabang 19.0: minimal 19.0.10
• Cabang 19.1: minimal 19.1.9
• Cabang 19.2: minimal 19.2.9
• Cabang 19.3: minimal 19.3.6
• Cabang 19.4: minimal 19.4.3
• Cabang 19.5: minimal 19.5.1

Hati-hati dengan cabang 19.2 sampai 19.4. Versi 19.2.8, 19.3.5, dan 19.4.2 sudah menutup CVE-2026-97229, tetapi belum menutup CVE-2026-110264. Jadi, server yang di-upgrade pada pertengahan Oktober 2026 masih perlu satu upgrade lagi.

Saran kami, langsung naik ke rilis patch terbaru di cabang Anda: 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11, atau 18.11.14. Rilis ini juga mencabut kepercayaan pada delapan sertifikat intermediate CA eMudhra yang kunci privatnya bocor (CVE-2026-111943). Sertifikat seperti ini dipakai untuk membuktikan bahwa sebuah server asli, mirip stempel resmi pada surat. GitLab menegaskan GitLab Runner juga harus di-update ke 19.5.1. Image job CI/CD yang membawa paket ca-certificates sendiri juga perlu dibangun ulang. Versi 19.5.2 dan 19.4.4 memang dilewati GitLab dan tidak pernah ada, jadi tidak perlu dicari.

Instalasi source atau image custom: upgrade Ruby juga

Ruby adalah bahasa pemrograman yang menjadi mesin GitLab. Bila GitLab Anda memakai Ruby yang dipasang sendiri, upgrade GitLab saja tidak cukup. Menurut catatan rilis 21 Oktober 2026, perbaikan CVE-2026-110264 berupa patch pada Ruby, bukan pada kode GitLab. Patch itu hanya ikut di paket Linux dan container image resmi. Jadi, instalasi yang dikompilasi sendiri atau memakai image custom wajib meng-upgrade Ruby ke 3.3.13, 3.4.12, 4.0.9, atau lebih baru.

Langkah upgrade: tidak ada workaround

Satu-satunya perbaikan adalah upgrade. Catatan rilis GitLab tidak mencantumkan workaround atau cara pengaman sementara. GitLab meminta semua instalasi self-managed segera di-upgrade.

1. Buat backup lengkap sebelum mulai. Cadangkan repository, database, serta file konfigurasi dan secret (gitlab.rb dan gitlab-secrets.json pada paket Omnibus, paket instalasi resmi GitLab). Pastikan backup itu benar-benar bisa dipulihkan. Penjelasan dasarnya ada di artikel fungsi SSL dan backup website.
2. Jadwalkan downtime. Menurut GitLab, patch ini berisi migrasi database, yaitu perubahan struktur data. Pada server tunggal (single-node), GitLab baru bisa dipakai setelah migrasi selesai. Pilih jam sepi dan beri tahu tim lebih dulu.
3. Ikuti jalur upgrade resmi GitLab bila versi Anda tertinggal jauh. Lompatan versi besar kadang mewajibkan versi perantara.
4. Update GitLab Runner ke 19.5.1 di setiap mesin runner.
5. Pastikan hasilnya lewat halaman /help bahwa versi baru sudah aktif. Lalu jalankan satu pipeline uji.

Bila server GitLab juga berjalan di Linux yang lama tidak diperbarui, cek kernelnya sekalian. Panduannya ada di artikel celah keamanan kernel Linux CVE-2026-98432.

Setelah patch: periksa tanda penyusupan

Patch itu seperti mengganti kunci pintu. Pintunya tertutup, tetapi penyusup yang sudah telanjur masuk belum tentu keluar. Karena CVE-2026-97229 sudah dieksploitasi sebelum banyak server ditambal, minta tim IT memeriksa hal berikut.

• Deteksi resmi GitLab. Menurut catatan rilis 12 Oktober 2026, GitLab merilis enam aturan deteksi untuk CVE-2026-97229 di repository gitlab-security-oss/tldr. Contohnya "Onigmo native worker crash", "ci lint workhorse worker crash", "Graphql cilint hostile regexp", dan "ci regexp guard rejection". Cocokkan aturan itu dengan log GitLab Anda, mulai dari sebelum patch dipasang.
• Akun pengguna. Cari akun admin baru, akun yang tidak dikenal, atau perubahan hak akses yang tidak tercatat di tiket kerja.
• Token akses. Tinjau personal access token, project token, dan deploy key, yaitu "kunci" untuk masuk tanpa password. Hapus yang tidak dipakai.
• Runner. Pastikan tidak ada runner baru yang terdaftar tanpa sepengetahuan tim.
• Secret CI/CD. Variabel berisi password database, API key, atau akses cloud bisa terbaca bila server sempat diambil alih.

Bila ada tanda mencurigakan, ganti semua password dan kunci yang tersimpan di GitLab, dimulai dari yang dipakai untuk sistem produksi. Ini saran kehati-hatian dari kami, bukan instruksi tertulis di catatan rilis GitLab. Untuk jangka panjang, pertimbangkan membatasi akses GitLab dari internet dengan VPN atau IP allowlist (daftar alamat yang diizinkan). Dengan begitu, halaman login dan API tidak bisa dijangkau sembarang orang.

Untuk pemilik bisnis yang aplikasinya dibuat vendor

Anda tidak perlu paham GitLab untuk memastikan bisnis Anda aman. Cukup ajukan tiga pertanyaan ini kepada vendor atau tim IT Anda.

1. Apakah kode aplikasi kami disimpan di GitLab self-managed, GitLab.com, atau layanan lain?
2. Bila self-managed, versi berapa yang berjalan sekarang, dan kapan server terakhir di-update?
3. Apakah akun, token, dan secret sudah diperiksa setelah patch?

Pertanyaan ini juga mengingatkan pentingnya serah terima. Misalnya, saat vendor lama berhenti, Anda tetap harus tahu di mana kode disimpan dan siapa yang memegang aksesnya. Karena itu, akses repository dan dokumentasi server sebaiknya tercatat sejak awal proyek, seperti dibahas di artikel tahap pembuatan website sampai serah terima.

Pertanyaan yang sering diajukan

Apakah pengguna GitLab.com perlu melakukan sesuatu?

Tidak. GitLab menyatakan GitLab.com sudah berjalan di versi yang ditambal, dan tenant GitLab Dedicated juga tidak perlu bertindak. Yang wajib upgrade hanya pemilik instalasi GitLab self-managed.

Server kami sudah di versi 19.4.2. Apakah sudah aman?

Belum sepenuhnya. Versi 19.4.2 menutup CVE-2026-97229, tetapi CVE-2026-110264 baru ditutup di 19.4.3. Naiklah minimal ke 19.4.3, atau lebih baik ke 19.4.5, patch terbaru di cabang itu.

Apakah ada cara menambal tanpa upgrade?

Tidak ada. Catatan rilis GitLab tidak mencantumkan workaround untuk kedua celah ini, jadi upgrade adalah satu-satunya perbaikan. Instalasi yang memakai Ruby sendiri juga harus meng-upgrade Ruby ke 3.3.13, 3.4.12, 4.0.9, atau lebih baru.

Berapa lama downtime saat upgrade?

Tidak ada angka pasti, karena lamanya bergantung pada ukuran database dan jumlah migrasi. Pada server tunggal (single-node), GitLab baru bisa dipakai setelah migrasi database selesai. Jadi, jadwalkan upgrade di luar jam kerja dan siapkan backup lebih dulu.

Belum yakin di mana kode aplikasi bisnis Anda disimpan atau siapa yang merawat servernya? Anaverse, software house dan IT consultant di Pekanbaru, Riau, bisa membantu meninjau infrastruktur, alur deploy, dan rencana upgrade bersama tim Anda. Pelajari layanan konsultan IT dan sistem informasi kami atau hubungi kami untuk konsultasi.

Referensi

• GitLab: Critical Patch Release 19.4.2, 19.3.5, 19.2.8 (12 Oktober 2026)
• GitLab: Critical Patch Release 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, 18.11.13 (21 Oktober 2026)
• GitLab: Patch Release and Security Update 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11, 18.11.14
• CISA: CISA Adds Two Known Exploited Vulnerabilities to Catalog (29 Oktober 2026)
• BleepingComputer: Over 1,000 GitLab servers vulnerable to ongoing RCE attacks (2 November 2026)
• BleepingComputer: GitLab warns of new max severity code execution vulnerability (22 Oktober 2026)