GitLab CVE-2026-97229 dan CVE-2026-110264: Celah RCE CVSS 10 Sudah Diserang, Cara Cek dan Patch Hari Ini

Jawaban langsung: GitLab self-managed punya 2 celah dengan skor CVSS 10.0: CVE-2026-97229 dan CVE-2026-110264. Keduanya dapat menjalankan kode di server tanpa login. CVE-2026-97229 sudah dipakai menyerang dan masuk CISA KEV pada 29 Oktober 2026. Update GitLab ke rilis 29 Oktober hari ini: 19.5.3, 19.4.5, 19.3.7, 19.2.10, 19.1.10, 19.0.11, atau 18.11.14.

Celah ini hanya ada di GitLab yang Anda pasang sendiri. GitLab.com dan GitLab Dedicated sudah ditambal oleh GitLab.

Kondisi utama: Paket Omnibus, image Docker resmi, dan Helm chart resmi hanya butuh update GitLab. Instalasi dari source dan image buatan sendiri juga butuh Ruby 3.3.13, 3.4.12, atau 4.0.9. Batas: Langkah sementara di artikel ini hanya mengurangi paparan. Artikel ini tidak memuat kode eksploit.

Kami membaca rilis patch GitLab 12 Oktober, rilis patch GitLab 21 Oktober, rilis GitLab 29 Oktober, advisory Ruby 23 Oktober, laporan insiden Alpine Linux, dan CISA KEV pada 30 Oktober 2026, sekitar pukul 17.00 WIB. Perintah di langkah 1, 2, 4, dan 5 kami jalankan di container podman dengan image resmi GitLab 19.3.4, GitLab 19.5.3, Ruby 3.3.12, dan Ruby 3.3.13 pada tanggal yang sama. Server uji tidak memuat data pelanggan.

Masalah: patch pertama belum menutup semua celah, dan update GitLab saja bisa gagal

Server yang ditambal pada 12 Oktober masih rentan terhadap CVE-2026-110264. Server dengan Ruby sendiri bisa tetap rentan sesudah update GitLab.

GitLab merilis patch untuk CVE-2026-97229 pada 12 Oktober 2026. 9 hari kemudian, rilis patch GitLab 21 Oktober menutup celah kedua, CVE-2026-110264, yang ada di semua versi sejak 7.0. Jadi admin yang sudah patch pada 12 Oktober harus update lagi.

Masalah kedua lebih licin. Menurut laporan insiden Alpine Linux, sebuah akun baru menguji GitLab Alpine Linux pada 20 Oktober, lalu menyerang pada 21 Oktober. Worker GitLab crash 8 kali. Alpine sudah naik ke GitLab 19.3.6, tetapi image mereka memakai Ruby biasa, jadi celah tetap terbuka.

Alpine menutup GitLab, membangun ulang server dari nol, reset semua password, dan mengganti secret GitLab pada 27 sampai 28 Oktober. Alpine tidak menemukan bukti kode penyerang berjalan, tetapi menulis bahwa kemungkinan itu tidak bisa disingkirkan. Sehari kemudian, CISA KEV memasukkan CVE-2026-97229 ke daftar celah yang sudah dieksploitasi.

Bulan ini kami juga membahas celah PHP2Shell dan celah kernel PwnEscape. Pola yang sama muncul lagi: jarak dari patch ke serangan hanya beberapa hari. Untuk GitLab, BleepingComputer mencatat pada 22 Oktober bahwa CISA sudah menandai 5 celah GitLab sebagai dieksploitasi sejak November 2021.

Cara kerja: regex yang dirakit khusus memicu integer overflow

Kedua celah memakai pola yang sama: regex yang dirakit khusus membuat angka di compiler regex melewati batasnya. Update GitLab ke rilis 29 Oktober menutup keduanya.

Bagian ini memakai ringkasan dari advisory resmi. Tujuannya membantu Anda memilih langkah yang tepat, bukan menjelaskan cara menyerang.

CVE-2026-97229: compiler regex CI/CD

