Kerentanan Command Injection di Composer PHP Terungkap: Dua CVE Baru Ancam Eksekusi Perintah Arbitrer

Dua kerentanan keamanan dengan tingkat keparahan tinggi telah diungkap dalam Composer, pengelola dependensi utama untuk ekosistem PHP yang digunakan secara luas oleh developer di seluruh dunia. Celah ini berkaitan dengan mekanisme integrasi sistem version control Perforce (VCS driver) yang digunakan oleh Composer untuk mengambil dan mengelola source code dari repository eksternal. Kedua kerentanan tersebut telah didaftarkan sebagai CVE-2026-40261 dan CVE-2026-40176, masing-masing dilaporkan oleh peneliti keamanan Koda Reef dan saku0512. Hingga saat pengungkapan, tidak ditemukan bukti eksploitasi aktif terhadap kedua celah ini.

Bagaimana Kerentanan Ini Bisa Ada?

Kerentanan ini berakar pada kesalahan dalam proses sanitasi input yang digunakan dalam konstruksi perintah shell. Secara spesifik, Composer tidak melakukan escaping yang memadai terhadap parameter tertentu yang berasal dari input pengguna, sehingga membuka peluang bagi penyerang untuk menyisipkan perintah berbahaya. Dalam konteks sistem operasi, kondisi ini dikenal sebagai command injection, yaitu teknik eksploitasi di mana input yang tidak tervalidasi dimanfaatkan untuk mengeksekusi perintah arbitrer pada sistem target.

CVE-2026-40176 memengaruhi metode Perforce::generateP4Command(), yang bertanggung jawab dalam membangun perintah shell untuk berinteraksi dengan repository Perforce. Dalam implementasinya, metode ini menggabungkan parameter koneksi seperti port, user, dan client langsung ke dalam perintah tanpa proses escaping yang aman. Jika parameter tersebut dikendalikan oleh pihak yang tidak tepercaya, misalnya melalui file composer.json yang dimodifikasi secara jahat, maka penyerang dapat menyisipkan karakter khusus shell untuk mengeksekusi perintah tambahan di sistem korban.

Namun demikian, ruang lingkup eksploitasi untuk kerentanan ini relatif terbatas. Composer hanya memuat konfigurasi repository VCS dari file composer.json utama yang berada di direktori kerja pengguna atau dari direktori konfigurasi global seperti ~/.config/composer/composer.json. Artinya, file composer.json yang berasal dari dependensi pihak ketiga tidak secara otomatis menjadi vektor eksploitasi. Risiko muncul ketika pengguna menjalankan perintah Composer pada proyek yang tidak terpercaya, terutama jika file composer.json dalam proyek tersebut telah dimanipulasi oleh penyerang.

Kerentanan kedua, CVE-2026-40261, ditemukan pada metode Perforce::syncCodeBase(). Dalam kasus ini, masalah muncul dari parameter source reference yang ditambahkan ke dalam perintah shell tanpa escaping yang memadai. Parameter ini dapat dimanipulasi untuk menyisipkan karakter metakarakter shell, sehingga memungkinkan eksekusi perintah arbitrer. Peneliti juga mengidentifikasi bahwa kelemahan serupa pada metode generateP4Command() turut berdampak pada field source URL, memperluas potensi permukaan serangan.

Berbeda dengan kerentanan sebelumnya, CVE-2026-40261 memiliki vektor eksploitasi yang lebih luas. Parameter source reference dan source URL berasal dari metadata paket, yang dapat disediakan oleh repository Composer mana pun. Dengan kata lain, repository yang telah dikompromikan atau dibuat secara khusus untuk tujuan berbahaya dapat mendistribusikan metadata yang mengandung payload eksploitasi. Hal ini berarti pengguna tidak perlu secara langsung membuka proyek berbahaya untuk menjadi korban; cukup dengan menginstal dependensi dari repository yang tidak terpercaya, risiko eksploitasi sudah muncul.

Menariknya, eksploitasi terhadap kerentanan ini tidak bergantung pada keberadaan Perforce di sistem korban. Composer tetap akan mencoba mengeksekusi perintah shell yang telah dibangun, terlepas dari apakah Perforce terinstal atau tidak. Ini memperluas potensi dampak serangan, karena tidak ada prasyarat khusus pada lingkungan sistem selain penggunaan Composer itu sendiri.

Eksploitasi CVE-2026-40261 terutama terjadi dalam skenario di mana dependensi diinstal dari source, misalnya dengan menggunakan opsi --prefer-source atau ketika menginstal paket versi pengembangan (dev). Dalam mode ini, Composer cenderung mengambil kode langsung dari repository sumber, bukan dari distribusi arsip yang telah dikemas. Hal ini membuka jalur bagi metadata berbahaya untuk diproses dan dieksekusi sebagai bagian dari workflow instalasi.

Langkah Mitigasi

Sebagai respons terhadap temuan ini, tim pengembang Composer telah merilis pembaruan keamanan yang mencakup perbaikan untuk kedua kerentanan tersebut. Versi yang telah diperbaiki adalah Composer 2.9.6 untuk jalur rilis utama dan 2.2.27 untuk cabang long-term support (LTS). Pengguna yang masih menjalankan versi lama sangat disarankan untuk segera melakukan pembaruan guna memitigasi risiko yang ada.

Selain pembaruan perangkat lunak, terdapat beberapa langkah mitigasi yang relevan untuk mengurangi potensi eksploitasi. Untuk CVE-2026-40261, disarankan untuk menghindari instalasi dependensi dari source dengan menggunakan opsi --prefer-dist atau mengatur preferensi instalasi ke mode distribusi. Pendekatan ini mengurangi kemungkinan eksekusi perintah yang berasal dari metadata repository. Sementara itu, untuk CVE-2026-40176, praktik terbaik mencakup audit manual terhadap file composer.json sebelum menjalankan perintah Composer, khususnya jika proyek berasal dari sumber yang belum diverifikasi.

Langkah mitigasi lain yang tidak kalah penting adalah membatasi penggunaan repository Composer hanya pada sumber yang terpercaya. Dalam ekosistem open-source yang terbuka, integritas repository menjadi faktor krusial dalam menjaga keamanan rantai pasokan perangkat lunak. Serangan yang memanfaatkan metadata paket merupakan bagian dari tren yang lebih luas dalam supply chain attack, di mana penyerang menargetkan titik distribusi dependensi untuk menyusupkan kode berbahaya.

Sebagai tindakan pencegahan tambahan, platform distribusi paket utama, Packagist, telah melakukan pemindaian terhadap paket yang ada dan tidak menemukan indikasi eksploitasi aktif menggunakan metadata Perforce yang berbahaya. Meskipun demikian, sebagai langkah mitigasi proaktif, publikasi metadata source Perforce telah dinonaktifkan sejak 10 April 2026. Kebijakan ini bertujuan untuk menutup sementara potensi jalur distribusi eksploitasi hingga ekosistem benar-benar aman dari ancaman tersebut.

Kesimpulan 

