GitLab CVSS 10 dieksploitasi: validasi data yang keluar

Peringatan CSA Singapura tertanggal 17 September 2026 menyebut CVE-2026-85706 sedang dieksploitasi dan proof-of-concept telah tersedia untuk publik. Kerentanan path traversal tanpa autentikasi dengan skor CVSS 10 ini memungkinkan penyerang membuat repository commits API membuka berkas arbitrer pada server GitLab yang rentan.

Namun, request mencurigakan atau keberhasilan server membaca berkas belum membuktikan isinya diterima penyerang. Panduan validasi GitLab yang diterbitkan pada 17 September 2026 menjelaskan bahwa operator Self-Managed perlu menghubungkan request API, correlation ID, written_bytes, dan api_error untuk menentukan byte yang benar-benar dikirim kepada klien.

Versi terdampak dan tindakan untuk setiap layanan GitLab

CVE-2026-85706 memengaruhi GitLab Community Edition dan Enterprise Edition mulai versi 18.7 hingga sebelum 19.1.8, versi 19.2 sebelum 19.2.6, serta versi 19.3 sebelum 19.3.2. Catatan patch GitLab tanggal 10 September 2026 mencantumkan 19.1.8, 19.2.6, dan 19.3.2 sebagai rilis perbaikan, menyatakan GitLab.com telah memakai versi yang ditambal, serta menyebut pelanggan GitLab Dedicated tidak perlu mengambil tindakan.

Dengan demikian, kebutuhan upgrade dan pemeriksaan log langsung terutama berlaku bagi operator GitLab Self-Managed. Log layanan GitLab.com dan Dedicated berada dalam pengelolaan GitLab, sedangkan administrator Self-Managed harus memastikan rilisnya aman dan memeriksa bukti pada infrastrukturnya sendiri.

Mulai dari request API, bukan status respons

Sebelum upgrade atau restart, salin log yang dapat terputar atau tertimpa. Untuk instalasi paket Linux, bukti utama berada pada seluruh varian api_json.log, log akses GitLab Workhorse, dan log Nginx; instalasi dari source dan deployment Helm menggunakan lokasi berbeda, tetapi request tetap dapat dipasangkan melalui correlation ID.

Dalam api_json.log, cari request POST ke repository commits API yang membawa parameter file.path atau metadata.path. Jangan hanya mencari ejaan literal rute dan parameter: eksploit publik dapat memakai percent-encoding pada bagian rute maupun titik dalam nama parameter.

Periksa setiap nilai path secara terpisah dengan percent-decoding dan penyelesaian segmen direktori seperti ... Request menjadi kandidat ketika salah satu nilainya keluar dari sandbox unggahan yang semestinya; nilai file.path yang tampak normal tidak meniadakan metadata.path berbahaya dalam request yang sama. Catat correlation ID, waktu, path, status respons, dan alamat sumber untuk setiap kandidat.

written_bytes dan api_error membedakan pembacaan dari kebocoran

Gunakan correlation ID kandidat untuk menemukan entri akses yang sama pada log GitLab Workhorse. Nilai written_bytes menunjukkan jumlah byte respons yang ditulis kepada klien, sedangkan api_error pada api_json.log dapat memuat badan kesalahan—termasuk fragmen berkas yang ikut dikirim.

Sebelum menafsirkan request historis, buat respons kontrol terhadap path yang dipastikan tidak ada dan cocokkan ukuran badan yang diterima dengan written_bytes pada instalasi tersebut. Jika nilainya berbeda, kompresi, reverse proxy, atau transformasi lain pada jalur respons harus dipahami lebih dahulu; perbandingan berdasarkan ukuran belum dapat dianggap andal.

Klasifikasi setiap kandidat dengan membaca kedua bidang secara bersamaan:

Jika api_error tidak ada atau null dan written_bytes cocok dengan baseline berkas yang tidak ditemukan, path tidak menghasilkan berkas yang dapat dibaca dan tidak ada konten berkas yang terungkap.
Jika api_error tidak ada atau null dan written_bytes cocok dengan respons Unauthorized yang lebih pendek, server telah membaca berkas, tetapi decoding berhasil sehingga tidak ada fragmen berkas dalam respons.
Jika api_error memuat fragmen dan written_bytes sesuai dengan panjang badan kesalahan yang dikirim, konten tersebut telah keluar kepada klien. Inilah bukti pengungkapan data, bukan sekadar percobaan eksploitasi.

Fragmen dalam api_error menunjukkan bagian yang benar-benar diterima klien, bukan otomatis seluruh isi berkas. written_bytes juga bukan ukuran kebocoran karena menghitung seluruh badan respons, termasuk pembungkus dan escaping JSON. Perbedaan yang tidak dapat dijelaskan antara api_error dan written_bytes menandakan respons mungkin telah ditransformasi atau log tidak lengkap, sehingga request belum boleh diklasifikasikan.

Mengapa status HTTP dan ukuran berkas tidak cukup

Dalam mekanisme ini, konten mencapai klien ketika percent-decoding atas bagian isi berkas gagal. Tanda persen yang tidak diikuti dua digit heksadesimal dapat memicu kesalahan yang menyertakan potongan bermasalah, sedangkan berkas tanpa urutan seperti itu dapat dibaca penuh oleh server tanpa mengirimkan isinya.

Karena kesalahan parsing terjadi sebelum autentikasi, respons Bad Request yang membawa fragmen api_error menunjukkan pengungkapan, sedangkan respons Unauthorized dapat berarti berkas dibaca tetapi tidak diungkapkan. Bad Request pada baseline berkas yang tidak ditemukan juga bukan bukti kebocoran. Status lain tetap harus dinilai melalui pasangan api_error dan written_bytes.

Parameter file.size dan ukuran berkas di disk juga tidak menentukan jumlah data yang keluar. Batas fragmen bergantung pada bagian konten yang gagal diurai serta pemisah di sekitarnya; karena itu, kebocoran dapat berupa satu potongan, bukan awal berkas atau keseluruhan berkas.

Tindakan ketika fragmen terkonfirmasi terkirim

Perlakukan fragmen yang dipulihkan dari api_error sebagai artefak sensitif. Identifikasi kredensial atau rahasia yang benar-benar terlihat di dalam fragmen, prioritaskan rotasi nilai tersebut, lalu periksa log autentikasi layanan terkait sejak waktu request mencurigakan.

Alamat IP di log hanya merupakan petunjuk awal. Nilainya dapat berasal dari X-Forwarded-For dan bisa dipalsukan jika konfigurasi proxy mempercayai header tersebut tanpa pembatasan yang tepat; korelasikan dengan log edge, proxy, dan layanan tujuan sebelum mengaitkan aktivitas lanjutan dengan satu sumber.

Kesimpulan harus mengikuti batas bukti. Jika semua request terhadap suatu path memiliki pola tanpa pengungkapan, pernyataan yang dapat dipertahankan adalah “tidak ada bukti isi berkas dikirim kepada klien”, bukan “berkas tidak pernah dibaca”. Jika entri hilang, terpotong oleh log shipper, atau sudah terhapus akibat rotasi, metode ini tidak dapat memastikan apakah eksfiltrasi terjadi.

GitLab CVSS 10 dieksploitasi—cek log untuk memastikan data benar-benar keluar