Menurut rilis patch GitLab 12 Oktober, validasi regex di konfigurasi CI/CD kurang ketat. Regex yang dirakit khusus memicu integer overflow (CWE-190), lalu kode bisa jalan di server GitLab. Versi terdampak: 19.2 sebelum 19.2.8, 19.3 sebelum 19.3.5, dan 19.4 sebelum 19.4.2.

Rapid7 berhasil mereproduksi eksekusi kode di image GitLab CE tanpa patch. Rapid7 juga mencatat syaratnya: penyerang harus bisa menaruh konfigurasi CI/CD. Instance yang membuka pendaftaran akun untuk umum menghapus syarat itu.

CVE-2026-110264: compiler regex, semua versi sejak 7.0

Menurut rilis patch GitLab 21 Oktober, pada kondisi tertentu, pengguna tanpa login bisa menjalankan kode di server dengan regex yang memicu integer overflow saat dikompilasi. GitLab belum membuka kondisi persisnya. Celah ini ada di semua versi sejak 7.0, jadi GitLab memberi patch untuk 7 cabang.

Per 22 Oktober, eSecurityPlanet mengutip Censys: belum ada eksploitasi yang terkonfirmasi dan belum ada PoC yang terverifikasi untuk CVE-2026-110264. Status ini bisa berubah cepat, karena akarnya sama dengan celah yang sudah diserang.

Akar masalah: Onigmo di dalam Ruby

Menurut advisory Ruby 23 Oktober, kedua celah berasal dari bug di Onigmo, mesin regex di dalam Ruby. GitLab menambal Ruby di paket dan image resminya. Ruby merilis 3.3.13, 3.4.12, dan 4.0.9 dengan perbaikan yang sama pada 23 Oktober 2026.

Advisory Ruby menulis bahwa aplikasi Ruby lain juga terdampak bila aplikasi itu mengompilasi regex dari input pengguna, contohnya Regexp.new(input). Regexp.timeout dan batas panjang pola tidak melindungi. Catatan KEV juga menulis bahwa produk lain bisa terdampak oleh bug Ruby yang sama.

Apa yang diubah patch

Patch Ruby memperbaiki 3 bug: double free saat parsing gagal, integer overflow pada ukuran pola, dan overflow ID internal pada pola dengan banyak pengulangan. Rilis 29 Oktober dari GitLab memuat semua patch itu, ditambah pencabutan kepercayaan 8 sertifikat CA eMudhra yang kuncinya bocor (CVE-2026-111943).

Siapa yang paling berisiko

GitLab yang terbuka ke internet dengan pendaftaran akun terbuka paling berisiko. Instalasi dengan Ruby sendiri butuh 2 update.

Cara GitLab dipasang menentukan apa yang harus Anda update. Tabel ini merangkum GitLab, advisory Ruby 23 Oktober, dan laporan insiden Alpine Linux.

Cara pasang	Yang Anda update	Bukti aman
Paket Omnibus (.deb, .rpm)	GitLab	Versi GitLab di langkah 1
Image Docker gitlab/gitlab-ce atau gitlab-ee	Tag image, lalu buat ulang container	Versi GitLab di langkah 1
Helm chart resmi	Versi chart dan image GitLab	Versi GitLab di halaman Help
Instalasi dari source	GitLab dan Ruby	Langkah 1 dan langkah 2
Image buatan sendiri atau image distro	GitLab dan Ruby di image	Langkah 1 dan langkah 2
GitLab.com dan GitLab Dedicated	Tidak ada	Sudah ditambal GitLab

Skala paparannya besar. eSecurityPlanet mengutip Censys: 81.820 host GitLab terlihat dari internet pada 21 Oktober. BleepingComputer mengutip Shadowserver: lebih dari 2.700 instance GitLab CE terekspos. Kedua angka mengukur hal yang berbeda, jadi jangan menjumlahkannya.

Versi yang sudah memuat patch

GitLab merilis patch untuk 7 cabang. Kolom tengah menutup kedua CVE. Kolom kanan adalah target hari ini, karena memuat juga patch 29 Oktober.

