Tag: Kerentanan RCE

Pengembang bahasa pemrograman Ruby telah meluncurkan pembaruan versi 4.0.9, 3.4.12, dan 3.3.13 guna membenahi tiga masalah teknis pada Onigmo, mesin ekspresi reguler bawaan di dalamnya. Ketiga kerusakan tersebut menjadi akar dari empat celah keamanan berisiko tinggi yang ditambal oleh platform GitLab selama sebulan belakangan.

Pihak GitLab menemukan bahwa pola ekspresi reguler yang dirancang khusus dapat merusak alokasi memori ketika Ruby mengompilasinya. Kelemahan ini berisiko membuka jalan bagi pihak luar untuk mengeksekusi kode perintah arbitrary secara ilegal langsung pada server pengelola.

Tim Ruby menegaskan bahwa bahaya ini mengancam setiap aplikasi yang menyusun pola ekspresi reguler menggunakan string masukan yang dikendalikan oleh penyerang, bukan terbatas pada sistem GitLab semata.

Aplikasi Mana Saja yang Terkena Dampak

Dalam rilis imbauan keamanannya, tim Ruby memaparkan bahwa program baru dianggap rentan apabila memproses kompilasi regex memakai data teks yang dapat dimanipulasi peretas. Kondisi tersebut tercipta saat aplikasi memasukkan teks tersebut ke dalam Regexp.new, Regexp.union, maupun Regexp.compile, atau menyisipkannya melalui interpolasi sintaks seperti /#{input}/.

Adapun perangkat lunak yang hanya menggunakan pola ekspresi reguler statis ciptaan pengembangnya sendiri sepenuhnya berada di posisi aman dari ancaman ini.

Ruby resmi membenahi kesalahan sistem ini pada varian 4.0.9, 3.4.12, dan 3.3.13. Rilis edisi 3.4.12 dan 3.3.13 tercatat sebagai versi perdana di lini masing-masing yang menyertakan perbaikan untuk ketiga galat tersebut.

Versi terdahulu yang dirilis pada pekan yang sama, yakni 4.0.8, rupanya belum mencakup solusi bagi salah satu cacat berkode CVE-2026-110264. Oleh sebab itu, seluruh pemakai seri 4.0 sangat disarankan langsung beralih memasang edisi 4.0.9.

Sementara itu, seri Ruby 3.2 beserta edisi sebelumnya tidak akan memperoleh tambalan pengaman apa pun. Masa dukungan untuk Ruby 3.2 telah resmi berakhir pada 1 April 2026, ditandai dengan rilis 3.2.11 sebagai varian penutup. Pihak pengembang menyarankan pengguna untuk segera bermigrasi menuju versi 3.4 atau 4.0.

Bagi pengelola sistem yang belum dapat menerapkan peningkatan versi dalam waktu dekat, imbauan resmi meminta penghentian seluruh aktivitas kompilasi regex yang bersumber dari masukan tak tepercaya.

Dua metode mitigasi umum yang kerap dianggap efektif ternyata tidak mampu membendung masalah ini. Penyetelan batas durasi melalui parameter Regexp.timeout terbukti gagal menangkis gangguan. Selain itu, pembatasan panjang karakter regex juga tidak menjamin keamanan, mengingat rangkaian pola yang berukuran sangat pendek pun terbukti mampu memicu terjadinya eror.

Kronologi Masuknya Galat ke Platform GitLab

Platform GitLab memproses kompilasi pola regex kiriman pengguna secara rutin, contohnya pada sintaks pengaturan sistem otomasi CI/CD. Pengelola menemukan manipulasi pola ini sanggup merusak struktur memori selama fase kompilasi Ruby berlangsung, memicu terbitnya empat catatan CVE antara tanggal 23 September hingga 21 Oktober yang masing-masing diperbaiki melalui paket distribusi Ruby tertambal.

Dua celah perdana diumumkan pada 23 September, mengharuskan akun pengguna melakukan login terlebih dahulu, dan memperoleh skor keparahan 9,9 dari skala 10. Dua masalah berikutnya menyusul pada Oktober, yaitu CVE-2026-97229 pada tanggal 12 dan CVE-2026-110264 pada tanggal 21, yang keduanya dapat dieksploitasi tanpa kepemilikan akun dengan raihan skor maksimal 10,0. Cacat CVE-2026-110264 berdampak langsung pada seluruh edisi GitLab mulai versi 7.0 ke atas.

