Kalau kamu ngelola GitLab self-managed di kantor atau buat tim sendiri, ada satu isu yang wajib banget kamu cek sekarang juga. Bukan bug remeh ini kelas remote code execution (RCE), alias attacker bisa nyuruh server kamu jalanin perintah sistem tanpa perlu jadi admin dulu.
Yang bikin runyam, bug ini sebenarnya udah dipatch GitLab enam minggu lalu, tapi nggak ditandai sebagai security fix. Jadi banyak tim IT yang review changelog patch itu dan mikir “ah, cuma bug fix biasa” padahal di baliknya ada celah RCE penuh. Baru tanggal 24 Juli 2026 kemarin, exploit-nya dipublikasikan lengkap oleh tim riset depthfirst, dan sekarang siapa aja yang paham exploit-nya bisa mempraktikkannya.
Yuk kita bedah pelan-pelan biar kamu ngerti apa yang terjadi, kenapa bisa separah ini, dan langkah apa yang perlu diambil.
Siapa yang Kena Dampak
Kalau kamu authenticated user di GitLab yang punya akses push ke satu project aja (nggak perlu admin, nggak perlu akses CI/runner, nggak perlu project orang lain), kamu bisa memicu exploit ini. Nggak butuh interaksi dari korban sama sekali.
Versi yang kena RCE pada GitLab
Soal versi, GitLab CE/EE yang ada di rentang 15.2.0 sampai 18.10.7 sudah aman kalau di-upgrade ke 18.10.8. Yang di rentang 18.11.0 sampai 18.11.4 perlu naik ke 18.11.5. Sementara yang di 19.0.0 sampai 19.0.1 tinggal upgrade ke 19.0.2. Di sisi gem Oj sendiri, versi 3.13.0 sampai 3.17.1 yang bermasalah, dan sudah diperbaiki di versi 3.17.3.
Semua tier kena Free sampai Ultimate, CE maupun EE. Ruby-nya sendiri aman, yang bermasalah adalah gem Oj (parser JSON berbasis Ruby yang komponen intinya ditulis pakai C native).
Gimana Cara Kerjanya
Inti masalahnya ada di fitur notebook diff GitLab fitur yang nampilin perbedaan isi file Jupyter Notebook (.ipynb) waktu kamu lihat commit diff. Fitur ini dijalankan oleh gem internal bernama ipynbdiff, yang manggil Oj buat parsing JSON dari file notebook tadi.
karena isi notebook itu sepenuhnya dikontrol attacker (tinggal commit file .ipynb sendiri), maka data yang diparsing Oj juga sepenuhnya bisa direkayasa attacker.
Di dalam Oj sendiri ada dua bug memory corruption
Stack overflow di parser kalau nesting JSON-nya sengaja dibikin lebih dari 1.024 level, buffer internal parser meluap sampai attacker bisa ambil alih fungsi callback parser.
Integer truncation di key object key JSON yang panjangnya 65.565 byte kepotong jadi cuma disimpan sebagai angka 16-bit, dan celah ini bikin parser balikin pointer heap yang masih “hidup” ke proses aplikasi.
Attacker tinggal commit beberapa notebook yang udah dirancang khusus, buka commit diff-nya (di sinilah pointer heap-nya kebocor lewat tampilan diff), ulangi sampai attacker tahu lokasi library di memory, lalu kirim dua notebook susulan buat memicu payload. ujung-ujungnya, attacker bisa jalanin perintah sistem lewat fungsi system(), dengan privilege user git akun yang dipakai proses Puma (server aplikasi Ruby-nya GitLab).
kalau attacker berhasil sampai tahap ini, yang bisa mereka jangkau tergantung isolasi server kamu, tapi biasanya termasuk: source code, secret Rails, kredensial service internal, data CI/CD, dan layanan lain yang bisa diakses dari server itu.
Kenapa Sempat Kelewat dari Radar
ini bagian yang paling bikin gregetan buat tim security. Waktu GitLab merilis patch tanggal 10 Juni 2026, perbaikan buat masalah ini cuma nongol sebagai “bump versi Oj ke 3.17.3” di daftar bug fix biasa bukan di tabel security fix. Nggak ada CVE, nggak ada skor CVSS, dan sama sekali nggak disebut soal rantai exploit lewat notebook diff.
Buat tim yang cuma cek tabel security advisory pas nge-triage rilis patch, wajar banget kalau update ini nggak dianggap prioritas. Padahal isinya patch RCE penuh.
timeline singkatnya:
- 21 Mei 2026 : depthfirst laporin dua bug Oj ke maintainer-nya
- 27 Mei 2026 : fix di-merge4 Juni 2026 — Oj 3.17.3 rilis
- 5 Juni 2026 : depthfirst laporin rantai exploitnya ke GitLab lewat HackerOne
- 8 Juni 2026 : GitLab konfirmasi
- 10 Juni 2026 : patch resmi rilis (tanpa label security)
- 24 Juli 2026 : exploit dipublikasikan penuh.
gak ada CVE yang diajukan buat kedua bug ini, baik dari sisi Oj maupun rantai exploitnya di GitLab. Menurut peneliti dari depthfirst, itu lebih ke soal gimana proses disclosure-nya dikoordinasikan, bukan indikasi tingkat keparahannya rendah.
Hati-Hati Kalau Pakai Helm Chart atau Operator
Ini jebakan yang gampang kelewat: kalau kamu deploy GitLab lewat Helm chart atau Kubernetes Operator, jangan cek versi chart atau Operator-nya. Yang harus kamu cek adalah versi GitLab di dalam image Webservice yang nge-jalanin Puma, itu yang nentuin apakah instalasi kamu rentan atau nggak.
satu hal lagi yang perlu dicatat: kalau instalasi kamu masih di rentang 15.2 sampai 18.9, kamu nggak akan dapat backport patch ini, karena versi-versi itu udah keluar dari jalur maintenance resmi GitLab. Solusinya cuma satu: upgrade ke versi yang masih didukung.
seberapa Gampang Exploit Ini “Dipindah” ke Target Lain
Exploit publik yang beredar sekarang dirancang khusus buat GitLab 18.11.3 di arsitektur x86-64, offset gadget, kondisi register, sampai perilaku alokator memori (jemalloc) semuanya diambil dari image itu, jadi nggak bisa langsung “tempel-pakai” ke target sembarangan.
tapi jangan salah, bug di Oj-nya sendiri bersifat umum. Menurut peneliti depthfirst, buat mindahin exploit ke build GitLab lain di arsitektur yang sama, biasanya cuma perlu penyesuaian kecil di offset gadget atau simbol, bahkan sering kali offset itu nggak berubah sama sekali di versi-versi yang berdekatan, karena gadget-nya datang dari Ruby dan library sistem, bukan dari kode GitLab sendiri.
Yang jadi penghalang sesungguhnya adalah arsitektur. Pindah ke ARM64 berarti beda calling convention, beda gadget, beda pemakaian register, dan kemungkinan beda perilaku heap juga jadi build Ruby, libc, allocator, dan environment kompilasi jadi lebih menentukan ketimbang sekadar versi GitLab-nya.
Soal kecepatan eksekusi, depthfirst mencatat proses pencarian lokasi memory butuh sekitar 5–10 menit di instalasi baru dengan dua worker, dan bisa makan waktu 1–2 jam di server yang udah lama nyala.
Apa yang Harus Kamu Lakukan Sekarang
- Cek versi GitLab kamu sekarang juga, kalau ada di rentang 15.2.0–18.10.7, 18.11.0–18.11.4, atau 19.0.0–19.0.1, kamu rentan.
- Upgrade ke 18.10.8, 18.11.5, atau 19.0.2, ini satu-satunya solusi resmi. Sampai tulisan ini dibuat, belum ada workaround konfigurasi yang tervalidasi dari GitLab maupun depthfirst.
- Kalau belum bisa upgrade sekarang, langkah paling masuk akal adalah membatasi siapa aja yang boleh push project, karena semua yang bisa push otomatis bisa memicu jalur notebook diff ini. Tapi ini bukan solusi permanen, cuma mengurangi eksposur sementara. Untuk konfigurasi spesifik ke instalasi kamu, tetap disarankan konsultasi langsung ke tim support GitLab.
- kalau pakai Helm/Operator, jangan cuma cek versi chart-nya, masuk ke image Webservice dan cek versi GitLab aktualnya.
- Kalau server kamu masih di versi 15.2–18.9, nggak ada backport buat kamu. Rencanakan upgrade ke versi yang masih dalam masa dukungan.
Kasus ini jadi pengingat bagus buat kita semua: nggak semua patch security itu “berteriak” lewat label CVE atau tabel security advisory. Kadang perbaikan paling kritis nyempil di antara daftar bug fix biasa. Kalau kamu tim yang ngurusin infrastruktur, kebiasaan baiknya adalah tetap update rutin ke versi terbaru
Bukan cuma pas ada CVE yang muncul di radar.Sampai saat ini RCE pada GitLab belum kasih tanggapan resmi soal kenapa fix ini nggak diklasifikasikan sebagai security issue, dan apakah bakal ada CVE yang dikeluarkan belakangan. baca artikel poc di https://hight.id/