Cabang	Minimum untuk 2 CVE (21 Okt)	Rilis terbaru (29 Okt)
19.5	19.5.1	19.5.3
19.4	19.4.3	19.4.5
19.3	19.3.6	19.3.7
19.2	19.2.9	19.2.10
19.1	19.1.9	19.1.10
19.0	19.0.10	19.0.11
18.11	18.11.13	18.11.14
18.10 ke bawah	Tanpa patch di cabang ini	Upgrade ke cabang yang didukung

Cabang 18.10 ke bawah tidak mendapat patch. Pakai Upgrade Path dari GitLab untuk melihat urutan upgrade sampai cabang yang didukung. Lompatan antarcabang besar butuh beberapa tahap dan waktu migrasi.

Rilis 29 Oktober juga meminta update GitLab Runner self-hosted ke 19.5.1. Runner memeriksa sertifikat sendiri, jadi update GitLab tidak ikut mengubahnya.

Prasyarat sebelum mulai

• Akses SSH dengan hak sudo ke server GitLab, atau akses docker exec ke container GitLab.
• Akun admin GitLab untuk Admin area.
• Daftar semua instance GitLab: produksi, staging, mirror, dan GitLab bawaan vendor.
• Ruang disk untuk backup, dan jadwal downtime singkat untuk server single-node.
• Daftar token dan secret yang tersimpan di GitLab: variabel CI/CD, deploy key, dan token Runner.

Langkah 1: Cek versi GitLab di setiap server

Simpan skrip ini sebagai cek-gitlab.sh. Skrip membaca versi GitLab, lalu membandingkannya dengan versi minimum dan versi terbaru untuk cabangnya.

v=$(cat /opt/gitlab/embedded/service/gitlab-rails/VERSION); v=${v%%-*}
case ${v%.*} in
  19.5) min=19.5.1 new=19.5.3;;  19.4) min=19.4.3 new=19.4.5;;
  19.3) min=19.3.6 new=19.3.7;;  19.2) min=19.2.9 new=19.2.10;;
  19.1) min=19.1.9 new=19.1.10;; 19.0) min=19.0.10 new=19.0.11;;
  18.11) min=18.11.13 new=18.11.14;;
  *) echo "$v: cabang tanpa patch. Upgrade ke 18.11 atau lebih baru."; exit;;
esac
lt() { [ "$1" != "$2" ] && [ "$(printf '%s\n' "$1" "$2" | sort -V | head -1)" = "$1" ]; }
if lt "$v" "$min"; then echo "$v: RENTAN 2 CVE CVSS 10. Update ke $new."
elif lt "$v" "$new"; then echo "$v: aman dari 2 CVE. Update ke $new untuk rilis 29 Okt."
else echo "$v: versi terbaru per 29 Okt 2026."; fi

Jalankan skrip di server paket Omnibus, atau kirim skrip ke container Docker.

sudo bash cek-gitlab.sh                 # paket Omnibus
docker exec -i gitlab bash < cek-gitlab.sh   # container Docker

Untuk instalasi dari source, ganti path di baris pertama menjadi /home/git/gitlab/VERSION. Anda juga bisa membuka halaman Help (bantuan) di GitLab, yang menampilkan versi untuk pengguna yang login.

Cek hasil: Output menulis "versi terbaru per 29 Okt 2026". Hasil "RENTAN" berarti server harus update hari ini. Hasil "aman dari 2 CVE" berarti kedua celah sudah tertutup, tetapi rilis 29 Oktober belum terpasang.

Langkah 2: Cek Ruby bila GitLab memakai Ruby sendiri

Langkah ini hanya untuk instalasi dari source dan image buatan sendiri. Simpan skrip ini sebagai cek-ruby.sh, lalu jalankan dengan Ruby yang menjalankan GitLab.

ruby -e 'fix = { "3.3" => "3.3.13", "3.4" => "3.4.12", "4.0" => "4.0.9" }
  v = RUBY_VERSION; f = fix[v[/\A\d+\.\d+/]]
  if f.nil? then puts "#{v}: cabang di luar advisory Ruby. Upgrade Ruby."
  elsif Gem::Version.new(v) < Gem::Version.new(f) then puts "#{v}: RENTAN. Update Ruby ke #{f}."
  else puts "#{v}: memuat patch Onigmo." end'

