CompileDaily
Coding

Celah SlugFest Ancam 1.500 Paket npm, GitHub Batasi Trusted Publishing Jadi 48 Jam

Admin CompileDaily ·
Bagikan WhatsApp X Facebook Threads

Trusted Publishing diperkenalkan untuk menghapus risiko token rahasia yang bocor. Ironisnya, celah terbarunya tidak butuh mencuri apa pun: cukup sebuah nama repositori yang sudah ditinggalkan pemiliknya.

Peneliti Bloom Security mengungkap celah bernama SlugFest di fitur Trusted Publishing npm yang membuat lebih dari 1.500 paket berisiko dibajak. Paket-paket tersebut secara kolektif sudah diunduh lebih dari 10 juta kali. Detail celah ini dipublikasikan sejumlah media keamanan pada Selasa (13/10/2026), sementara perbaikan GitHub, pemilik npm, tercantum dalam changelog bertanggal 2 Oktober 2026. Ancaman rantai pasok di npm bukan hal baru, seperti terlihat saat worm Shai-Hulud menyerang ribuan versi paket.

Kunci yang Mengecek Alamat, Bukan Pemilik Rumah

Trusted Publishing memungkinkan sistem CI/CD seperti GitHub Actions menerbitkan paket npm memakai token OIDC berumur pendek, tanpa menyimpan token rahasia jangka panjang. Pengelola paket cukup mengikat paketnya ke repositori GitHub dan berkas workflow tertentu.

Masalahnya, npm mencatat repositori tersebut berdasarkan slug atau nama "pemilik/repositori", bukan ID numerik permanen yang sebenarnya sudah ikut terkirim di token OIDC GitHub. Menurut The Hacker News, npm baru memakai ID numerik itu setelah paket berhasil diterbitkan pertama kali dari repositori tersebut.

Peneliti keamanan Bloom Security, Golan Myers, menegaskan bahwa serangan ini tidak memerlukan pengetahuan orang dalam, pencurian kredensial, maupun race condition.

Empat Langkah Membajak Paket

Begitu sebuah repositori diganti nama, dipindahkan, atau dihapus, slug lamanya bisa diklaim orang lain. Penyerang cukup membuat repositori baru dengan nama yang sama, menambahkan workflow publikasi npm, lalu menukarkan token OIDC hasil workflow itu ke npm. Karena slug-nya cocok, npm menerbitkan kredensial publikasi.

Dengan kredensial itu, penyerang bisa merilis versi berbahaya dari paket korban dan mewarisi nama, reputasi, serta jumlah unduhannya. Rilis palsu tersebut tetap membawa atestasi provenance (catatan build bertanda tangan) yang sah, hanya saja menyebut repositori penyerang, seperti dirinci Help Net Security.

Ancaman terbesarnya ada pada skrip postinstall, yang dijalankan npm secara otomatis di setiap mesin yang memasang paket.

Lihat Layanan Kami

Agen AI Memperbesar Dampak

Bloom Security menyoroti peran agen AI dalam rantai pasok perangkat lunak. Menurut perkiraan mereka, agen AI di komputer biasa memasang sekitar 70 paket per bulan, dan hampir 350 paket di mesin pengembang, belum termasuk dependensinya.

"Agen AI mengubah permainan. Pengembang bukan lagi satu-satunya konsumen perangkat lunak pengembang," kata Myers. Agen AI tidak selalu memeriksa asal sebuah paket, sehingga versi berbahaya berpeluang terpasang tanpa campur tangan manusia.

Laporan Juni, Perbaikan Oktober

Bloom melaporkan celah ini ke GitHub pada 6 Juni 2026. Menurut Bloom, balasan terakhir GitHub datang pada 8 Juli 2026, dan enam tindak lanjut setelahnya tidak dijawab.

Perbaikan yang kini berlaku: konfigurasi Trusted Publishing yang belum tervalidasi kedaluwarsa 48 jam setelah dibuat. Konfigurasi dikecualikan dari batas waktu itu setelah publikasi pertama berhasil.

Dalam tanggapannya, Myers mengatakan seluruh paket yang dianggap rentan berkaitan dengan slug yang bisa diklaim ulang. Bloom tidak merilis daftar paket yang terdampak, sehingga pengguna tidak bisa mencocokkan dependensinya dengan daftar tertentu.

Yang Perlu Dilakukan Pengelola Paket

Bloom menyarankan pengelola menjalankan npm trust list dan memastikan setiap repositori yang tercantum masih berada di bawah kendali mereka. Ikatan yang menunjuk ke repositori yang sudah diganti nama atau dipindahkan sebaiknya dihapus lalu dibuat ulang, dan ikatan harus dihapus sebelum repositorinya dihapus. Pengguna paket juga disarankan memeriksa apakah atestasi provenance menyebut repositori yang semestinya.

Bloom menyebut integrasi Trusted Publishing npm dengan GitLab punya kelemahan serupa. GitHub belum menjelaskan apakah konfigurasi lama yang sudah pernah dipakai menerbitkan paket ikut diikat ulang ke ID permanen, dan jawaban atas pertanyaan itu akan menentukan seberapa tuntas celah SlugFest benar-benar tertutup.

Komentar (0)

Masuk untuk menulis komentar.

Belum ada komentar.

Kami memakai cookie untuk analisis kunjungan. Baca Kebijakan Privasi kami.