Kasus ini kembali mengingatkan pentingnya validasi input yang ketat dalam pengembangan perangkat lunak, terutama pada komponen yang berinteraksi langsung dengan sistem operasi. Kesalahan kecil dalam proses escaping dapat berujung pada konsekuensi serius, termasuk eksekusi perintah arbitrer yang dapat mengkompromikan sistem secara penuh. Bagi developer dan praktisi keamanan, insiden ini menjadi pengingat bahwa keamanan tidak hanya bergantung pada konfigurasi atau kebijakan, tetapi juga pada implementasi kode yang aman di level fundamental.

Dengan meningkatnya kompleksitas ekosistem dependensi modern, pendekatan defensif seperti verifikasi sumber, pembaruan rutin, dan pembatasan trust boundary menjadi semakin penting. Composer, sebagai salah satu komponen inti dalam pengembangan aplikasi PHP, kini telah menutup celah tersebut, tetapi tanggung jawab akhir tetap berada pada pengguna untuk memastikan bahwa praktik penggunaan mereka tidak membuka peluang eksploitasi yang serupa di masa depan.

Baca Juga:

36 Paket Berbahaya di NPM Menyamar sebagai Plugin Strapi, Targetkan Infrastruktur Kripto dengan Eksploitasi Redis dan PostgreSQL

Teknik Baru Web Shell: Aktor Ancaman Sembunyikan Eksekusi Kode Lewat HTTP Cookie di Server Linux

Adobe Rilis Patch Darurat untuk Celah Kritis Acrobat Reader yang Dieksploitasi Aktif - 2026

Perusahaan perangkat lunak Adobe merilis pembaruan keamanan darurat untuk menutup kerentanan kritis pada produk Acrobat dan Acrobat Reader setelah ditemukan bukti eksploitasi aktif di dunia nyata. Celah keamanan ini, yang diidentifikasi sebagai CVE-2026-34621, memungkinkan penyerang menjalankan kode berbahaya pada sistem korban melalui dokumen PDF yang dirancang secara khusus.

Kerentanan tersebut memiliki skor CVSS 8,6 dari 10, menandakan tingkat keparahan tinggi dengan potensi dampak signifikan terhadap integritas dan keamanan sistem. Dalam analisis teknisnya, celah ini dikategorikan sebagai prototype pollution, sebuah kelemahan dalam konteks JavaScript yang memungkinkan manipulasi properti objek secara tidak sah. Dalam praktiknya, teknik ini dapat membuka jalur bagi eksekusi kode arbitrer, yang berarti penyerang tidak hanya dapat membaca data tetapi juga menjalankan perintah berbahaya di lingkungan korban.

Celah ini memengaruhi berbagai versi produk Acrobat di sistem operasi Windows dan macOS. Adobe mengonfirmasi bahwa versi Acrobat DC dan Acrobat Reader DC hingga 26.001.21367 terdampak, dengan perbaikan telah dirilis pada versi 26.001.21411. Sementara itu, untuk lini Acrobat 2024, versi sebelum 24.001.30356 juga terdampak, dengan patch tersedia pada versi 24.001.30362 untuk Windows dan 24.001.30360 untuk macOS. Pembaruan ini menjadi langkah krusial mengingat eksploitasi kerentanan telah terdeteksi berlangsung di lingkungan nyata, bukan sekadar uji laboratorium.

Dalam pernyataan resminya, Adobe mengakui bahwa mereka “menyadari adanya eksploitasi aktif terhadap CVE-2026-34621 di dunia nyata.” Pernyataan ini mempertegas urgensi pembaruan, terutama bagi organisasi dan individu yang masih menggunakan versi perangkat lunak yang rentan. Eksploitasi aktif menunjukkan bahwa pelaku ancaman telah mengembangkan metode serangan yang memanfaatkan celah tersebut sebelum patch tersedia secara luas.

Temuan awal terkait eksploitasi kerentanan ini diungkap oleh Haifei Li, seorang peneliti keamanan sekaligus pendiri EXPMON. Ia mengidentifikasi bahwa celah tersebut dapat dimanfaatkan untuk menjalankan kode JavaScript berbahaya ketika pengguna membuka dokumen PDF yang telah dimodifikasi. Mekanisme serangan ini relatif sederhana dari perspektif pengguna akhir, karena hanya memerlukan interaksi berupa membuka file, tanpa indikasi mencurigakan yang jelas.

Lebih lanjut, indikasi menunjukkan bahwa eksploitasi terhadap celah ini kemungkinan telah berlangsung sejak Desember 2025. Jika dikonfirmasi, hal ini berarti terdapat jendela waktu yang cukup panjang di mana sistem rentan dapat disusupi tanpa disadari. Dalam konteks keamanan siber, periode eksploitasi sebelum patch tersedia sering kali menjadi fase paling berbahaya, karena pengguna tidak memiliki mitigasi resmi selain langkah pencegahan manual.

Perubahan skor CVSS dari sebelumnya 9,6 menjadi 8,6 juga mencerminkan penyesuaian dalam vektor serangan. Adobe memperbarui parameter dari Network (AV:N) menjadi Local (AV:L), yang berarti eksploitasi memerlukan interaksi pengguna secara langsung, seperti membuka file berbahaya. Meskipun demikian, dampaknya tetap signifikan karena vektor distribusi PDF berbahaya dapat dilakukan melalui berbagai saluran, termasuk email phishing, unduhan situs tidak terpercaya, atau distribusi melalui platform berbagi file.

Dalam analisis yang dipublikasikan oleh EXPMON, disebutkan bahwa kerentanan ini tidak hanya terbatas pada kebocoran informasi, tetapi berpotensi mengarah pada eksekusi kode arbitrer. Hal ini memperluas spektrum ancaman, dari sekadar pencurian data menjadi pengambilalihan sistem secara penuh. Temuan ini juga konsisten dengan observasi peneliti keamanan lain yang memantau aktivitas eksploitasi dalam beberapa hari terakhir sebelum pengumuman resmi dari Adobe.

Dari perspektif teknis, prototype pollution merupakan kelas kerentanan yang sering kali sulit dideteksi dalam aplikasi berbasis JavaScript yang kompleks. Dengan memanipulasi prototipe objek global, penyerang dapat mengubah perilaku aplikasi secara tidak terduga. Dalam konteks Acrobat Reader, ini membuka kemungkinan injeksi kode yang dieksekusi dalam runtime aplikasi, sehingga melewati beberapa mekanisme perlindungan tradisional.

Adobe telah menyediakan beberapa metode pembaruan bagi pengguna untuk mengatasi risiko ini. Pengguna individu dapat memperbarui perangkat lunak melalui menu “Help” dan memilih “Check for Updates,” sementara sistem juga dapat diperbarui secara otomatis jika fitur pembaruan diaktifkan. Untuk lingkungan enterprise, administrator TI disarankan menggunakan metode distribusi terpusat seperti SCCM, GPO, atau Apple Remote Desktop untuk memastikan seluruh endpoint diperbarui secara konsisten.