Pada uji kami, Ruby di image GitLab 19.3.4 dan 19.5.3 resmi sama-sama menulis 3.3.12. Berkas libruby di kedua image berbeda, sesuai catatan Alpine bahwa GitLab menambal Ruby saat build. Jadi, jangan jalankan langkah 2 untuk paket resmi. Hasilnya akan menulis RENTAN, padahal versi GitLab sudah aman.

Cek hasil: Untuk Ruby sendiri, output menulis "memuat patch Onigmo". Bila Anda memakai image alpinelinux/gitlab, laporan insiden Alpine Linux meminta Anda menarik ulang tag 19.3.6. Image yang ditarik sebelum 27 Oktober masih rentan.

Langkah 3: Backup, lalu update GitLab

Backup konfigurasi dan data dulu, lalu pasang versi patch di cabang yang sama. Versi patch di cabang yang sama tidak butuh urutan upgrade khusus.

sudo tar -czf /root/gitlab-config-$(date +%F).tgz /etc/gitlab
sudo gitlab-backup create
sudo apt update
sudo apt install gitlab-ce=19.3.7-ce.0   # pakai versi cabang Anda, gitlab-ee untuk EE

Pada keluarga RHEL, pakai perintah ini.

sudo dnf install 'gitlab-ce-19.3.7*'

Untuk Docker Compose, ubah tag image, lalu buat ulang container.

# docker-compose.yml: image: gitlab/gitlab-ce:19.3.7-ce.0
docker compose pull
docker compose up -d

Arsip /etc/gitlab menyimpan gitlab.rb dan gitlab-secrets.json, yang tidak masuk backup data. panduan backup GitLab menjelaskan detailnya. Rilis ini memuat migrasi database, jadi server single-node mengalami downtime sampai migrasi selesai.

Untuk instalasi dari source, update Ruby lebih dulu ke versi di langkah 2, lalu update GitLab. Untuk image buatan sendiri, build ulang image dengan Ruby yang sudah ditambal.

Cek hasil: Ulangi langkah 1. Output harus menulis "versi terbaru per 29 Okt 2026". Lalu jalankan sudo gitlab-ctl status dan pastikan semua service berjalan.

Langkah 4 (opsional): Kunci akses sementara bila belum bisa update

Langkah ini hanya untuk jeda pendek sampai update selesai. Rapid7 menulis bahwa pembatasan akses hanya menutup jalur yang sudah diperagakan, bukan bug-nya.

Matikan pendaftaran akun baru dan batasi level Public. Lewat UI, buka Admin area > Settings > General, lalu ubah Sign-up restrictions (pembatasan pendaftaran) dan Visibility and access controls (kontrol visibilitas). Lewat terminal, pakai perintah ini.

sudo gitlab-rails runner '
  Gitlab::CurrentSettings.update!(signup_enabled: false,
    restricted_visibility_levels: [Gitlab::VisibilityLevel::PUBLIC])
  s = Gitlab::CurrentSettings.current_application_settings
  puts "signup_enabled=#{s.signup_enabled} restricted=#{s.restricted_visibility_levels}"
  puts "project publik: #{Project.where(visibility_level: Gitlab::VisibilityLevel::PUBLIC).count}"'

Level Public yang dibatasi hanya mencegah project publik baru. Project publik yang sudah ada tetap publik, jadi ubah project yang tidak perlu publik menjadi Internal atau Private. dokumentasi sign-up restrictions dan dokumentasi visibility menjelaskan efek setiap pengaturan.

Bila GitLab tidak perlu diakses dari internet, tutup aksesnya dengan VPN atau allowlist IP sampai update selesai. Langkah ini paling kuat di antara langkah sementara.

Cek hasil: Output menulis signup_enabled=false dan restricted=[20]. Halaman sign-in tidak lagi menampilkan tautan untuk mendaftar.

Langkah 5: Periksa tanda server sudah disentuh

