Jika perusahaan Anda menjalankan GitLab di server sendiri, perbarui hari ini. Pada 12 Oktober 2026, GitLab merilis patch keamanan kritis yang memperbaiki 24 kerentanan. Yang terparah, CVE-2026-97229, mendapat skor tingkat keparahan tertinggi yang mungkin: 10 dari 10. Celah ini memungkinkan seseorang yang tidak punya akun di server Anda menjalankan kodenya sendiri di sana. Setiap server yang menjalankan versi 19.2 sebelum 19.2.8, versi 19.3 sebelum 19.3.5, atau versi 19.4 sebelum 19.4.2 terdampak. Satu-satunya perbaikan yang disebut GitLab adalah upgrade ke 19.4.2, 19.3.5 atau 19.2.8. Jika Anda menggunakan layanan cloud di GitLab.com, Anda tidak perlu melakukan apa pun.

Apa itu GitLab, dan mengapa pemilik bisnis perlu peduli?

GitLab adalah tempat tim teknis Anda menyimpan kode sumber sistem dan aplikasi Anda, serta tempat versi baru dibangun dan dikirim ke server Anda. Banyak perusahaan menjalankannya di server internal alih-alih layanan cloud, agar kode dan data tetap berada di dalam organisasi. Server itu biasanya menyimpan lebih banyak dari yang diperkirakan pemiliknya: seluruh kode sumber, kata sandi database, kunci yang menghubungkan Anda ke payment gateway dan layanan pemerintah, serta hak untuk melakukan deploy ke server yang digunakan pelanggan Anda. Siapa pun yang menguasainya dapat membaca semua itu, dan dapat mengubah kode Anda sebelum sampai ke pelanggan.

Apa tepatnya yang diumumkan GitLab?

Menurut pengumuman resmi rilis patch GitLab, celah ini berada di bagian yang memproses regular expression di dalam pengaturan pipeline build dan deployment (CI/CD). Regular expression adalah potongan teks pendek yang menggambarkan pola pencarian. Pengumuman tersebut menyatakan bahwa celah ini dapat memungkinkan pengguna yang tidak terautentikasi mengeksekusi kode sembarang di server GitLab melalui regular expression yang dibuat secara khusus, karena validasi ekspresi tersebut tidak memadai. Seorang peneliti melaporkannya melalui program bug bounty GitLab di HackerOne.

Pengumuman itu tidak menyebutkan bahwa celah ini sudah dieksploitasi. Namun skor 10 berarti celah ini dapat dieksploitasi melalui internet, tanpa kata sandi dan tanpa bantuan karyawan mana pun. Penyerang biasanya mulai memburu celah seperti ini dalam beberapa hari setelah perbaikan dipublikasikan, karena perbaikan itu sendiri menunjukkan letak kelemahannya.

Apa lagi isi patch ini?

Patch yang sama memperbaiki 23 kerentanan lain, lima di antaranya berkategori tinggi:

  • Injeksi skrip berbahaya (XSS) pada penyorotan sintaks, skor 8.7.
  • Celah otorisasi saat membuat pipeline, skor 8.5.
  • Regular expression yang terlalu longgar yang memengaruhi akses file, skor 8.2.
  • Celah otorisasi pada kebijakan eksekusi pipeline di edisi berbayar, skor 7.7.
  • Celah prompt injection pada agen AI GitLab Duo di edisi berbayar, skor 7.3.

Jadi versi yang lebih lama dari 19.2, yang tidak terdampak celah kritis, belum tentu aman. Kebijakan pemeliharaan resmi GitLab menyatakan bahwa perbaikan keamanan hanya di-backport ke rilis saat ini dan dua rilis bulanan sebelumnya. Server dengan versi yang lebih lama sama sekali tidak lagi menerima perbaikan keamanan, dan bagaimanapun perlu di-upgrade.

Siapa yang perlu bertindak?

  • Pengguna cloud GitLab.com: tidak ada yang perlu dilakukan; GitLab menyatakan layanannya sudah berjalan dengan versi yang telah di-patch.
  • Pelanggan GitLab Dedicated: menurut pengumuman, juga tidak ada yang perlu dilakukan.
  • Siapa pun yang menjalankan GitLab di server sendiri: segera upgrade. Itulah rekomendasi tegas GitLab untuk setiap instalasi self-managed.
  • Siapa pun yang tidak yakin di mana GitLab-nya berjalan: tanyakan hari ini kepada tim Anda atau vendor yang membangun sistem Anda. Banyak server internal dipasang oleh vendor lama lalu terlupakan.

Langkah praktis untuk minggu ini

  1. Cari tahu versinya: minta kepala tim teknis Anda membuka halaman Help di GitLab, membaca nomor versi yang ditampilkan di sana, lalu membandingkannya dengan nomor-nomor di atas.
  2. Jadwalkan upgrade hari ini, bukan di akhir bulan: menurut pengumuman GitLab, server satu node akan mati selama patch sampai migrasi database selesai, sedangkan konfigurasi multi-node dapat di-patch tanpa downtime jika prosedur zero-downtime yang benar diikuti. Downtime satu jam di luar jam kerja jauh lebih murah daripada server yang dibobol.
  3. Jika Anda menggunakan 19.3: langsung ke 19.3.5, bukan 19.3.4. Pengumuman mencatat bahwa 19.3.4 memiliki bug yang memengaruhi halaman merge request saat integrasi Ona diaktifkan, yang diperbaiki di 19.3.5.
  4. Kurangi paparan ke internet: jika tidak ada pihak di luar perusahaan yang perlu mengakses server GitLab Anda, atur agar server hanya menerima koneksi dari jaringan perusahaan atau melalui VPN. Ini tidak menggantikan patch, tetapi mempersempit pintunya di lain waktu.
  5. Periksa setelah patch: tinjau pengguna, kunci, dan token akses yang baru dibuat. Jika muncul sesuatu yang tidak dikenali siapa pun, ganti kata sandi dan kunci yang disimpan di server.

Langkah upgrade untuk setiap metode instalasi tersedia di panduan upgrade resmi GitLab.

Pandangan Origami

Kami menggunakan GitLab setiap hari karena repositori kami ada di sana, jadi kami mengikuti pengumuman keamanannya sedekat kami memantau tagihan kami. Pelajarannya lebih luas dari GitLab: setiap sistem yang Anda jalankan sendiri agar data tetap di internal membawa kewajiban untuk menambalnya pada hari perbaikan dirilis. Masalah yang paling sering kami lihat bukanlah keputusan itu sendiri, melainkan tidak adanya nama penanggung jawab pembaruan. Server yang dipasang vendor tiga tahun lalu, yang tidak diketahui siapa pemeliharanya, adalah hal pertama yang dicari penyerang. Kami mengatakan hal yang sama tentang celah toko Magento: patch saja tidak cukup jika datang terlambat. Jika Anda membutuhkan pihak yang meninjau server Anda atau mengambil alih pembaruannya, hubungi kami.

Sumber