Pembaruan ini menegaskan pentingnya manajemen patch yang disiplin, terutama untuk perangkat lunak yang digunakan secara luas seperti Acrobat Reader. Dalam banyak kasus, PDF dianggap sebagai format yang relatif aman oleh pengguna awam, padahal secara teknis dapat menjadi vektor serangan yang efektif jika terdapat celah pada engine pemrosesnya.

Kasus CVE-2026-34621 juga mencerminkan pola yang semakin umum dalam lanskap ancaman modern, di mana eksploitasi zero-day terjadi sebelum vendor merilis patch resmi. Hal ini menempatkan organisasi dalam posisi reaktif, di mana deteksi dini dan respons insiden menjadi faktor kunci dalam meminimalkan dampak.

Dengan adanya bukti eksploitasi aktif, pembaruan terhadap perangkat lunak bukan lagi sekadar rekomendasi, melainkan kebutuhan mendesak. Sistem yang tidak diperbarui berisiko menjadi titik masuk bagi serangan lanjutan, termasuk penyebaran malware, pencurian data sensitif, atau bahkan kompromi jaringan secara menyeluruh.

Dalam konteks yang lebih luas, insiden ini kembali menyoroti pentingnya kolaborasi antara vendor dan komunitas peneliti keamanan. Adobe secara khusus memberikan kredit kepada Haifei Li atas pelaporan kerentanan ini, yang menunjukkan peran krusial peneliti independen dalam mengidentifikasi dan mengungkap celah sebelum disalahgunakan secara lebih luas.

Seiring meningkatnya kompleksitas perangkat lunak modern, potensi munculnya kerentanan serupa tetap tinggi. Oleh karena itu, pendekatan proaktif terhadap keamanan, termasuk pembaruan rutin, pemantauan aktivitas mencurigakan, dan edukasi pengguna, menjadi elemen penting dalam mempertahankan ketahanan sistem terhadap ancaman yang terus berkembang.

36 Paket Berbahaya di NPM Menyamar sebagai Plugin Strapi, Targetkan Infrastruktur Kripto dengan Eksploitasi Redis dan PostgreSQL

Sebuah kampanye berbahaya yang terstruktur dan terarah telah terungkap di ekosistem NPM, di mana sedikitnya 36 paket ditemukan menyamar sebagai plugin untuk Strapi CMS. Paket-paket ini tidak sekadar berisi kode berbahaya biasa, tetapi dirancang dengan berbagai payload kompleks yang mampu mengeksploitasi Redis dan PostgreSQL, mencuri kredensial sensitif, hingga menanam implant persisten pada sistem korban. Temuan ini menunjukkan adanya operasi yang matang dengan tujuan spesifik, yakni menargetkan infrastruktur platform pembayaran berbasis cryptocurrency.

Secara kronologis, aktivitas publikasi paket dimulai dengan akun umar_bektembiev1 yang merilis gelombang awal, termasuk paket seperti strapi-plugin-cron dan varian lain yang memiliki kemampuan eksploitasi tingkat lanjut. Dalam waktu beberapa jam, paket-paket lain menyusul dari akun berbeda seperti umarbek1233, kekylf12, dan tikeqemif26. Pola publikasi yang saling tumpang tindih serta konsistensi teknik serangan menunjukkan bahwa seluruh akun tersebut kemungkinan dikendalikan oleh aktor yang sama.

Setiap paket membawa fungsi spesifik dalam rantai serangan. Misalnya, strapi-plugin-cron memanfaatkan teknik eksploitasi Redis melalui perintah CONFIG SET untuk menyuntikkan entri crontab, menulis webshell berbasis PHP, serta menjalankan reverse shell berbasis Node.js. Selain itu, paket ini juga mencoba menyisipkan kunci SSH ke dalam authorized_keys serta membaca data mentah dari disk menggunakan kombinasi mknod dan dd untuk mengekstrak informasi sensitif.

Paket lain seperti strapi-plugin-config memperluas kemampuan serangan dengan mencoba melakukan escape dari container Docker melalui analisis overlay filesystem. Dengan menemukan direktori upperdir, payload dapat ditulis ke lokasi yang dapat diakses host. Teknik ini memungkinkan penyerang melampaui isolasi container dan mengakses sistem yang lebih luas. Tidak hanya itu, paket ini juga membaca data mentah untuk menemukan kredensial Elasticsearch serta wallet kripto, kemudian menyisipkan hook berbahaya ke dalam node_modules.

Serangkaian paket lain seperti strapi-plugin-server, strapi-plugin-database, hingga strapi-plugin-hooks difokuskan pada eksekusi reverse shell secara langsung. Menariknya, payload ini menggunakan mekanisme gating berbasis hostname, hanya aktif jika sistem target mengandung string tertentu seperti “prod”. Hal ini menunjukkan bahwa serangan dirancang untuk menghindari deteksi di lingkungan pengujian atau sandbox. Reverse shell dijalankan melalui bash pada port 4444 dan Python pada port 8888, serta dapat dipicu melalui Redis.

Eksfiltrasi data menjadi komponen utama dalam kampanye ini. Paket seperti strapi-plugin-events dan strapi-plugin-monitor dirancang untuk mengumpulkan kredensial dalam skala besar. Mereka menelusuri file .env, variabel lingkungan, konfigurasi Strapi, serta file sistem untuk menemukan private key, token Kubernetes, dan informasi jaringan. Data yang dikumpulkan mencakup koneksi PostgreSQL, isi Redis, hingga informasi Docker dan Kubernetes, yang semuanya dikirim ke server command-and-control menggunakan HTTP tanpa enkripsi.

Teknik eksfiltrasi yang digunakan juga menunjukkan tingkat kecanggihan tertentu. Salah satu varian payload menerapkan metode chunking, memecah data besar menjadi segmen 50KB untuk menghindari batasan ukuran atau deteksi. Setiap bagian dikirim dengan penomoran tertentu, memungkinkan rekonstruksi data secara lengkap di sisi server penyerang. Jalur komunikasi C2 menggunakan path berbasis routing seperti /c2/<id>/env untuk file lingkungan atau /c2/<id>/redis-full untuk dump Redis.

Eksploitasi terhadap PostgreSQL dilakukan secara langsung dalam paket seperti strapi-plugin-seed. Dengan menggunakan kredensial hardcoded, paket ini dapat terhubung ke database, mengekstrak tabel yang berkaitan dengan transaksi, wallet, dan deposit, serta melakukan enumerasi terhadap seluruh database dalam server. Bahkan terdapat probing spesifik terhadap nama database seperti guardarian, guardarian_payments, exchange, dan custody, yang memperkuat indikasi bahwa serangan ini menargetkan platform tertentu secara spesifik.

Aspek persistence juga menjadi perhatian utama dalam kampanye ini. Versi tertentu dari strapi-plugin-api menanamkan agen C2 persisten ke dalam sistem dengan menulis file seperti /tmp/.node_gc.js dan menjalankannya secara terpisah. Selain itu, entri crontab ditambahkan untuk memastikan payload tetap aktif meskipun sistem direstart. Teknik fileless execution juga digunakan melalui perintah node -e, yang memungkinkan eksekusi kode tanpa meninggalkan artefak file yang jelas.

