Bagi banyak perusahaan teknologi, bank, startup, hingga instansi pemerintah di Indonesia, GitLab yang di-hosting sendiri (self-managed) adalah jantung proses pengembangan: di sanalah kode sumber, pipeline CI/CD, token deployment, dan rahasia lingkungan produksi berkumpul. Dalam rentang sekitar enam minggu terakhir, GitLab merilis perbaikan untuk tiga celah berkeparahan maksimum atau mendekati maksimum. Dua di antaranya, CVE-2026-85706 dan CVE-2026-97229, sudah dikonfirmasi dieksploitasi aktif dan masuk katalog Known Exploited Vulnerabilities (KEV) milik CISA. Artikel ini merangkum apa yang dilaporkan sumber publik, mengapa server repositori adalah target bernilai tinggi, dan langkah audit yang realistis bagi tim di Indonesia.
Ringkasan Tiga Celah yang Dilaporkan
Berikut rangkuman berdasarkan pemberitaan BleepingComputer dan TechRadar. Detail teknis, nomor versi, dan skor dapat berubah atau dikoreksi; selalu rujuk advisori resmi GitLab sebagai sumber utama sebelum bertindak.
- CVE-2026-85706 (CVSS 10/10, path traversal). Dilaporkan pada pertengahan September 2026. Celah ini berada pada API commit repositori dan disebabkan oleh penegakan autentikasi yang hilang serta pembatasan path yang tidak memadai. Menurut watchTowr, penyerang dapat membaca berkas arbitrer hanya dengan satu permintaan HTTP tanpa autentikasi. CISA memasukkannya ke KEV dengan tenggat tiga hari bagi lembaga federal AS. Versi perbaikan yang dilaporkan: 19.3.2, 19.2.6, dan 19.1.
- CVE-2026-97229 (CVSS 10/10, eksekusi kode jarak jauh). Integer overflow pada Regular Expression Compiler di jalur CI/CD, yaitu komponen yang mengurai dan mengevaluasi ekspresi reguler dalam berkas konfigurasi pipeline. Menurut GitLab, penyerang tanpa autentikasi dapat mengeksekusi kode arbitrer di server pada kondisi tertentu. CISA menambahkannya ke KEV pada 29 Oktober 2026 dan GitLab menyebut telah mendeteksi percobaan eksploitasi. Versi perbaikan yang dilaporkan: 19.4.2, 19.3.5, dan 19.2.8.
- CVE-2026-110264 (berkeparahan maksimum, eksekusi kode jarak jauh). Juga integer overflow (CWE-190) pada Regular Expression Compiler, diumumkan sekitar 22 Oktober 2026. Pelapornya adalah peneliti berhandle "joaxcar" melalui program bug bounty HackerOne GitLab, orang yang sama dengan pelapor CVE-2026-97229. Skor CVSS numerik tidak disebut dalam artikel yang kami rujuk, dan status eksploitasi di dunia nyata belum dinyatakan. Versi perbaikan yang dilaporkan: 19.5.1, 19.4.3, 19.3.6, 19.2.9, 19.1.9, 19.0.10, dan 18.11.13.
Perhatikan bahwa nomor versi perbaikan berbeda untuk tiap CVE. Instance yang sudah ditambal untuk satu celah belum tentu aman dari yang lain. Cara paling sederhana adalah naik ke rilis patch terbaru pada cabang yang Anda pakai, bukan menambal satu per satu.
Mengapa Server GitLab Adalah Target Bernilai Tinggi
Penyerang yang menguasai server GitLab memperoleh jauh lebih banyak daripada sekadar akses ke satu aplikasi. Beberapa aset yang biasanya ada di sana:
- Kode sumber dan riwayat commit yang memuat logika bisnis, endpoint internal, dan kadang kredensial yang tidak sengaja ter-commit.
- Variabel CI/CD berisi kunci cloud, token registry, kredensial basis data, dan sertifikat penandatanganan.
- Runner yang mengeksekusi job dan sering memiliki akses jaringan ke lingkungan staging maupun produksi.
- Kemampuan mengubah pipeline, sehingga artefak yang dikirim ke pelanggan dapat disisipi kode berbahaya. Inilah esensi serangan rantai pasok perangkat lunak.
Karena itu, insiden pada GitLab self-managed sebaiknya diperlakukan sebagai potensi kompromi kredensial seluruh organisasi, bukan insiden satu server. Pola yang sama telah kita bahas pada kasus gateway AI yang berubah menjadi pencuri kunci API: aset yang menyimpan banyak rahasia menjadi sasaran utama.
Anatomi Singkat: Integer Overflow pada Pengompilasi Regex
Dua dari tiga celah berakar pada kelas kelemahan yang sama, yaitu integer overflow (CWE-190). Secara konsep, overflow terjadi ketika sebuah nilai numerik, misalnya panjang buffer atau jumlah pengulangan dalam ekspresi reguler, melampaui batas tipe datanya lalu "melingkar" menjadi nilai kecil atau negatif. Program kemudian mengalokasikan memori terlalu kecil dan menulis data lebih besar dari yang dialokasikan, sehingga memori yang berdekatan rusak. Pada kondisi tertentu, kerusakan memori semacam ini dapat diarahkan menjadi eksekusi kode.
Yang membuat jalur ini berbahaya adalah lokasinya: ekspresi reguler dalam konfigurasi CI/CD diproses otomatis oleh server, dan GitLab menyebut kondisi eksploitasi tidak memerlukan autentikasi. Artikel sumber tidak menjelaskan teknik eksploit secara rinci, dan kami tidak akan berspekulasi lebih jauh. Pelajaran umumnya jelas: komponen parser yang menerima masukan yang dapat dikendalikan pihak luar perlu diperlakukan sebagai permukaan serangan.
Skala Paparan
Shadowserver melacak sekitar 2.700 hingga 2.800 instance GitLab Community Edition yang terpapar ke internet. Angka ini tidak menyebut berapa yang sudah ditambal atau yang merupakan honeypot, sehingga jangan dibaca sebagai jumlah instance rentan. Namun, ia memberi gambaran bahwa penyerang memiliki daftar sasaran siap pindai. Dalam pengalaman respons insiden, jeda antara advisori dan pemindaian massal biasanya hanya hitungan hari.
Langkah 1: Inventaris dan Pastikan Versi
Mulailah dengan menjawab pertanyaan sederhana: berapa instance GitLab yang kita jalankan, di mana, dan pada versi berapa? Banyak organisasi memiliki instance "bayangan" yang dibuat tim tertentu untuk proyek lama dan terlupakan.
# Cek versi pada instance self-managed (paket Omnibus)
sudo gitlab-rake gitlab:env:info
# Atau lihat versi paket terpasang
dpkg -l | grep -E 'gitlab-(ce|ee)'
rpm -qa | grep -E 'gitlab-(ce|ee)'
Bandingkan hasilnya dengan advisori resmi GitLab untuk cabang yang Anda gunakan, lalu rencanakan peningkatan ke rilis patch terbaru. Ikuti jalur upgrade yang didokumentasikan GitLab, termasuk pencadangan penuh sebelum upgrade.
Langkah 2: Kurangi Paparan Sambil Menunggu Patch
- Batasi akses ke instance hanya dari jaringan internal, VPN, atau daftar IP yang dikenal, bila tidak ada kebutuhan bisnis untuk membukanya ke publik.
- Letakkan instance di belakang reverse proxy atau WAF dan aktifkan pencatatan permintaan lengkap.
- Nonaktifkan pendaftaran akun terbuka bila tidak diperlukan.
- Pastikan runner tidak memiliki akses jaringan lebih luas dari kebutuhan job.
Langkah-langkah ini mengurangi risiko, tetapi tidak menggantikan patch. GitLab sendiri menyatakan peningkatan versi sebagai mitigasi yang direkomendasikan.
Langkah 3: Berburu Jejak Eksploitasi
Untuk CVE-2026-85706, watchTowr menyarankan memeriksa log aplikasi atau web server untuk permintaan HTTP POST ke path API commit repositori yang menyertakan parameter file.path. Contoh pencarian awal pada log (sesuaikan lokasi dan format log Anda):
# Contoh: cari POST ke API commits dengan parameter file.path
sudo grep -h "POST" /var/log/gitlab/nginx/gitlab_access.log* \
| grep "/repository/commits" \
| grep "file.path"
# Cari lonjakan permintaan dari satu alamat IP
sudo awk '{print $1}' /var/log/gitlab/nginx/gitlab_access.log \
| sort | uniq -c | sort -rn | head -20
Untuk dugaan eksekusi kode, periksa proses anak yang tidak lazim dari layanan GitLab (misalnya shell yang dijalankan oleh pengguna git), koneksi keluar baru dari server, berkas baru di direktori sementara, akun admin atau token akses pribadi yang baru dibuat, serta perubahan pada berkas konfigurasi pipeline atau variabel CI/CD yang tidak dikenali. Simpan salinan log dan citra disk sebelum membersihkan apa pun agar bukti forensik tidak hilang.
Langkah 4: Rotasi Rahasia bila Ada Indikasi
Jika ada tanda eksploitasi, atau instance Anda terpapar internet dalam keadaan belum ditambal selama periode eksploitasi aktif, anggap rahasia yang dapat diakses GitLab berpotensi bocor. Prioritaskan rotasi:
- Token dan kunci pada variabel CI/CD, terutama kredensial cloud dan registry.
- Deploy key, token akses pribadi, dan token runner.
- Kredensial basis data dan kunci penandatanganan artefak.
- Secret yang tersimpan di repositori, lalu pindahkan ke secret manager.
Tinjau juga riwayat pipeline dan artefak yang dibangun selama jendela risiko. Bila ada pipeline yang berubah tanpa persetujuan, bangun ulang artefak dari commit yang terverifikasi.
Langkah 5: Perkuat Fondasi Jangka Panjang
- Jadwalkan patching rutin dengan jendela darurat untuk celah yang masuk KEV. Daftar KEV CISA dapat dijadikan pemicu prioritas, sejalan dengan pendekatan triase KEV dan EPSS yang pernah kami bahas.
- Terapkan prinsip hak akses minimal pada runner dan token CI/CD, serta gunakan kredensial berumur pendek (misalnya OIDC ke penyedia cloud) agar rahasia statis berkurang.
- Pisahkan lingkungan: runner produksi tidak berbagi jaringan dengan runner umum.
- Pantau perubahan pipeline dengan aturan persetujuan kode (code owners) pada berkas konfigurasi CI.
- Siapkan rencana respons insiden khusus untuk kompromi platform pengembangan, termasuk prosedur rotasi massal rahasia.
Konteks Hukum dan Kepatuhan di Indonesia
Jika repositori atau variabel CI/CD Anda memuat atau memberi akses ke data pribadi, kompromi server GitLab dapat berimplikasi pada UU No. 27 Tahun 2022 tentang Pelindungan Data Pribadi (UU PDP). Pengendali data memiliki kewajiban menjaga keamanan data dan, bila terjadi kegagalan pelindungan data pribadi, menyampaikan pemberitahuan tertulis kepada subjek data dan lembaga yang berwenang dalam waktu paling lambat 3 x 24 jam (Pasal 46). Tim hukum dan kepatuhan sebaiknya dilibatkan sejak awal investigasi. Di sisi lain, pihak yang mengakses sistem milik orang lain tanpa izin dapat dijerat UU ITE (antara lain Pasal 30), sehingga pemindaian atau pengujian terhadap instance yang bukan milik Anda tidak boleh dilakukan tanpa otorisasi tertulis. Untuk pengujian internal, pastikan ada surat penugasan dan ruang lingkup yang jelas.
Daftar Periksa Cepat
- Temukan semua instance GitLab, termasuk yang terlupakan.
- Catat versi tiap instance dan bandingkan dengan advisori resmi GitLab.
- Upgrade ke rilis patch terbaru pada cabang yang dipakai, setelah mencadangkan data.
- Batasi paparan jaringan selama proses upgrade berlangsung.
- Telusuri log untuk pola yang disarankan peneliti dan indikator pasca-eksploitasi.
- Rotasi rahasia bila ada indikasi kompromi atau paparan lama tanpa patch.
- Dokumentasikan temuan, dan nilai kewajiban notifikasi menurut UU PDP.
Penutup
Tiga celah dalam enam minggu menunjukkan satu hal: platform pengembangan telah menjadi target utama karena menyimpan kunci menuju seluruh infrastruktur. Organisasi yang memperlakukan GitLab seperti server produksi, lengkap dengan inventaris, patching cepat, segmentasi jaringan, dan pemantauan, akan jauh lebih siap menghadapi gelombang berikutnya. Tim Siberindo membantu organisasi Indonesia dalam asesmen keamanan infrastruktur, threat hunting, dan forensik digital; hubungi kami bila Anda memerlukan pendampingan audit atau respons insiden pada platform CI/CD Anda.
Catatan: data dalam artikel ini dirangkum dari pemberitaan publik (BleepingComputer dan TechRadar) per 2 November 2026 dan dapat diperbarui. Verifikasi selalu pada advisori resmi GitLab dan katalog KEV CISA.
