Peringatan untuk Anda yang menjalankan server GitLab sendiri (self-managed). Sebuah celah keamanan dengan skor maksimal 10.0 — CVE-2026-85706 — sudah masuk daftar Known Exploited Vulnerabilities (KEV) CISA dan terbukti dieksploitasi di dunia nyata. Penyerang tidak perlu login: satu permintaan HTTP cukup untuk membaca file apa pun di server GitLab Anda, termasuk file rahasia berisi kunci enkripsi, kredensial database, dan token CI/CD. Jika instance GitLab Anda bisa diakses dari internet, jangan tunda — cek versi dan patch sekarang juga.

Apa Itu CVE-2026-85706 dan Kenapa Berbahaya?

CVE-2026-85706 adalah kombinasi path traversal (CWE-22) dengan hilangnya pemeriksaan autentikasi pada REST API repository commits GitLab (endpoint /api/v4/projects/:id/repository/commits/). Parameter file.path tidak dibatasi ke direktori repositori, dan endpoint-nya tidak mewajibkan login, sehingga penyerang bisa mengirim satu permintaan POST berisi urutan traversal (seperti ../ atau varian yang di-encode) untuk membaca file di luar repositori. Peneliti independen juga melaporkan pola serupa pada API repository files.

Dampaknya bukan sekadar kebocoran data biasa. Server GitLab menyimpan aset paling sensitif milik tim pengembang: gitlab-secrets.json (berisi secret_key_base dan kunci enkripsi terkait), file konfigurasi utama GitLab dan database.yml, kunci SSH, token deploy, serta variabel CI/CD. Kunci-kunci itu bisa menjadi modal untuk memalsukan sesi, membajak pipeline CI/CD, hingga menembus sistem lain yang terhubung dengan server tersebut. Itulah alasan celah ini diberi skor CVSS 10.0, nilai tertinggi.

• Sudah dieksploitasi aktif: CISA menambahkan CVE ini ke katalog KEV pada 11 September 2026, dengan tenggat remediasi yang sangat singkat untuk instansi federal AS — dan pemindaian massal ke server yang belum di-patch mulai terdeteksi tak lama setelah patch dirilis.
• PoC publik beredar: beberapa skrip eksploitasi sudah dipublikasikan, sehingga siapa pun bisa mencobanya tanpa keahlian khusus.
• Syarat eksploitasi ringan: eksploit yang beredar hanya membutuhkan minimal satu project berstatus publik di instance Anda.
• Khusus self-managed: GitLab.com dan GitLab Dedicated sudah di-patch oleh GitLab. Yang wajib bertindak adalah pemilik instalasi GitLab CE/EE self-managed.

Versi Mana yang Terdampak dan Versi Perbaikannya

Menurut catatan rilis resmi GitLab, versi yang terdampak adalah: 18.7 sampai sebelum 18.11.12, 19.0 sampai sebelum 19.0.9, 19.1 sampai sebelum 19.1.8, 19.2 sampai sebelum 19.2.6, dan 19.3 sampai sebelum 19.3.2. Versi perbaikannya: 18.11.12, 19.0.9, 19.1.8, 19.2.6, dan 19.3.2. Rilis utama (19.3.2, 19.2.6, 19.1.8) terbit 10 September 2026; backport untuk 19.0.9 dan 18.11.12 menyusul pada 23 September 2026.

Langkah 1: Cek Versi GitLab Anda

1. Cara tercepat lewat browser: buka halaman /help di instance GitLab Anda, atau buka Admin Area > Overview > Components.
2. Lewat terminal pada instalasi Omnibus, jalankan:

   sudo gitlab-rake gitlab:env:info

   Versi GitLab tampil pada bagian "GitLab information".
3. Atau cek versi paketnya:

   dpkg -l gitlab-ce   # Debian/Ubuntu
   rpm -q gitlab-ce    # RHEL/AlmaLinux/Rocky

Jika versi Anda berada di rentang terdampak di atas, lanjutkan ke langkah berikutnya tanpa menunggu jadwal maintenance.

Langkah 2: Update ke Versi yang Sudah Di-patch

1. Backup terlebih dahulu agar aman:

   sudo gitlab-backup create

2. Upgrade paket GitLab. Untuk Debian/Ubuntu (instalasi Omnibus):

   sudo apt update
   sudo apt install gitlab-ce

   Untuk RHEL/Rocky/AlmaLinux:

   sudo dnf update gitlab-ce

3. Jika perlu versi spesifik, pasang sesuai kebutuhan, misalnya:

   sudo apt install gitlab-ce=19.3.2-ce.0

4. Verifikasi setelah upgrade:

   sudo gitlab-ctl status
   sudo gitlab-rake gitlab:env:info

Untuk deployment Kubernetes/Helm atau Docker, sesuaikan image/tag ke versi aman yang sesuai cabang rilis Anda (19.3.2, 19.2.6, 19.1.8, 19.0.9, atau 18.11.12).

Langkah 3: Periksa Jejak Percobaan Serangan di Log

GitLab merilis aturan deteksi resmi untuk membantu pemilik instance self-managed menemukan percobaan eksploitasi. Idenya: telusuri permintaan ke endpoint commits API yang membawa parameter file.path mencurigakan. Contoh pencarian pada log API (lokasi log dapat berbeda tergantung metode instalasi):

sudo grep -E "repository/commits" /var/log/gitlab/gitlab-rails/api_json.log | grep -Ei "\.\.|%2e|gitlab-secrets" | head -50

Waspadai juga permintaan ke endpoint repository/commits yang datang tanpa token atau sesi login, terutama dalam jumlah banyak dari alamat IP asing, serta entri yang menyebut nama file sensitif seperti gitlab-secrets.json atau database.yml. Jika ada indikasi file sensitif sempat terbaca, jangan berhenti di patching: anggap kredensial sudah bocor dan segera rotasi variabel CI/CD, token deploy, kunci SSH, serta kredensial database yang tersimpan di server GitLab.

Jika Belum Bisa Update Sekarang

• Cabut paparan publik: batasi akses ke instance GitLab hanya dari alamat IP tepercaya atau melalui VPN.
• Ubah visibilitas project menjadi private — eksploit yang beredar membutuhkan minimal satu project publik.
• Tambahkan aturan di WAF atau reverse proxy untuk memblokir pola traversal (seperti ../ dan %2e%2e) yang menuju endpoint repository, sebagai pengaman sementara.

Langkah-langkah di atas hanyalah mitigasi sementara — satu-satunya perbaikan tuntas adalah upgrade ke versi yang sudah di-patch. Server GitLab memegang kunci seluruh alur kerja pengembangan perangkat lunak Anda, jadi prioritaskan pengecekannya hari ini.

Sumber: GitLab Docs — Critical Patch Release 19.3.2, 19.2.6, 19.1.8; CVE-2026-85706 di CVE.org; CISA KEV Catalog (11 September 2026); InfoQ — GitLab Vulnerability Under Active Exploitation.