Seorang peneliti keamanan siber dengan identitas akun joaxcar melaporkan keempat kelemahan sistem tersebut via program pemburu bug GitLab. Sampai dengan 23 Oktober, belum ada satu pun dari keempatnya yang dimasukkan ke daftar Known Exploited Vulnerabilities kepunyaan instansi CISA.

Status Penomoran CVE dari Pihak Ruby

Hingga saat ini, pihak Ruby belum mengajukan nomor identitas CVE khusus atas pembaruan ini, “setidaknya untuk saat ini,” terang mereka sembari mengarahkan para administrator untuk memantau status perkembangan melalui empat kode CVE milik GitLab.

Langkah penundaan ini memunculkan celah teknis bagi pengelola yang memakai alat pemindai keamanan berbasis katalog CVE. Dokumen resmi catatan kerentanan GitLab hanya mengidentifikasi GitLab sebagai perangkat lunak terdampak, sehingga pemindai otomatis yang memeriksa kesesuaian instalasi Ruby tidak menemukan keterkaitan data yang cocok.

Padahal di masa lalu, Ruby sempat memperlakukan jenis gangguan serupa ini sebagai isu kerentanan formal, terbukti dengan pemberian kode identitas CVE pada perbaikan di tahun 2022 serta 2024, kendati praktik memproses pola masukan luar sudah lama dianggap berisiko.

Buku panduan dokumentasi resminya saat ini masih mengelompokkan risiko masukan teks tidak tepercaya semata-mata sebagai bahaya penolakan layanan (denial of service). Tim Ruby memastikan akan memperbarui buletin mereka bila pengajuan kode identitas CVE dilakukan di kemudian hari.

Instruksi Khusus Pengelola Layanan GitLab

Seluruh instalasi peladen GitLab mandiri (self-managed) diwajibkan memperbarui paket ke edisi yang memperbaiki celah CVE-2026-110264. GitLab telah meluncurkan tambalan tersebut pada 21 Oktober dan menerapkannya mundur hingga versi pendukung 18.11.13.

Layanan berbasis cloud GitLab.com dipastikan telah memakai versi aman terkini, sedangkan penyewa GitLab Dedicated pada rilis internal baru tidak memerlukan penyesuaian tambahan apa pun, jelas perwakilan GitLab. Berhubung platform mengemas bundel Ruby miliknya sendiri dan menambalnya langsung di sana, pemasangan versi GitLab terbaru ini otomatis menuntaskan kerentanan.

Selain pembaruan kode, pengembang GitLab juga membagikan aturan deteksi keamanan resmi yang dapat diimplementasikan administrator mandiri guna mengenali potensi indikasi percobaan eksploitasi di lingkungan masing-masing.

Eksploitasi Node2Shell pada Node.js: Peneliti Ungkap Celah Eksekusi Kode via Data Brotli

By admin

On October 23, 2026

In The Hacker News

Data Brotli berbahaya terbukti mampu memicu sebuah aplikasi pada build resmi Node.js menjalankan kode arbitrer yang dikirimkan oleh penyerang, sebagaimana telah didemonstrasikan oleh para peneliti keamanan siber di Imperva.

Bukti konsep bertajuk "Node2Shell" yang mereka kembangkan sukses mengeksekusi kode pada image resmi Node.js 24.22.0 untuk arsitektur Linux arm64 tanpa debugger maupun build kustom, yakni murni dengan memasok data manipulasi ke dekoder Brotli bawaan (CVE-2026-111497). Pihak Node.js telah mengungkap kerentanan ini serta merilis sejumlah perbaikan pada tanggal 21 Oktober, sehingga seluruh aplikasi yang memproses dekode data Brotli tidak tepercaya diimbau segera memperbarui sistem mereka.

Pengujian yang dilakukan Imperva tidak langsung berhasil pada setiap percobaan, di mana eksekusi kode memerlukan beberapa kali upaya dalam lingkungan Linux arm64 tersebut. Temuan hasil ini mencakup satu build dan konfigurasi aplikasi spesifik tersebut, sementara arsitektur lain serta lini versi 22.x dan 26.x belum diuji secara menyeluruh. Pada versi rilis perbaikan, yakni 24.22.1, paket data manipulasi yang sama langsung ditolak mentah-mentah dan tidak ada kode yang berhasil berjalan.

