Peretas Masukka Trojan ke Dalam Perpustakaan Kode yang Menggerakkan Sebagian Besar Internet – Apakah Tim Anda Terkena Dampaknya?

Baru-baru ini, serangan siber yang cukup mencolok terjadi di dunia pengembangan perangkat lunak. Seorang penyerang berhasil mencuri token akses npm milik @jasonsaayman, pemelihara utama dari Axios, yang merupakan pustaka klien HTTP paling populer di JavaScript. Token ini kemudian digunakan untuk menerbitkan dua versi berbahaya yang menginstal trojan akses jarak jauh lintas platform. Versi jahat ini ditujukan untuk macOS, Windows, dan Linux, dan hanya bertahan sekitar tiga jam di registry npm sebelum dihapus.

Axios mendapatkan lebih dari 100 juta unduhan setiap minggu dan dilaporkan digunakan dalam sekitar 80% dari lingkungan cloud dan kode, mulai dari front-end React hingga pipeline CI/CD dan fungsi serverless. Huntress, sebuah perusahaan keamanan siber, mendeteksi infeksi pertama hanya 89 detik setelah paket berbahaya aktif dan mengonfirmasi setidaknya 135 sistem yang terkena dampak selama jendela paparan tersebut.

Ini adalah kompromi rantai pasokan npm yang ketiga dalam tujuh bulan terakhir, dengan setiap insiden mengeksploitasi kredensial pemelihara. Menariknya, kali ini, targetnya telah menerapkan semua langkah pertahanan yang disarankan oleh komunitas keamanan.

1 Credential, 2 Cabang, 39 Menit

Pencuri berhasil mengambil alih akun npm @jasonsaayman dan mengubah email akun tersebut menjadi alamat ProtonMail anonim sebelum menerbitkan paket berbahaya melalui antarmuka baris perintah npm. Langkah ini membuat pipeline CI/CD GitHub proyek tersebut terlewatkan sepenuhnya.

Pencuri tidak menyentuh kode sumber Axios sama sekali. Sebaliknya, kedua cabang rilis hanya mendapatkan satu ketergantungan baru: plain-crypto-js@4.2.1. Paket ini tidak diimpor di bagian mana pun dari basis kode, dan keberadaannya hanya untuk menjalankan skrip pasca-instal yang menanamkan RAT lintas platform ke mesin pengembang.

Perencanaan serangan ini sangat terukur. Delapan belas jam sebelum rilis Axios, penyerang menerbitkan versi bersih dari plain-crypto-js melalui akun npm terpisah untuk membangun riwayat penerbitan dan menghindari deteksi pemindai paket baru. Kemudian muncul versi berbahaya 4.2.1. Dalam waktu 39 menit, kedua cabang rilis itu langsung aktif. Tiga payload spesifik untuk platform sudah dibangun sebelumnya. Malware ini menghapus dirinya sendiri setelah eksekusi dan mengganti dengan package.json yang bersih untuk menyulitkan inspeksi forensik.

StepSecurity, yang mengidentifikasi kompromi ini bersama Socket, menyebutnya sebagai salah satu serangan rantai pasokan yang paling canggih secara operasional yang pernah didokumentasikan terhadap paket npm top-10.

Pertahanan yang Ada di Atas Kertas

Axios memang melakukan langkah-langkah yang benar. Rilis 1.x yang sah dikirimkan melalui GitHub Actions menggunakan mekanisme OIDC Trusted Publisher dari npm, yang mengikat setiap penerbitan secara kriptografis dengan alur kerja CI/CD yang terverifikasi. Proyek ini juga memiliki pengakuan asal SLSA. Dari semua ukuran keamanan modern, stack keamanan ini terlihat solid.

