.png)
Peneliti keamanan siber mengungkap detail kerentanan yang kini telah diperbaiki pada sistem Open VSX, sebuah registry ekstensi yang banyak digunakan oleh ekosistem Visual Studio Code. Celah ini memungkinkan ekstensi berbahaya melewati proses verifikasi keamanan sebelum publikasi, lalu langsung tersedia untuk diunduh oleh pengguna. Temuan ini menyoroti kelemahan mendasar dalam desain pipeline scanning yang seharusnya menjadi garis pertahanan pertama terhadap distribusi kode berbahaya.
Kerentanan tersebut diidentifikasi oleh peneliti dari Koi Security, Oran Simhony, dan diberi nama “Open Sesame”. Inti masalahnya terletak pada cara pipeline pre-publish scanning menangani hasil pemindaian. Sistem hanya mengandalkan satu nilai boolean untuk merepresentasikan dua kondisi yang berbeda secara fundamental, yaitu tidak adanya scanner yang dikonfigurasi dan kegagalan seluruh scanner dalam menjalankan tugasnya. Dalam praktiknya, kedua kondisi ini tidak dapat dibedakan oleh sistem pemanggil, sehingga menciptakan ambiguitas fatal dalam pengambilan keputusan.
Ketika beban sistem meningkat dan scanner gagal dijalankan, Open VSX justru menganggap kondisi tersebut sebagai tidak adanya objek yang perlu dipindai. Akibatnya, ekstensi yang seharusnya ditolak atau setidaknya ditinjau ulang malah dianggap aman dan langsung dipublikasikan. Situasi ini menciptakan celah yang dapat dimanfaatkan oleh aktor berbahaya untuk menyusupkan ekstensi berisi kode berbahaya ke dalam registry resmi.
Masalah ini menjadi lebih signifikan mengingat peran Open VSX sebagai marketplace ekstensi tidak hanya untuk Visual Studio Code, tetapi juga berbagai fork populer seperti Cursor dan Windsurf. Dengan meningkatnya ketergantungan pada ekstensi untuk memperluas fungsionalitas editor, keamanan pipeline publikasi menjadi aspek krusial. Untuk menjawab ancaman ini, Eclipse Foundation sebelumnya telah mengumumkan penerapan mekanisme pre-publish security checks sebagai upaya preventif terhadap maraknya ekstensi berbahaya.
Dalam desain yang diharapkan, ekstensi yang gagal melewati proses scanning akan dikarantina untuk ditinjau oleh administrator sebelum dipublikasikan. Namun, kerentanan Open Sesame membalik logika tersebut. Ketika scanner gagal dijalankan—misalnya akibat kehabisan resource—sistem justru memberikan status “lulus” pada ekstensi tersebut. Hal ini tidak hanya melewati mekanisme karantina, tetapi juga langsung mengaktifkan ekstensi di registry, membuatnya dapat diakses oleh publik.
Akar teknis dari masalah ini berkaitan dengan layanan berbasis Java yang mengelola hasil pemindaian. Kesalahan interpretasi terjadi saat kegagalan dalam proses enqueue job scanning diperlakukan sebagai kondisi normal. Salah satu penyebab kegagalan ini adalah kehabisan koneksi pada database connection pool, sebuah kondisi yang umum terjadi pada sistem dengan beban tinggi. Dalam skenario ini, job scanning tidak dapat dijadwalkan, namun sistem tetap melanjutkan proses publikasi tanpa validasi keamanan.
Lebih mengkhawatirkan lagi, layanan pemulihan yang dirancang untuk mengulang pemindaian yang gagal juga memiliki kelemahan yang sama. Alih-alih memperbaiki kegagalan, mekanisme ini justru memperkuat celah yang ada, memungkinkan ekstensi melewati seluruh proses scanning dalam kondisi tertentu. Ini menunjukkan bahwa masalah bukan hanya pada satu komponen, tetapi pada pola desain yang digunakan secara luas dalam pipeline tersebut.
Dari perspektif eksploitasi, serangan terhadap kerentanan ini tidak memerlukan hak akses khusus. Seorang aktor dengan akun publisher gratis dapat memanfaatkan celah ini dengan cara membanjiri endpoint publikasi menggunakan sejumlah besar file .VSIX berbahaya. Lonjakan beban ini akan menyebabkan resource sistem, khususnya koneksi database, menjadi jenuh. Ketika kondisi ini tercapai, job scanning gagal dijalankan, dan ekstensi akan lolos tanpa pemeriksaan.
Karakteristik serangan ini membuatnya relatif mudah direproduksi dan berpotensi berdampak luas. Tidak adanya kebutuhan akan privilege tinggi berarti hambatan masuk bagi penyerang sangat rendah. Dalam ekosistem open-source yang mengedepankan keterbukaan dan kontribusi publik, kondisi ini menjadi risiko yang tidak bisa diabaikan.
Kerentanan ini telah diperbaiki dalam Open VSX versi 0.32.0 setelah dilaporkan secara bertanggung jawab pada 8 Februari 2026. Perbaikan ini menandai langkah penting dalam memperkuat pipeline keamanan, namun juga menjadi pengingat bahwa lapisan perlindungan tunggal tidak pernah cukup. Pre-publish scanning memang penting, tetapi tetap harus didukung oleh mekanisme validasi lain seperti runtime monitoring, reputasi publisher, dan analisis perilaku ekstensi.
Kasus ini juga menyoroti pola kesalahan desain yang cukup umum dalam pengembangan sistem, yaitu fail-open error handling. Dalam pola ini, kegagalan sistem tidak menyebabkan proses dihentikan, melainkan tetap dilanjutkan seolah-olah tidak terjadi kesalahan. Dalam konteks keamanan, pendekatan ini sangat berisiko karena membuka peluang bagi data atau proses yang tidak tervalidasi untuk lolos ke tahap berikutnya.
Penggunaan satu nilai boolean untuk merepresentasikan beberapa kondisi berbeda menjadi contoh konkret bagaimana simplifikasi berlebihan dapat berdampak besar. Ketika sistem tidak mampu membedakan antara “tidak ada pekerjaan” dan “pekerjaan gagal”, maka seluruh logika kontrol menjadi tidak dapat diandalkan. Dalam pipeline keamanan, ketidakjelasan ini setara dengan membuka pintu tanpa verifikasi.
Implikasi dari temuan ini melampaui Open VSX. Banyak sistem lain, terutama yang mengandalkan pipeline otomatis untuk validasi dan distribusi software, berpotensi memiliki kelemahan serupa. Oleh karena itu, pendekatan desain yang eksplisit terhadap state error menjadi keharusan. Setiap kondisi kegagalan harus diperlakukan sebagai entitas yang berbeda, dengan mekanisme penanganan yang jelas dan terisolasi.
Bagi developer dan engineer yang membangun sistem serupa, pelajaran utama dari kasus ini adalah pentingnya membedakan antara kondisi “tidak perlu diproses” dan “gagal diproses”. Keduanya mungkin terlihat serupa dalam konteks tertentu, tetapi memiliki implikasi yang sangat berbeda dalam eksekusi sistem. Menggabungkan keduanya dalam satu jalur logika bukan hanya praktik buruk, tetapi juga membuka potensi kerentanan serius.
Pada akhirnya, insiden ini menunjukkan bahwa keamanan bukan hanya soal menambahkan fitur, tetapi juga tentang bagaimana fitur tersebut dirancang dan diimplementasikan. Sebuah pipeline yang secara konsep sudah benar tetap dapat menjadi titik lemah jika detail implementasinya diabaikan. Dalam lingkungan distribusi software yang semakin kompleks, presisi dalam desain sistem menjadi faktor penentu antara keamanan dan kompromi.