Serangan yang gagal meninggalkan crash. Serangan yang berhasil bisa tanpa jejak di log web, seperti yang ditulis laporan insiden Alpine Linux. Jalankan perintah ini untuk periode sejak 12 Oktober 2026.

sudo zgrep -cE '\[BUG\]|Segmentation fault' /var/log/gitlab/puma/puma_stderr.log*
sudo zcat -f /var/log/gitlab/nginx/gitlab_access.log* | awk '$9 == 502' | wc -l
sudo gitlab-rails runner '
  t = Time.utc(2026, 10, 12)
  baru = User.where("created_at > ?", t)
  baru.find_each { |u| puts "akun #{u.username} #{u.created_at.to_date} #{u.state}" }
  Ci::Pipeline.where("created_at > ?", t).where(user_id: baru.select(:id))
    .find_each { |p| puts "pipeline #{p.id} #{p.project.full_path} #{p.user.username}" }'

Cari 4 pola. Pertama, crash native worker Puma, yang ditulis Ruby sebagai [BUG] atau Segmentation fault. Kedua, HTTP 502 beruntun dan job CI yang gagal tanpa sebab. Lokasi setiap log ada di dokumentasi log GitLab.

Ketiga, akun baru yang tidak Anda kenal. Keempat, pipeline dari akun baru itu. GitLab juga merilis deteksi resmi untuk kedua CVE, contohnya "Onigmo native worker crash" dan "Org mode render error burst".

Cek hasil: Hitungan crash 0, tidak ada lonjakan 502, dan semua akun baru Anda kenal. Bila ada tanda, isolasi server dan simpan log. Lalu ikuti langkah Alpine: bangun ulang server, reset semua password, ganti secret GitLab, dan ganti token, variabel CI/CD, deploy key, serta token Runner.

Contoh: 1 sore respons untuk 3 server GitLab

Simulasi ini memakai data dummy. Nama server, waktu, dan hasil bukan data pelanggan.

Waktu (WIB)	Server dummy	Yang dicek	Hasil	Tindakan
15.00	git-kantor (Omnibus 19.3.4)	Langkah 1	RENTAN 2 CVE	Backup, lalu apt install 19.3.7
15.40	git-kantor	Ulangi langkah 1	Versi terbaru per 29 Okt	Lanjut ke langkah 5
16.00	git-klien (Docker 19.4.2)	Langkah 1	RENTAN, terbuka untuk sign-up	Langkah 4, lalu ganti tag ke 19.4.5
16.30	git-lab (source, Ruby 3.3.12)	Langkah 1 dan 2	GitLab 19.3.6, Ruby RENTAN	Update Ruby ke 3.3.13, lalu GitLab 19.3.7
17.30	git-klien	Langkah 5	2 akun asing, 1 pipeline dari akun asing	Isolasi, simpan log, mulai respons insiden

Pelajaran dari simulasi: server dengan paket resmi selesai paling cepat. Server dengan pendaftaran terbuka butuh pemeriksaan akun, bukan hanya update.

Siapa yang memasang patch

Tanggung jawab patch berbeda per cara hosting. Tabel ini membantu Anda tahu siapa yang harus bergerak hari ini.

Cara hosting	Pemegang patch	Yang Anda kerjakan
VM atau server sendiri	Tim IT Anda	Langkah 1 sampai 5
Container atau Kubernetes	Tim yang mengelola image dan chart	Ganti tag atau chart, lalu langkah 1 dan 5
GitLab yang dikelola vendor atau konsultan	Vendor	Minta bukti versi tertulis, lalu minta hasil langkah 5
GitLab.com	GitLab	Tidak ada untuk 2 CVE ini

Rekomendasi Rama Digital: bila GitLab Anda menyimpan kode produk dan secret produksi, perlakukan setiap tanda di langkah 5 sebagai insiden. Kode sumber yang bocor membuka jalan ke server lain. standar audit keamanan aplikasi memuat cara audit lanjutan.

Checklist hari ini