Namun, semua itu tidak ada artinya. Huntress menggali lebih dalam ke dalam alur kerja penerbitan dan menemukan celah. Proyek ini masih melewatkan NPM_TOKEN sebagai variabel lingkungan bersamaan dengan kredensial OIDC. Ketika keduanya ada, npm secara default menggunakan token tersebut. Token klasik yang tahan lama ternyata menjadi metode otentikasi nyata untuk setiap penerbitan, terlepas dari bagaimana OIDC dikonfigurasikan. Penyerang tidak perlu mengalahkan OIDC; mereka cukup menghindarinya. Token legacy tersebut tetap ada sebagai jalur otentikasi paralel, dan hirarki npm sendiri lebih memilihnya secara diam-diam.

“Dari pengalaman saya di AWS, sangat umum bagi mekanisme otentikasi tua untuk tetap ada,” kata Merritt Baer, CSO di Enkrypt AI dan mantan Wakil CISO di AWS, dalam wawancara eksklusif. “Kontrol modern diterapkan, tetapi jika token lama atau kunci tidak dicabut, sistem dengan tenang lebih memilihnya. Seperti yang kita lihat pada kasus SolarWinds, di mana skrip lama melewati pemantauan yang lebih baru.”

Pemelihara tersebut mengungkapkan di GitHub setelah menemukan kompromi: “Saya berusaha mendapatkan dukungan untuk memahami bagaimana ini bisa terjadi. Saya sudah mengaktifkan 2FA/MFA di hampir semua yang saya gunakan.”

Endor Labs mendokumentasikan perbedaan forensik. Rilis sah axios@1.14.0 menunjukkan asal OIDC, catatan penerbitan terpercaya, dan gitHead yang menghubungkan ke commit tertentu. Sedangkan axios@1.14.1 yang jahat tidak memiliki salah satunya. Alat apa pun yang memeriksa asal pasti akan langsung mendeteksi celah tersebut. Namun, verifikasi asal bersifat opt-in. Tidak ada pintu gerbang registry yang menolak paket.

Tiga Serangan, Tujuh Bulan, Penyebab yang Sama

Saat ini, telah terjadi tiga kompromi rantai pasokan npm dalam tujuh bulan. Masing-masingnya berawal dengan kredensial pemelihara yang dicuri.

Worm Shai-Hulud menyerang pada September 2025. Sebuah akun pemelihara yang dipancing memberikan penyerang pijakan yang berkembang meluas ke lebih dari 500 paket, mengumpulkan token npm, kredensial cloud, dan rahasia GitHub saat menyerang. CISA mengeluarkan advisori, dan GitHub melakukan perombakan total terhadap model otentikasi npm sebagai respons.

Akhirnya, di Januari 2026, penelitian PackageGate dari Koi Security mengungkap enam kerentanan zero-day dalam npm, pnpm, vlt, dan Bun yang berhasil melewati pertahanan yang diadopsi ekosistem setelah serangan Shai-Hulud. Integritas lockfile dan pemblokiran skrip gagal dalam kondisi tertentu. Tiga dari empat manajer paket memperbaiki dalam hitungan minggu. npm menutup laporan tersebut.

Kini, dengan axios, token tahan lama yang dicuri berhasil menerbitkan RAT melalui kedua cabang rilis meskipun OIDC, SLSA, dan setiap langkah penguatan pasca-Shai-Hulud sudah diterapkan.

Setelah serangan Shai-Hulud, npm menerapkan reformasi nyata. Pembuatan token klasik baru dihapus, meskipun yang sudah ada masih ada sampai tenggat pencabutan yang ketat. FIDO 2FA menjadi wajib, token akses granular dibatasi hingga tujuh hari untuk penerbitan, dan penerbitan terpercaya melalui OIDC memberikan alternatif kriptografis untuk kredensial yang disimpan. Secara keseluruhan, perubahan tersebut memperkuat segala sesuatu di hilir akun pemelihara. Namun, yang tidak berubah adalah akun itu sendiri. Kredensial tetap menjadi titik kegagalan utama.

“Kompromi kredensial adalah tema berulang dalam pelanggaran npm,” kata Baer. “Ini bukan hanya masalah kata sandi yang lemah. Ini struktural. Tanpa kredensial sementara, penegakan MFA, atau lingkungan build dan penandatanganan yang terisolasi, akses pemelihara tetap menjadi titik lemah.”