Semua data yang dicuri, termasuk private key, mnemonic wallet, dan kredensial lainnya, dikirim melalui HTTP ke alamat IP 144.31.107.231 pada port 9999 tanpa enkripsi. Hal ini berarti bahwa data sensitif dapat dengan mudah diintersepsi jika lalu lintas jaringan dipantau, namun juga menunjukkan bahwa fokus utama penyerang adalah kecepatan dan volume eksfiltrasi, bukan stealth tingkat jaringan.

Indikasi kuat bahwa ini adalah penargetan yang dilakukan terlihat dari referensi spesifik terhadap infrastruktur tertentu dalam payload, termasuk path direktori, nama layanan, serta kredensial database yang sudah diketahui sebelumnya. Hal ini menandakan bahwa penyerang kemungkinan telah memiliki akses awal atau intelijen sebelumnya terhadap target, bukan sekadar melakukan serangan acak terhadap ekosistem NPM.

Hal ini juga bersamaan dengan lonjakan serangan yang kemudian menargetkan ekosistem sumber terbuka atau Open Source melalui rantai serangan:

1. user atau pengguna GitHub dengan nama ezmtebo teridentifikasi mengirim lebih dari 256 pull request yang telah disisipi payload pencurian kredensial. Teknik yang digunakan memanfaatkan log CI/CD serta komentar pada pull request untuk mengekstrak secret dari lingkungan pengembangan tanpa memicu kecurigaan langsung.

2. Organisasi GitHub dev-protocol dilaporkan mengalami pengambilalihan akun dan dimanfaatkan untuk mendistribusikan bot trading Polymarket berbahaya. Paket tersebut mengandalkan dependency npm dengan teknik typosquatting untuk mencuri private key wallet serta membuka akses backdoor melalui SSH.

3. Paket Emacs kubernetes-el/kubernetes-el menjadi korban kompromi melalui eksploitasi celah pada workflow GitHub Actions yang dikenal sebagai Pwn Request. Serangan ini memungkinkan pelaku mendapatkan GITHUB_TOKEN milik repository, yang kemudian digunakan untuk menyisipkan kode destruktif ke dalam proyek.

4. Workflow GitHub Actions milik proyek xygeni/xygeni-action berhasil ditembus setelah kredensial maintainer dicuri. Akses ini dimanfaatkan untuk menanamkan backdoor berupa reverse shell. Setelah insiden tersebut, pihak Xygeni telah melakukan penguatan kontrol keamanan pada sistem mereka.

5. Paket npm mgc disusupi melalui pengambilalihan akun maintainer, yang kemudian digunakan untuk merilis versi berbahaya. Versi ini mengandung dropper yang mengunduh payload sesuai platform, yakni trojan berbasis Python untuk Linux dan varian PowerShell untuk Windows. Pola serangan ini memiliki kemiripan dengan kampanye supply chain sebelumnya yang menargetkan Axios dan dikaitkan dengan aktor UNC1069 yang di sinyalir dari Korea Utara.

6. Sebuah paket npm berbahaya dengan nama express-session-js ditemukan meniru paket populer "express-session". Paket ini berfungsi sebagai dropper yang mengunduh remote access trojan (RAT), membuka akses jarak jauh ke sistem korban.

7. Paket PyPI bittensor-wallet versi 4.0.2 diketahui telah dimodifikasi untuk menyisipkan backdoor. Payload ini secara khusus dirancang untuk mengekstrak private key dari wallet pengguna.

8. Paket npm @azure/service-bus-node mengandung komponen berbahaya berupa dropper yang mengambil RAT dari layanan JSON Keeper. Malware ini digunakan untuk mencuri data sekaligus mempertahankan akses persisten dengan membangun koneksi ke alamat IP 216.126.237[.]71 melalui library Socket.IO.

Dampak dari serangan ini sangat signifikan. Sistem yang terinfeksi dapat mengalami kompromi penuh, termasuk akses root, kebocoran data sensitif, serta pengambilalihan layanan. Oleh karena itu, setiap pengguna yang pernah menginstal paket-paket tersebut disarankan untuk menganggap sistem mereka telah sepenuhnya dikompromikan.

Langkah mitigasi yang direkomendasikan mencakup rotasi seluruh kredensial yang mungkin terekspos, termasuk password database, API key, dan JWT secret. Password PostgreSQL yang digunakan dalam payload harus segera diganti jika masih digunakan. Token Kubernetes juga perlu dicabut untuk mencegah penyalahgunaan lebih lanjut. Selain itu, sistem harus diperiksa untuk mekanisme persistence seperti file mencurigakan di direktori /tmp, entri crontab yang tidak dikenal, serta proses node yang berjalan tanpa konteks jelas.

Audit terhadap Redis juga diperlukan, khususnya dengan memeriksa konfigurasi direktori melalui perintah CONFIG GET dir untuk memastikan tidak ada manipulasi. Penggunaan alat keamanan seperti pemindai dependency dapat membantu mendeteksi paket berbahaya sebelum mencapai lingkungan produksi. Pencegahan di tahap instalasi menjadi krusial mengingat serangan ini memanfaatkan kepercayaan terhadap ekosistem open-source.

Kasus ini menegaskan kembali bahwa supply chain attack di ekosistem JavaScript masih menjadi ancaman nyata, terutama bagi proyek yang mengandalkan banyak dependency eksternal. Dengan kompleksitas payload dan tingkat target yang spesifik, kampanye ini menunjukkan evolusi serangan yang tidak lagi bersifat oportunistik, melainkan dirancang dengan presisi tinggi untuk mencapai tujuan tertentu.

Sumber:

safedep

stepsecurity

xygeni

PyPi

cyberandramen

Baca Juga:

Claude Code Repo

Celah Kritis pyLoad Buka Jalan RCE Tanpa Autentikasi: Analisis Bug storage_folder dan Risiko Session Poisoning

Kerentanan baru pada aplikasi manajemen unduhan pyLoad mengungkap kelemahan serius yang memungkinkan eksekusi kode arbitrer tanpa autentikasi melalui mekanisme yang tidak biasa, yaitu manipulasi direktori penyimpanan dan penyalahgunaan sistem sesi berbasis filesystem. Celah ini merupakan kelanjutan dari perbaikan yang tidak lengkap terhadap kerentanan sebelumnya, CVE-2026-33509, dan menunjukkan bagaimana kontrol akses yang tidak komprehensif dapat membuka jalur eksploitasi baru yang signifikan.

Masalah utama berakar pada opsi konfigurasi bernama storage_folder yang tidak dimasukkan dalam daftar parameter sensitif yang dibatasi hanya untuk admin. Dalam implementasi sebelumnya, pengembang telah memperkenalkan mekanisme pembatasan melalui sebuah set bernama ADMIN_ONLY_OPTIONS untuk mencegah pengguna non-admin mengubah konfigurasi kritikal. Namun, storage_folder tidak termasuk dalam daftar tersebut. Akibatnya, pengguna dengan kombinasi izin tertentu masih dapat mengubah lokasi penyimpanan file unduhan tanpa pembatasan yang memadai.

