Jika syarikat anda menjalankan GitLab pada pelayannya sendiri, kemas kini hari ini. Pada 12 Oktober 2026, GitLab mengeluarkan tampalan keselamatan kritikal yang membaiki 24 kelemahan. Yang paling teruk, CVE-2026-97229, menerima skor keterukan tertinggi yang mungkin: 10 daripada 10. Ia membolehkan seseorang yang tiada akaun pada pelayan anda menjalankan kodnya sendiri di situ. Setiap pelayan yang menjalankan versi 19.2 sebelum 19.2.8, versi 19.3 sebelum 19.3.5, atau versi 19.4 sebelum 19.4.2 terjejas. Satu-satunya pembaikan yang dinyatakan oleh GitLab ialah naik taraf ke 19.4.2, 19.3.5 atau 19.2.8. Jika anda menggunakan perkhidmatan awan di GitLab.com, anda tidak perlu berbuat apa-apa.

Apakah GitLab, dan mengapa pemilik perniagaan perlu mengambil berat?

GitLab ialah tempat pasukan teknikal anda menyimpan kod sumber sistem dan aplikasi anda, dan tempat versi baharu dibina serta dihantar ke pelayan anda. Banyak syarikat menjalankannya pada pelayan dalaman dan bukannya perkhidmatan awan, supaya kod dan data kekal di dalam organisasi. Pelayan itu biasanya menyimpan lebih banyak daripada jangkaan pemiliknya: keseluruhan kod sumber, kata laluan pangkalan data, kunci yang menghubungkan anda ke gerbang pembayaran dan perkhidmatan kerajaan, serta hak untuk membuat pengerahan ke pelayan yang digunakan oleh pelanggan anda. Sesiapa yang menguasainya boleh membaca semua itu, dan boleh mengubah kod anda sebelum ia sampai kepada pelanggan.

Apakah sebenarnya yang diumumkan oleh GitLab?

Menurut pengumuman rasmi keluaran tampalan GitLab, kelemahan ini terletak pada bahagian yang memproses ungkapan nalar (regular expression) di dalam tetapan saluran paip binaan dan pengerahan (CI/CD). Ungkapan nalar ialah sebahagian kecil teks yang menerangkan corak carian. Pengumuman itu menyatakan bahawa kelemahan ini boleh membolehkan pengguna yang tidak disahkan melaksanakan kod sewenang-wenangnya pada pelayan GitLab melalui ungkapan nalar yang direka khas, disebabkan pengesahan ungkapan tersebut yang tidak mencukupi. Seorang penyelidik melaporkannya melalui program ganjaran pepijat GitLab di HackerOne.

Pengumuman itu tidak menyatakan bahawa kelemahan ini telah dieksploitasi. Tetapi skor 10 bermakna ia boleh dieksploitasi melalui internet, tanpa kata laluan dan tanpa bantuan mana-mana pekerja. Penyerang biasanya mula memburu kelemahan seperti ini dalam beberapa hari selepas pembaikan didedahkan kepada umum, kerana pembaikan itu sendiri menunjukkan di mana kelemahannya.

Apa lagi yang terkandung dalam tampalan ini?

Tampalan yang sama membaiki 23 kelemahan lain, lima daripadanya bertaraf tinggi:

  • Suntikan skrip berniat jahat (XSS) dalam penonjolan sintaks, skor 8.7.
  • Kelemahan kebenaran semasa mencipta saluran paip, skor 8.5.
  • Ungkapan nalar yang terlalu longgar yang menjejaskan akses fail, skor 8.2.
  • Kelemahan kebenaran dalam dasar pelaksanaan saluran paip dalam edisi berbayar, skor 7.7.
  • Kelemahan suntikan gesaan (prompt injection) dalam ejen AI GitLab Duo dalam edisi berbayar, skor 7.3.