Demonstrasi mutakhir ini melangkah jauh melampaui bukti konsep publik perdana, yang kala itu hanya berhasil meraih eksekusi kode pada build uji coba yang sengaja dilemahkan secara khusus. Pada build standar umum, penulis bukti konsep awal tersebut hanya melaporkan terjadinya crash serta pembacaan memori proses yang terbatas alih-alih eksekusi kode, dan menyatakan bahwa serangan yang berfungsi penuh pada build normal belum berhasil dicapai saat itu.

Hingga tanggal 22 Oktober, tidak ada laporan mengenai eksploitasi aktif atas celah keamanan tersebut di alam liar.

Aplikasi Mana Saja yang Terdampak

Celah keamanan ini berakar langsung pada dekoder Brotli yang dibundel di dalam Node.js, sehingga dampaknya menyasar seluruh aplikasi pada lini versi 22.x, 24.x, dan 26.x, bukan hanya satu build yang diuji Imperva. Sebuah layanan komputasi dapat menjangkau modul dekoder tersebut melalui kedua sisi pertukaran HTTP: ketika membaca respons terkompresi Brotli menggunakan fungsi bawaan fetch(), atau saat komponen middleware mendekompresi isi request body yang terkompresi Brotli.

Modul pengurai body pada Express 5, mencakup express.json(), express.urlencoded(), express.text(), dan express.raw(), kini secara otomatis mendekode payload request body Brotli ketika dipasang pada suatu rute, berdampingan dengan kompresi gzip dan deflate. Server HTTP Node.js standar murni pada dasarnya tidak mendekode request body Brotli hanya karena menerimanya, sehingga proses dekode tersebut memang mutlak memerlukan middleware tadi atau pemanggilan kode secara eksplisit.

Imperva mereproduksi keberhasilan eksekusi kode melalui jalur request-body maupun response path, menguji rilis Express 5.0.0 hingga 5.3.0 serta body-parser 2.0.0 hingga 2.3.0 pada versi terpilih yang dipatok, dan tidak mengecek seluruh rilis minor di antaranya.

Cara Kerja Celah Keamanan Tersebut

Peneliti Imperva melacak akar masalah pada metode penanganan dekoder ketika menghadapi kondisi mustahil dalam aliran data Brotli: aliran tersebut mengumumkan tipe blok yang akan dipakai seiring berjalannya dekode, dan input uji coba memicu perubahan blok yang strukturnya sendiri sudah dieliminasi. Dekoder yang rentan keliru menafsirkan status ini sebagai permintaan input tambahan dan terus memproses data dalam keadaan tidak valid.

Dalam pengujian terpisah memakai memory sanitizer, tindakan melanjutkan proses dari status cacat tersebut memicu penulisan melewati batas buffer yang telah ditentukan, yang menjadi akar out-of-bounds write di balik celah ini.

Node.js menambal kelemahan ini dengan mengimpor patch Brotli hulu yang memaksa dekoder langsung berhenti memunculkan format error pada titik tersebut alih-alih melanjutkan pemrosesan.

Langkah perbaikan utama adalah beralih ke rilis yang sudah ditambal. Pembaruan wajib diterapkan hingga mencakup container images dan artifak lain yang memuat binary Node, yang kerap terlewat dalam inventarisasi paket. Lini end-of-life versi 20.x ke bawah tidak memperoleh patch dan harus dimigrasikan ke lini yang masih didukung penuh.

Pemberitahuan resmi tidak mencantumkan solusi alternatif internal di Node.js, sehingga aplikasi yang belum bisa segera memperbarui tidak memiliki penangkal di tingkat runtime. Imperva menyarankan pembatasan lalu lintas Brotli tidak tepercaya pada rute terdampak jika memungkinkan, serta menegaskan hanya pembaruan yang menuntaskan celah. Perusahaan juga menambahkan aturan penangkal pada web application firewall milik mereka dan mengujinya terhadap serangan hasil reproduksi.

Penyedia hosting Vercel, yang menjalankan Node.js bagi para pelanggannya, menyatakan telah menambahkan aturan pemblokiran serangan pada permintaan masuk per 21 Oktober. Aturan proteksi ini tidak mencakup respons Brotli yang diambil aplikasi dari server eksternal lain, dan tidak menggantikan kewajiban pembaruan versi.