Dalam konteks ini, eksploitasi membutuhkan seorang pengguna non-admin yang memiliki dua jenis izin, yaitu SETTINGS dan ADD. Kedua izin ini bersifat independen dan dapat diberikan secara bersamaan oleh administrator. Dengan izin SETTINGS, pengguna dapat mengubah konfigurasi storage_folder. Sementara itu, izin ADD memungkinkan pengguna untuk menambahkan URL unduhan. Kombinasi ini menjadi fondasi utama dalam rantai serangan.

Eksploitasi dimulai dengan mengarahkan storage_folder ke direktori yang digunakan oleh sistem sesi Flask, yang secara default berada di jalur seperti /tmp/pyLoad/flask dalam deployment berbasis Docker. Jalur ini lolos dari mekanisme validasi karena tidak berada dalam direktori yang dibatasi seperti PKGDIR atau userdir. Validasi yang ada hanya memeriksa apakah path hasil realpath berada dalam dua direktori tersebut, sehingga direktori sesi Flask tetap dapat diakses.

Selanjutnya, penyerang menghitung nama file sesi yang akan ditargetkan. Sistem sesi Flask yang digunakan oleh pyLoad dikonfigurasi dengan SESSION_TYPE = "filesystem" dan memanfaatkan cachelib FileSystemCache untuk menyimpan sesi. File sesi disimpan menggunakan hash MD5 dari string yang menggabungkan prefix default "session:" dengan session_id. Dengan mengetahui pola ini, penyerang dapat menentukan nama file sesi yang valid secara deterministik.

Tahap berikutnya melibatkan pembuatan payload berbahaya menggunakan serialisasi Python melalui modul pickle. Payload ini dirancang untuk mengeksekusi perintah sistem ketika dide-serialisasi. Dalam contoh yang diuji, payload tersebut menulis hasil perintah id ke dalam file tertentu sebagai bukti eksekusi. File payload kemudian di-host oleh penyerang dan diunduh oleh pyLoad melalui mekanisme normal unduhan, yang menyimpannya ke direktori storage_folder yang telah dimanipulasi, yaitu direktori sesi Flask.

Yang membuat kerentanan ini semakin signifikan adalah tahap akhir eksploitasi yang tidak memerlukan autentikasi. Setelah file sesi berbahaya berhasil ditempatkan di direktori yang tepat, penyerang hanya perlu mengirimkan permintaan HTTP dengan cookie sesi yang sesuai. Ketika aplikasi memproses permintaan tersebut, Flask akan memuat file sesi berdasarkan session_id yang diberikan. Proses ini melibatkan deserialisasi menggunakan pickle.load(), yang secara langsung mengeksekusi payload berbahaya.

Hasil akhirnya adalah eksekusi kode arbitrer dengan hak akses proses pyLoad. Dalam pengujian yang dilakukan pada image Docker lscr.io/linuxserver/pyload-ng:latest, eksploitasi ini berhasil dijalankan dan menunjukkan bahwa penyerang dapat menjalankan perintah sistem, membaca variabel lingkungan, mengakses sistem file, dan berpotensi melakukan pivot ke sumber daya jaringan lain. Fakta bahwa trigger akhir tidak memerlukan autentikasi meningkatkan tingkat risiko secara signifikan.

Dari perspektif desain sistem, kerentanan ini menunjukkan kelemahan dalam pendekatan validasi path yang hanya berfokus pada pembatasan direktori tertentu tanpa mempertimbangkan direktori sensitif lain yang digunakan secara internal oleh aplikasi atau dependensinya. Dalam kasus ini, direktori sesi Flask menjadi target yang ideal karena file di dalamnya secara otomatis diproses oleh aplikasi.

Selain itu, penggunaan pickle untuk deserialisasi data yang tidak terpercaya merupakan praktik yang dikenal berisiko tinggi. Pickle tidak dirancang untuk keamanan dan dapat mengeksekusi kode arbitrer selama proses deserialisasi. Ketika digabungkan dengan kemampuan menulis file ke lokasi yang diproses otomatis, risiko eksploitasi meningkat secara drastis.

Sebagai langkah mitigasi, disarankan untuk menambahkan storage_folder ke dalam daftar ADMIN_ONLY_OPTIONS agar hanya dapat dimodifikasi oleh administrator. Alternatif lain adalah memperluas validasi path untuk mencegah penulisan ke direktori sementara yang secara otomatis dikonsumsi oleh aplikasi, termasuk direktori sesi Flask, cache bytecode Jinja, dan direktori sementara pyLoad. Perbaikan tambahan juga mencakup koreksi nama opsi konfigurasi yang sebelumnya salah, seperti ssl_cert dan ssl_key yang seharusnya menggunakan nama ssl_certfile dan ssl_keyfile.

Kasus ini menyoroti pentingnya pendekatan holistik dalam pengamanan aplikasi, terutama dalam sistem yang memungkinkan konfigurasi dinamis oleh pengguna. Kontrol akses yang tidak lengkap, validasi input yang terbatas, dan penggunaan mekanisme deserialisasi yang tidak aman dapat saling berinteraksi dan menciptakan jalur eksploitasi yang kompleks namun efektif.

Bagi praktisi keamanan dan developer, temuan ini menjadi pengingat bahwa kerentanan tidak selalu berasal dari satu kesalahan tunggal, melainkan dari kombinasi beberapa asumsi yang tidak divalidasi secara menyeluruh. Dalam konteks pyLoad, celah ini muncul dari interaksi antara kontrol akses, manajemen path, dan mekanisme penyimpanan sesi. Tanpa evaluasi menyeluruh terhadap bagaimana komponen-komponen ini saling berinteraksi, risiko seperti ini dapat dengan mudah terlewatkan.

Dengan semakin banyaknya aplikasi yang mengandalkan komponen pihak ketiga seperti Flask dan cachelib, pemahaman terhadap bagaimana komponen tersebut bekerja secara internal menjadi semakin penting. Kerentanan ini menunjukkan bahwa bahkan konfigurasi default yang tampak aman dapat menjadi titik lemah jika tidak dipertimbangkan dalam model ancaman secara menyeluruh.

References:

NVD-NIST

Github Rep

Kerentanan Kritis CVE-2026-5281 di Google Chrome: Bug Use-After-Free Picu Risiko Eksekusi Kode Jarak Jauh

Kerentanan baru dengan kode CVE-2026-5281 ditemukan pada browser populer Google Chrome, menyoroti kembali risiko serius yang dapat muncul dari kesalahan manajemen memori dalam perangkat lunak modern. Bug ini diklasifikasikan sebagai use-after-free, sebuah jenis kerentanan yang terjadi ketika program masih mencoba mengakses memori yang telah dibebaskan. Dalam konteks ini, celah tersebut berada pada komponen Dawn di Chrome dan berpotensi dimanfaatkan untuk eksekusi kode arbitrer oleh penyerang.