1. Inventaris semua instance GitLab. Pemilik: admin server. Bukti: daftar host dengan cara pasang.
2. Cek versi dengan langkah 1. Pemilik: admin server. Bukti: output skrip per host.
3. Cek Ruby dengan langkah 2 untuk instalasi source dan image sendiri. Pemilik: admin server. Bukti: output skrip.
4. Backup, lalu update ke rilis 29 Oktober. Pemilik: admin server. Bukti: output langkah 1 sesudah update.
5. Update GitLab Runner self-hosted ke 19.5.1. Pemilik: tim DevOps. Bukti: versi Runner di Admin area.
6. Pasang langkah 4 di server yang belum bisa update. Pemilik: admin GitLab. Bukti: output runner.
7. Periksa tanda dengan langkah 5. Pemilik: admin server. Bukti: output perintah, disimpan bersama log.
8. Berhenti bila semua server menulis "versi terbaru" dan langkah 5 bersih. Bila ada tanda, hentikan kerja patch dan mulai respons insiden.

Pertanyaan yang sering muncul

Apakah pengguna GitLab.com perlu melakukan sesuatu? Tidak untuk 2 CVE ini. GitLab sudah menambal GitLab.com dan GitLab Dedicated. Langkah di artikel ini untuk GitLab yang Anda pasang sendiri.

Saya sudah update pada 12 Oktober. Apakah server saya aman? Belum. Patch 12 Oktober hanya menutup CVE-2026-97229. Update lagi ke rilis 21 Oktober atau 29 Oktober untuk menutup CVE-2026-110264.

Kenapa Ruby di GitLab resmi masih menulis 3.3.12? GitLab menambal Ruby saat build tanpa mengubah nomor versinya. Untuk paket resmi, versi GitLab adalah buktinya. Cek Ruby hanya untuk instalasi source dan image buatan sendiri.

Apakah mematikan sign-up sudah menutup celah? Tidak. Langkah itu menutup 1 jalur yang sudah diperagakan. Kondisi CVE-2026-110264 belum dibuka GitLab, jadi hanya update yang menutup celah.

Apakah aplikasi Ruby on Rails saya juga terdampak? Bisa, bila aplikasi mengompilasi regex dari input pengguna. Advisory Ruby meminta update ke 3.3.13, 3.4.12, atau 4.0.9. Aplikasi yang hanya memakai regex tulisan developer tidak terdampak.

Bagaimana saya tahu server sudah dibobol? Cari crash worker, HTTP 502 beruntun, akun baru, dan pipeline dari akun baru, seperti di langkah 5. Log yang bersih tidak membuktikan server aman.

Langkah berikutnya

Batas yang tetap berlaku: update menutup 2 celah ini, tetapi tidak menghapus akses yang mungkin sudah tertanam sebelum patch. Bila server Anda menunjukkan tanda di langkah 5, atau Anda butuh bantuan memeriksa pipeline dan secret sesudah insiden, pakai Vibe Code Rescue untuk audit dan stabilisasi. Untuk 1 kendala yang mendesak hari ini, Jadwalkan sesi 30 menit.

Sumber

• rilis patch GitLab 12 Oktober: CVE-2026-97229, CVSS 10.0, versi terdampak.
• rilis patch GitLab 21 Oktober: CVE-2026-110264, CVSS 10.0, 7 cabang patch, deteksi.
• rilis GitLab 29 Oktober: rilis terbaru, CVE-2026-111943, dan Runner 19.5.1.
• advisory Ruby 23 Oktober: 3 bug Onigmo dan versi Ruby yang aman.
• laporan insiden Alpine Linux: linimasa serangan dan respons, 28 dan 30 Oktober 2026.
• CISA KEV: CVE-2026-97229 masuk KEV, 29 Oktober 2026.
• CVE-2026-97229 dan CVE-2026-110264: catatan CVE, CWE-190.
• Rapid7: reproduksi dan mitigasi sementara.
• SecurityWeek: ringkasan serangan ke Alpine.
• BleepingComputer: angka Shadowserver dan riwayat KEV GitLab.
• eSecurityPlanet: angka Censys dan status eksploitasi CVE-2026-110264.
• Upgrade Path, panduan backup GitLab, dokumentasi sign-up restrictions, dokumentasi visibility, dan dokumentasi log GitLab.