Ing. Calogero Bono
Pada 12 Oktober 2026 GitLab merilis versi 19.4.2, 19.3.5, dan 19.2.8 untuk Community Edition dan Enterprise Edition. Di dalamnya ada perbaikan untuk CVE-2026-97229, celah dengan skor CVSS 10.0 yang bisa menyebabkan eksekusi kode sembarang di server. Kamis lalu CISA, badan keamanan Amerika Serikat, mengonfirmasi eksploitasi aktif dan memasukkan celah ini ke katalog KEV. Jika kamu mengelola instans GitLab sendiri, yang harus dilakukan adalah memperbarui sekarang juga.
Beberapa istilah dulu sebelum masuk ke faktanya. CVE adalah kode yang mengidentifikasi kerentanan publik. CVSS adalah skor tingkat keparahan dari 0 sampai 10. CI/CD mengacu pada pipeline otomatis yang mengompilasi, menguji, dan mempublikasikan kode. KEV adalah katalog CISA berisi celah yang sudah dieksploitasi dalam serangan nyata. RCE berarti eksekusi kode dari jarak jauh, yaitu menjalankan perintah di server milik orang lain.
Apa itu CVE-2026-97229?
Menurut halaman resmi GitLab, ini adalah masalah integer overflow pada kompiler ekspresi reguler yang dipakai dalam konfigurasi CI/CD. Dalam kondisi tertentu, pengguna yang tidak terautentikasi bisa mengeksekusi kode sembarang di server dengan ekspresi reguler yang dibuat khusus, karena validasinya tidak memadai.
Vektor CVSS-nya adalah jaringan, kompleksitas rendah, tanpa hak akses khusus, dan tanpa interaksi pengguna. Karena itulah skornya mencapai 10.0. Celah ini dilaporkan oleh joaxcar melalui program bug bounty di HackerOne.
Siapa yang mengeksploitasinya?
Seperti dilaporkan BleepingComputer, CISA menambahkan celah ini ke KEV dan meminta badan federal mengamankan server mereka paling lambat hari Minggu. Menurut The Hacker News, tenggat untuk badan sipil jatuh pada 1 November 2026.
Pemasukan ke KEV ini terkait dengan insiden yang diumumkan Alpine Linux. Pihak tak dikenal mencoba mengeksploitasi celah ini di instans mereka pada 20 dan 21 Oktober 2026 tanpa berhasil. Mereka mengirim konfigurasi CI yang dibuat khusus dan membuat proses worker crash delapan kali. Dalam empat kasus, eksploitasinya gagal pada langkah berikutnya. Penyerang juga mengunduh image container GitLab milik Alpine. Percobaan lanjutan pada 25 dan 26 Oktober berhasil diblokir.
Pengelola Alpine menyatakan «The attack came close to working». Mereka menambahkan bahwa tidak ditemukan bukti keberhasilan, tetapi keberhasilan itu tidak bisa dikesampingkan, sehingga mereka membangun ulang instans dari nol. Menurut mereka, repositori aports, paket, dan rilis tanggal 21 Oktober tidak diutak-atik.
Versi mana saja yang terdampak?
Untuk CVE-2026-97229, GitLab menyebutkan semua versi 19.2 sebelum 19.2.8, versi 19.3 sebelum 19.3.5, dan versi 19.4 sebelum 19.4.2. GitLab.com sudah memakai versi yang diperbaiki. Tenant GitLab Dedicated sudah diperbarui lewat rilis internal sebelum publikasi.
GitLab juga mencatat bahwa 19.3.4 punya bug pada halaman merge request ketika integrasi Ona aktif. Bug ini sudah diperbaiki di 19.3.5. Perusahaan juga merilis enam deteksi ancaman untuk membantu pengelola instans self-managed menemukan percobaan eksploitasi.
Celah lain dalam patch yang sama
Rilis ini tidak hanya memuat kasus paling serius. Di antara perbaikan lainnya, dengan skor yang dinyatakan GitLab –
- CVE-2026-92883, cross-site scripting pada penyorotan sintaks, CVSS 8.7.
- CVE-2026-16301, pengguna dengan peran Developer bisa memulai pipeline pada branch yang dilindungi, CVSS 8.5.
- CVE-2026-14814, cache poisoning pada file raw, dengan kemungkinan terbukanya variabel yang dilindungi, CVSS 8.2.
- CVE-2026-81839, pipeline dijalankan dengan hak akses grup baru setelah proyek dipindahkan (hanya EE), CVSS 7.7.
- CVE-2026-96893, injeksi pada instruksi agen AI GitLab Duo (hanya EE), CVSS 7.3.
Ada juga lima celah dengan tingkat keparahan menengah, termasuk pembacaan catatan rahasia lewat GraphQL dan terbukanya token di log GitLab Pages. Gambaran lengkapnya ada di halaman resmi.
Batasan yang perlu diketahui
Kita belum tahu berapa banyak instans yang sudah disusupi. Shadowserver, yang dikutip BleepingComputer, melacak hampir 2.800 instans Community Edition yang terpapar di Internet, tetapi tidak menyebutkan berapa yang sudah diperbarui. Angka itu tidak boleh dibaca sebagai jumlah sistem yang rentan.
Dari sumber yang ada, tidak diketahui siapa penyerangnya dan apakah ada kasus lain selain Alpine. Detail teknis eksploitasinya belum dipublikasikan. GitLab membuka laporan keamanannya 90 hari setelah patch dirilis, jadi detail lain mungkin akan muncul nanti.
Dampaknya untuk kamu yang bekerja di dunia digital
Jika kamu memakai GitLab self-managed untuk studio atau perusahaanmu, prioritasnya adalah versinya. Celah tanpa autentikasi di server yang menyimpan kode, rahasia, dan pipeline adalah risiko nyata, termasuk bagi klienmu. Kalau repositorimu di GitLab.com, kamu sudah terlindungi dari sisi platform.
Pelajaran dari Alpine itu praktis. Jika kamu tidak bisa memastikan instansmu aman dari kompromi, bangun ulang instansnya dan ganti semua rahasia. Mengotomatisasi instalasi juga membantu, seperti yang kami jelaskan dalam panduan tentang Ansible untuk konfigurasi dan deploy. Untuk server, disiplin dalam memperbarui sistem juga penting, topik yang pernah kami bahas dalam kasus Fragnesia dan PHP2Shell. Contoh terbaru lain tentang pemindaian setelah patch adalah Oracle E-Business Suite. Kalau kamu tidak punya waktu mengurus semuanya, tersedia hosting dan server terkelola dengan pembaruan keamanan.
Pendapat kami
Kasus ini menunjukkan betapa singkatnya jarak antara patch dan serangan. Perbaikannya dirilis 12 Oktober, percobaan terhadap Alpine dimulai 20 Oktober, jadi hanya delapan hari. Jika kamu menunda pembaruan sampai siklus bulanan berikutnya, kamu sudah terlambat.
Ada catatan kritis di sini. GitLab disebut hadir di lebih dari separuh Fortune 100, dan BleepingComputer mencatat rangkaian celah berskor maksimum dalam periode yang sama, termasuk dua lainnya dengan skor maksimum. Untuk layanan yang menyimpan kode dan rahasia sebuah perusahaan, frekuensi seperti ini cukup berat. Tidak cukup hanya mengatakan GitLab memperbaiki dengan cepat, meskipun memang begitu. Siapa pun yang memutuskan menyimpan semuanya sendiri harus siap dengan pengawasan berkelanjutan, atau menyerahkannya kepada pihak yang memang profesional di bidang ini.
Pertanyaan yang sering diajukan
Apakah saya harus langsung memperbarui GitLab?
Ya, jika instansmu self-managed dan berada pada versi yang disebutkan. GitLab menyarankan pembaruan segera ke 19.4.2, 19.3.5, atau 19.2.8. Eksploitasi aktif sudah dikonfirmasi oleh CISA.
Apakah GitLab.com berisiko?
Tidak, menurut GitLab. GitLab.com sudah memakai versi yang diperbaiki, dan tenant Dedicated sudah diperbarui sebelum rilis publik.
Apakah perlu akun untuk mengeksploitasi celah ini?
Tidak. Vektor CVSS menyatakan tidak diperlukan hak akses dan tidak ada interaksi pengguna. Serangan dilakukan melalui konfigurasi CI/CD yang dibuat khusus.
Bagaimana saya tahu apakah sudah diserang?
Tidak ada cara pasti menurut sumber yang ada. GitLab merilis enam deteksi untuk instans self-managed. Alpine melihat worker crash berulang kali setelah konfigurasi CI yang tidak biasa.
Cukupkah hanya memperbarui?
Tergantung. Jika instansmu terpapar dan belum di-patch beberapa hari terakhir, kamu tidak bisa mengesampingkan kompromi. Alpine memilih membangunnya ulang dari nol.
Yang perlu dipantau dalam beberapa minggu ke depan, di antara patch dan pemeriksaan
Dalam beberapa hari ke depan, yang penting adalah melihat apakah ada kasus lain selain Alpine dan apakah detail teknisnya akan dipublikasikan. Tiga saran –
- Perbarui ke versi terbaru untuk cabang yang kamu pakai, lalu periksa nomor versinya setelah instalasi.
- Periksa log worker untuk crash berulang dan konfigurasi CI yang tidak biasa, dengan memanfaatkan deteksi dari GitLab.
- Jika instansmu terpapar dan belum diperbarui, ganti token dan variabel yang dilindungi, lalu pertimbangkan untuk membangun ulang.