Berdasarkan informasi dari National Vulnerability Database (NVD), kerentanan ini memengaruhi versi Chrome sebelum 146.0.7680.178. Eksploitasi hanya dapat dilakukan jika penyerang telah lebih dulu berhasil mengompromikan proses renderer, yang merupakan bagian dari arsitektur sandbox Chrome yang bertugas menangani konten web. Setelah mendapatkan akses tersebut, penyerang dapat menyisipkan halaman HTML yang dirancang secara khusus untuk memicu kondisi use-after-free dan mengeksekusi kode berbahaya di sistem target.

Meskipun analisis resmi dari NVD terkait skor CVSS belum tersedia pada saat laporan ini ditulis, data dari sumber lain, termasuk Cybersecurity and Infrastructure Security Agency, memberikan gambaran tingkat keparahan yang signifikan. Skor CVSS v3.1 tercatat sebesar 8.8 dengan kategori High. Vektor serangan menunjukkan bahwa eksploitasi dapat dilakukan melalui jaringan tanpa memerlukan autentikasi, dengan kompleksitas rendah, namun tetap membutuhkan interaksi pengguna. Dampak dari kerentanan ini mencakup aspek kerahasiaan, integritas, dan ketersediaan sistem secara menyeluruh.

Secara teknis, kerentanan ini termasuk dalam kategori Common Weakness Enumeration dengan ID CWE-416, yang merujuk pada use-after-free. Jenis bug ini sering kali menjadi target eksploitasi tingkat lanjut karena dapat memungkinkan manipulasi memori secara langsung. Dalam banyak kasus, eksploitasi use-after-free digunakan sebagai langkah awal untuk mencapai remote code execution (RCE), terutama jika dikombinasikan dengan teknik bypass sandbox atau privilege escalation.

Yang menarik, eksploitasi terhadap CVE-2026-5281 tidak berdiri sendiri. Penyerang harus terlebih dahulu melewati lapisan perlindungan awal Chrome dengan mengompromikan renderer process. Ini menunjukkan bahwa serangan kemungkinan melibatkan rantai eksploitasi yang lebih kompleks, bukan sekadar satu celah tunggal. Namun demikian, setelah tahap awal ini berhasil, dampaknya bisa sangat signifikan karena memungkinkan kontrol penuh terhadap proses yang berjalan.

Kerentanan ini berdampak pada berbagai sistem operasi yang menjalankan Chrome, termasuk macOS, Linux, dan Windows. Hal ini menegaskan bahwa cakupan risiko tidak terbatas pada satu platform tertentu, melainkan bersifat lintas ekosistem. Pengguna individu, organisasi, hingga lingkungan enterprise yang mengandalkan Chrome sebagai browser utama berpotensi terdampak jika tidak segera melakukan pembaruan.

Sebagai respons terhadap temuan ini, vendor telah merilis pembaruan keamanan yang memperbaiki kerentanan tersebut pada versi 146.0.7680.178 dan yang lebih baru. Otoritas keamanan siber juga merekomendasikan agar pengguna segera mengaplikasikan patch yang tersedia. Dalam beberapa kasus, jika mitigasi tidak dapat diterapkan, langkah alternatif seperti menghentikan penggunaan produk menjadi pertimbangan, terutama dalam lingkungan dengan tingkat risiko tinggi.

Selain itu, CVE-2026-5281 juga telah masuk dalam daftar prioritas dengan tenggat waktu mitigasi yang relatif singkat, yakni hingga pertengahan April 2026. Ini menunjukkan bahwa kerentanan tersebut dianggap memiliki potensi dampak yang signifikan dan membutuhkan penanganan segera. Praktik terbaik yang disarankan mencakup penerapan patch, pemantauan aktivitas sistem, serta evaluasi terhadap kemungkinan adanya indikasi kompromi.

Dari perspektif keamanan yang lebih luas, kasus ini kembali menegaskan pentingnya pengelolaan memori yang aman dalam pengembangan perangkat lunak. Use-after-free bukanlah jenis kerentanan baru, namun tetap relevan dan berbahaya karena kompleksitasnya serta potensi eksploitasi yang tinggi. Dalam ekosistem browser modern yang menangani berbagai jenis konten dinamis, kesalahan kecil dalam pengelolaan resource dapat membuka celah besar bagi penyerang.

Bagi praktisi keamanan, CVE-2026-5281 memberikan contoh nyata bagaimana kerentanan pada layer rendah seperti manajemen memori dapat berdampak langsung pada keamanan pengguna akhir. Sementara itu, bagi developer, ini menjadi pengingat bahwa pendekatan defensif dalam pengelolaan memori, termasuk penggunaan bahasa pemrograman yang lebih aman atau penerapan mekanisme proteksi tambahan, menjadi semakin penting.

Dengan semakin meningkatnya kompleksitas aplikasi web dan browser, potensi munculnya kerentanan serupa kemungkinan akan tetap ada. Oleh karena itu, kombinasi antara pembaruan rutin, monitoring aktif, dan kesadaran terhadap ancaman menjadi kunci dalam mengurangi risiko eksploitasi di dunia nyata. CVE-2026-5281 bukan hanya sekadar bug teknis, tetapi juga refleksi dari tantangan berkelanjutan dalam menjaga keamanan perangkat lunak yang digunakan secara luas.

CVE-2026-2699 dan CVE-2026-2701: Eksploitasi Kritis ShareFile Memungkinkan RCE Tanpa Autentikasi

Peneliti keamanan dari watchTowr Labs mengungkap rantai eksploitasi kritis yang menargetkan ShareFile Storage Zone Controller milik Progress Software, sebuah komponen on-premises yang banyak digunakan sebagai gateway berbagi file di lingkungan enterprise dan sektor yang diatur secara ketat. Temuan ini mengungkap dua kerentanan dengan dampak serius yang memungkinkan penyerang mendapatkan kontrol penuh atas server tanpa memerlukan autentikasi sama sekali.

Kerentanan tersebut dilacak sebagai CVE-2026-2699 dan CVE-2026-2701. Kombinasi keduanya membuka jalur eksploitasi yang memungkinkan Remote Code Execution (RCE) secara langsung, menjadikan sistem yang rentan sebagai target bernilai tinggi dalam lanskap ancaman saat ini.

Platform Managed File Transfer (MFT) dalam beberapa tahun terakhir telah menjadi sasaran utama bagi kelompok advanced persistent threat (APT) dan operator ransomware. Serangkaian insiden besar yang melibatkan solusi seperti MOVEit Transfer, Cleo Harmony, dan GoAnywhere MFT menunjukkan pola yang konsisten, di mana pelaku ancaman berfokus pada celah di gateway berbagi file sebagai pintu masuk awal ke jaringan perusahaan.

Dalam konteks ini, ShareFile Storage Zone Controller menjadi target yang sangat menarik. Diperkirakan terdapat sekitar 30.000 instance yang terekspos ke internet publik, menciptakan permukaan serangan yang luas. Sistem ini banyak digunakan oleh organisasi yang memiliki kebutuhan khusus terkait kedaulatan data atau kepatuhan regulasi, sehingga memilih deployment on-premises dibandingkan solusi cloud.

