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
. 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
.png)