Jadi versi yang lebih lama daripada 19.2, yang tidak terjejas oleh kelemahan kritikal itu, tidak semestinya selamat. Dasar penyelenggaraan rasmi GitLab menyatakan bahawa pembaikan keselamatan hanya dibawa balik ke keluaran semasa dan dua keluaran bulanan sebelumnya. Pelayan pada mana-mana versi yang lebih lama tidak lagi menerima pembaikan keselamatan langsung, dan perlu dinaik taraf walau apa pun.

Siapa yang perlu bertindak?

  • Pengguna awan GitLab.com: tiada apa-apa yang perlu dilakukan; GitLab menyatakan perkhidmatan itu sudah menjalankan versi yang telah ditampal.
  • Pelanggan GitLab Dedicated: menurut pengumuman, mereka juga tidak perlu berbuat apa-apa.
  • Sesiapa yang menjalankan GitLab pada pelayan sendiri: naik taraf dengan segera. Itulah cadangan jelas GitLab bagi setiap pemasangan yang diurus sendiri.
  • Sesiapa yang tidak pasti di mana GitLab mereka berjalan: tanya pasukan anda atau vendor yang membina sistem anda hari ini. Banyak pelayan dalaman dipasang oleh vendor terdahulu dan kemudian dilupakan.

Langkah praktikal untuk minggu ini

  1. Kenal pasti versi: minta ketua teknikal anda membuka halaman Help dalam GitLab, membaca nombor versi yang dipaparkan di situ, dan membandingkannya dengan nombor di atas.
  2. Jadualkan naik taraf hari ini, bukan pada hujung bulan: menurut pengumuman GitLab, pelayan satu nod akan terhenti semasa tampalan sehingga migrasi pangkalan data selesai, manakala persediaan berbilang nod boleh ditampal tanpa masa henti jika prosedur tanpa masa henti yang betul diikuti. Masa henti selama satu jam di luar waktu bekerja jauh lebih murah daripada pelayan yang dicerobohi.
  3. Jika anda menggunakan 19.3: terus ke 19.3.5, bukan 19.3.4. Pengumuman itu mencatatkan bahawa 19.3.4 mempunyai pepijat yang menjejaskan halaman permintaan gabungan (merge request) apabila integrasi Ona didayakan, yang dibaiki dalam 19.3.5.
  4. Kurangkan pendedahan kepada internet: jika tiada sesiapa di luar syarikat perlu mencapai pelayan GitLab anda, tetapkan supaya ia hanya menerima sambungan daripada rangkaian syarikat atau melalui VPN. Ini tidak menggantikan tampalan, tetapi ia menyempitkan pintu pada masa akan datang.
  5. Semak selepas menampal: semak pengguna, kunci dan token akses yang baru dicipta. Jika ada sesuatu yang tidak dikenali oleh sesiapa, tukar kata laluan dan kunci yang disimpan pada pelayan.

Langkah naik taraf bagi setiap kaedah pemasangan terdapat dalam panduan naik taraf rasmi GitLab.

Pandangan Origami

Kami menggunakan GitLab setiap hari kerana repositori kami berada di sana, jadi kami mengikuti pengumuman keselamatannya serapat kami memantau invois kami. Pengajarannya lebih luas daripada GitLab: setiap sistem yang anda jalankan sendiri untuk menyimpan data secara dalaman datang bersama tanggungjawab untuk menampalnya pada hari pembaikan dikeluarkan. Masalah yang paling kerap kami lihat bukanlah keputusan itu sendiri, tetapi ketiadaan nama orang yang bertanggungjawab atas kemas kini. Pelayan yang dipasang oleh vendor tiga tahun lalu, yang tiada sesiapa tahu siapa yang menyelenggaranya, ialah perkara pertama yang dicari oleh penyerang. Kami menyatakan perkara yang sama tentang kelemahan kedai Magento: menampal sahaja tidak mencukupi jika ia datang lewat. Jika anda memerlukan seseorang untuk menyemak pelayan anda atau mengambil alih kemas kininya, hubungi kami.

Sumber