Komponen Storage Zone Controller berfungsi sebagai jembatan antara infrastruktur internal organisasi dengan antarmuka web ShareFile. Ia mengelola alur upload dan download file melalui jaringan internal, sehingga memiliki akses langsung ke data sensitif. Menariknya, kedua kerentanan yang ditemukan sepenuhnya berada pada komponen ini, sehingga deployment berbasis cloud tidak terdampak.

Rantai serangan dimulai dari celah pada panel konfigurasi administrator yang terletak di endpoint /ConfigService/Admin.aspx. Dalam kondisi normal, akses tanpa autentikasi ke endpoint ini akan menghasilkan redirect HTTP 302 ke halaman login sebagai mekanisme pengamanan standar.

Namun, peneliti menemukan kesalahan fatal dalam implementasi kode sumber berbasis C#. Pengembang diketahui mengirimkan parameter boolean bernilai false ke fungsi .Redirect(), yang menyebabkan server tidak menghentikan eksekusi halaman setelah mengirimkan redirect. Kondisi ini dikenal sebagai Execution After Redirect (EAR), sebuah kerentanan klasik namun tetap berbahaya jika tidak ditangani dengan benar.

Eksploitasi terhadap kelemahan ini relatif sederhana. Penyerang hanya perlu mencegat respons HTTP dan menghapus header Location sebelum browser memproses redirect. Dengan demikian, halaman administrator tetap dieksekusi dan ditampilkan sepenuhnya tanpa autentikasi. Hasilnya adalah akses administratif penuh terhadap sistem target.

Setelah mendapatkan akses administrator, tahap kedua eksploitasi memanfaatkan kelemahan dalam mekanisme konfigurasi penyimpanan file. Storage Zone Controller memungkinkan administrator menentukan lokasi direktori untuk menyimpan file yang diunggah. Sistem memang melakukan verifikasi terhadap kemampuan baca dan tulis pada path yang diberikan, tetapi tidak melakukan validasi apakah direktori tersebut aman atau sesuai dengan kebijakan aplikasi.

Ketiadaan validasi ini memungkinkan penyerang mengubah lokasi penyimpanan ke direktori web publik milik aplikasi, seperti C:\inetpub\wwwroot\ShareFile\StorageCenter\documentum. Dengan konfigurasi ini, setiap file yang diunggah akan langsung tersedia di webroot dan dapat diakses melalui browser.

Langkah berikutnya adalah mengunggah file ASPX berbahaya yang berfungsi sebagai web shell, namun disamarkan sebagai file biasa. Setelah file tersebut diunggah, penyerang cukup mengaksesnya melalui browser untuk mendapatkan kontrol jarak jauh penuh terhadap server. Dalam dua langkah sederhana—akses admin tanpa autentikasi dan upload file berbahaya—rantai eksploitasi berhasil diselesaikan.

Kedua kerentanan ini berdampak pada ShareFile Storage Zone Controller versi 5.x yang dibangun di atas framework ASP.NET. Peneliti mengonfirmasi keberadaan celah ini pada versi 5.12.3. Perbaikan telah dirilis oleh Progress Software dalam versi 5.12.4 pada 10 Maret 2026, meskipun tanpa pengumuman publik yang mencolok pada awalnya.

Dari perspektif operasional, kerentanan ini memiliki implikasi yang signifikan. Tidak hanya memungkinkan akses awal tanpa autentikasi, tetapi juga membuka jalur untuk eksekusi kode yang dapat digunakan untuk berbagai tujuan, mulai dari pencurian data hingga deployment ransomware. Mengingat posisi Storage Zone Controller dalam arsitektur jaringan, kompromi terhadap komponen ini dapat memberikan akses luas ke data internal organisasi.

Temuan ini juga memperkuat tren bahwa gateway file sharing dan MFT menjadi titik lemah yang terus dieksploitasi. Sistem-sistem ini sering kali berada di perbatasan antara jaringan internal dan eksternal, menjadikannya target ideal untuk mendapatkan foothold awal. Selain itu, kompleksitas konfigurasi dan kebutuhan integrasi dengan berbagai sistem lain meningkatkan risiko kesalahan implementasi.

Peneliti menekankan bahwa organisasi yang masih menjalankan versi rentan harus menganggap diri mereka berada dalam kondisi berisiko tinggi. Selain melakukan pembaruan ke versi terbaru, langkah respons insiden juga perlu dipertimbangkan, terutama jika sistem telah terekspos ke internet dalam waktu yang lama.

Pemantauan log server web menjadi salah satu indikator awal untuk mendeteksi aktivitas mencurigakan, khususnya permintaan yang menargetkan endpoint konfigurasi seperti /ConfigService/Admin.aspx. Selain itu, audit terhadap direktori webroot untuk mencari file ASPX yang tidak dikenal dapat membantu mengidentifikasi kemungkinan kompromi yang sudah terjadi.

Segmentasi jaringan juga menjadi faktor penting dalam membatasi dampak serangan. Dengan menempatkan gateway file on-premises di belakang aturan firewall yang ketat dan hanya mengizinkan akses dari host terpercaya, organisasi dapat mengurangi eksposur terhadap serangan langsung dari internet.

Kasus ini menunjukkan bagaimana kombinasi dua kelemahan yang tampak sederhana dapat menghasilkan dampak yang sangat besar ketika digabungkan dalam satu rantai eksploitasi. Lebih dari itu, ia menyoroti pentingnya validasi input dan kontrol alur eksekusi dalam pengembangan aplikasi, terutama pada komponen yang memiliki akses langsung ke data sensitif.

Dalam lanskap ancaman saat ini, kecepatan dalam menerapkan patch menjadi faktor krusial. Dengan adanya ribuan instance yang terekspos secara publik, jendela eksploitasi untuk aktor ancaman tetap terbuka selama sistem belum diperbarui. Situasi ini menempatkan organisasi dalam posisi yang rentan, terutama jika mereka mengandalkan sistem on-premises tanpa lapisan proteksi tambahan.

Eksploitasi terhadap ShareFile Storage Zone Controller menambah daftar panjang insiden yang melibatkan platform MFT. Pola yang muncul menunjukkan bahwa pelaku ancaman terus beradaptasi dan mencari celah di infrastruktur yang memiliki nilai strategis tinggi. Bagi tim keamanan, hal ini menuntut pendekatan yang lebih proaktif, tidak hanya dalam merespons kerentanan yang diketahui, tetapi juga dalam mengantisipasi bagaimana komponen kritis dapat disalahgunakan dalam skenario serangan nyata.

CVE-2026-3055 Mengancam Citrix NetScaler: Aktivitas Reconnaissance Terdeteksi, Risiko Kebocoran Data Meningkat