Apa yang Dikirim npm vs. Apa yang Dilewati Serangan Ini

Apa yang Harus Dilakukan Sekarang di Perusahaan Anda

Pemimpin SOC di organisasi yang menjalankan Node.js harus menganggap ini sebagai insiden aktif hingga mereka memastikan sistem bersih. Jendela paparan selama tiga jam itu terjadi pada jam jam puncak pengembangan di seluruh zona waktu Asia-Pasifik, dan setiap pipeline CI/CD yang menjalankan npm install semalam dapat saja menarik versi yang terkompromi secara otomatis.

“Prioritas pertama adalah penilaian dampak: pembangunan dan konsumen hilir mana yang mengonsumsi paket yang terkompromi?” kata Baer. “Lalu tahanan, perbaikan, dan akhirnya, pelaporan yang transparan kepada pimpinan. Apa yang terjadi, apa yang terpapar, dan langkah-langkah pengendalian yang akan mencegah kejadian serupa. Pelajaran dari log4j dan event-stream menunjukkan bahwa kecepatan dan kejelasan sama pentingnya dengan perbaikan itu sendiri.”

• Periksa paparan. Cari lockfiles dan log CI untuk axios@1.14.1, axios@0.30.4, atau plain-crypto-js. Tetapkan ke axios@1.14.0 atau axios@0.30.3.

• Anggap terkompromi jika terkena. Rebuild mesin yang terdampak dari keadaan yang diketahui baik. Ganti semua kredensial yang dapat diakses: token npm, kunci AWS, kunci SSH, kredensial cloud, rahasia CI/CD, nilai .env.

• Blokir C2. Tambahkan sfrclak.com dan 142.11.206.73 ke dalam daftar blok DNS dan aturan firewall.

• Periksa artefak RAT. /Library/Caches/com.apple.act.mond di macOS. %PROGRAMDATA%\wt.exe di Windows. /tmp/ld.py di Linux. Jika ditemukan, lakukan rebuild penuh.

• Perkuat ke depan. Terapkan npm ci --ignore-scripts di CI/CD. Secara ketat memerlukan pemasangan lockfile saja. Menolak paket yang tidak memiliki asal dari proyek yang sebelumnya memilikinya. Lakukan audit apakah token legacy coexist dengan OIDC di alur kerja penerbitan Anda sendiri.

Celah Kredensial yang Belum Ditangani

Tiga serangan dalam tujuh bulan. Masing-masing beragam dalam eksekusi, tetapi identik dalam penyebab utama. Model keamanan npm masih menganggap akun pemelihara individual sebagai jangkar kepercayaan utama. Akun-akun ini tetap rentan terhadap pembajakan kredensial, terlepas dari seberapa banyak lapisan perlindungan yang ditambahkan di hilir.

“AI dapat mengenali paket berisiko, melakukan audit terhadap otentikasi legacy, dan mempercepat respons SOC,” kata Baer. “Tetapi manusia masih mengendalikan kredensial pemelihara. Kita mengurangi risiko, tetapi tidak menghilangkannya.”

Pengakuan asal yang wajib, di mana penerbitan manual CLI sepenuhnya dinonaktifkan, akan menangkap serangan ini sebelum mencapai registry. Begitu juga dengan penandatanganan multi-pihak yang diwajibkan, di mana tidak ada satu pemelihara yang dapat mendorong rilis sendirian. Keduanya saat ini tidak diterapkan. npm telah memberi sinyal bahwa menonaktifkan token secara default saat penerbitan terpercaya diaktifkan akan ada di peta jalan. Hingga saat itu, setiap proyek yang menjalankan OIDC bersamaan dengan token legacy memiliki titik buta yang sama dengan yang dialami oleh axios.

Pemelihara axios telah melakukan apa yang diminta oleh komunitas. Namun satu token legacy yang tidak disadari masih aktif justru menjadi faktor pengganggu semua upaya tersebut.