Kerentanan kritis baru yang memengaruhi produk Citrix kembali menjadi sorotan setelah peneliti keamanan mengonfirmasi adanya aktivitas reconnaissance aktif di internet. Celah keamanan yang terdaftar sebagai CVE-2026-3055 ini berdampak pada layanan NetScaler ADC dan NetScaler Gateway, dua komponen penting yang banyak digunakan organisasi untuk manajemen lalu lintas aplikasi dan akses jarak jauh.

Kerentanan tersebut memiliki skor CVSS 9.3, menandakan tingkat keparahan yang sangat tinggi. Secara teknis, masalah ini berasal dari validasi input yang tidak memadai, yang berujung pada kondisi memory overread. Dalam praktiknya, eksploitasi celah ini memungkinkan penyerang membaca bagian memori sistem yang seharusnya tidak dapat diakses, berpotensi mengungkap informasi sensitif seperti token autentikasi, kredensial, atau data konfigurasi internal.

Namun, eksploitasi tidak berlaku secara universal untuk semua deployment. Menurut vendor, kondisi tertentu harus terpenuhi agar serangan dapat berhasil, yakni ketika perangkat dikonfigurasi sebagai SAML Identity Provider atau SAML IDP. Artinya, organisasi yang menggunakan NetScaler untuk mengelola autentikasi berbasis SAML menjadi target yang paling relevan dalam skenario ini.

Indikasi awal bahwa kerentanan ini sedang “dipanaskan” oleh aktor ancaman datang dari pengamatan yang dilakukan oleh Defused Cyber. Dalam publikasinya, mereka mengungkap adanya aktivitas fingerprinting metode autentikasi terhadap endpoint tertentu, khususnya path /cgi/GetAuthMethods. Endpoint ini digunakan oleh sistem untuk menampilkan metode autentikasi yang tersedia, dan dalam konteks serangan, dapat dimanfaatkan untuk mengidentifikasi konfigurasi target.

Dengan kata lain, penyerang tidak langsung mengeksploitasi celah, tetapi terlebih dahulu melakukan pemetaan terhadap sistem yang rentan. Teknik ini dikenal sebagai reconnaissance, tahap awal dalam siklus serangan siber yang bertujuan mengumpulkan informasi sebelum melancarkan eksploitasi aktif. Aktivitas tersebut terdeteksi pada infrastruktur honeypot yang dikendalikan oleh peneliti, menunjukkan bahwa scanning telah terjadi secara luas dan sistematis.

Temuan ini diperkuat oleh laporan dari watchTowr, yang juga mengamati pola serupa dalam jaringan honeypot mereka. Mereka menilai bahwa aktivitas ini merupakan indikator kuat bahwa eksploitasi di dunia nyata hanya tinggal menunggu waktu. Dalam banyak kasus sebelumnya, fase reconnaissance seperti ini seringkali menjadi pendahulu dari serangan berskala besar.

watchTowr menekankan urgensi respons dengan peringatan yang cukup tegas. Mereka menyebut bahwa organisasi yang menjalankan versi rentan dari NetScaler dalam konfigurasi terdampak harus segera menghentikan aktivitas lain dan memprioritaskan patching. Penundaan, dalam konteks ini, dapat mempersempit jendela mitigasi hingga akhirnya tidak lagi tersedia ketika eksploitasi mulai berlangsung secara aktif.

Versi yang terdampak mencakup NetScaler ADC dan Gateway versi 14.1 sebelum build 14.1-66.59 serta versi 13.1 sebelum 13.1-62.23. Selain itu, varian khusus seperti NetScaler ADC 13.1-FIPS dan 13.1-NDcPP juga termasuk dalam cakupan risiko jika belum diperbarui ke versi 13.1-37.262 atau yang lebih baru. Informasi ini penting karena banyak organisasi cenderung menjalankan versi lama untuk stabilitas, tanpa menyadari implikasi keamanannya.

Kasus ini bukan yang pertama bagi ekosistem NetScaler. Dalam beberapa tahun terakhir, sejumlah kerentanan serius pada produk ini telah dieksploitasi secara aktif oleh berbagai kelompok ancaman. Salah satu yang paling dikenal adalah CVE-2023-4966 atau yang populer disebut Citrix Bleed, yang memungkinkan pencurian sesi autentikasi. Kerentanan lain seperti CVE-2025-5777 yang dijuluki Citrix Bleed 2, serta CVE-2025-6543 dan CVE-2025-7775, juga menunjukkan pola serupa: celah kritis yang dengan cepat beralih dari disclosure ke eksploitasi massal.

Polanya konsisten. Begitu detail teknis kerentanan dipublikasikan atau dapat direkonstruksi oleh penyerang, aktivitas scanning meningkat drastis, diikuti dengan eksploitasi oportunistik terhadap sistem yang belum ditambal. Dalam konteks CVE-2026-3055, tanda-tanda awal dari fase ini sudah terlihat jelas melalui aktivitas fingerprinting yang terdeteksi.

Dari perspektif operasional keamanan, situasi ini memperlihatkan pentingnya visibilitas terhadap aset yang terekspos. Banyak organisasi tidak sepenuhnya menyadari bahwa mereka menjalankan konfigurasi SAML IDP pada NetScaler, atau tidak memiliki inventarisasi yang akurat terhadap versi perangkat lunak yang digunakan. Hal ini menciptakan blind spot yang dapat dimanfaatkan oleh penyerang.

Selain itu, kerentanan berbasis memory overread memiliki karakteristik yang sering kali sulit dideteksi melalui mekanisme logging konvensional. Tidak seperti eksploitasi yang menyebabkan crash atau perubahan sistem yang mencolok, kebocoran memori dapat terjadi secara diam-diam, meninggalkan jejak minimal namun berdampak besar.

Kondisi ini memperkuat argumen bahwa patching bukan sekadar praktik terbaik, melainkan kebutuhan mendesak dalam manajemen risiko. Ketika vendor telah merilis pembaruan yang mengatasi celah kritis, jeda antara disclosure dan implementasi patch menjadi faktor penentu dalam menentukan apakah suatu organisasi akan menjadi korban.

Dalam kasus CVE-2026-3055, dinamika ancamannya sudah memasuki tahap yang tidak bisa diabaikan. Aktivitas reconnaissance yang terdeteksi menunjukkan bahwa aktor ancaman sedang aktif mengidentifikasi target potensial. Jika mengikuti pola historis eksploitasi NetScaler, fase berikutnya kemungkinan besar adalah penyalahgunaan celah secara langsung terhadap sistem yang belum diperbarui.

Dengan latar belakang ini, respons cepat menjadi satu-satunya pendekatan rasional. Tidak ada indikasi bahwa aktivitas scanning akan melambat, dan tidak ada jaminan bahwa eksploitasi belum dimulaai secara terbatas. Bagi organisasi yang bergantung pada NetScaler sebagai bagian dari infrastruktur kritis mereka, pertanyaan yang relevan bukan lagi apakah mereka akan menjadi target, melainkan kapan.

Bug “Open Sesame” di Open VSX Buka Celah Publikasi Ekstensi VS Code Berbahaya Tanpa Terdeteksi

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.