Worm Shai-Hulud di npm Menyebar ke Lebih dari 1.280 Paket

Bagaimana serangan dimulai?

Sekitar 09.00 UTC pada 4 Agustus 2026, penyerang menguasai akun GitHub Jared Wray, yang menggunakan nama pengguna jaredwray . Dengan akses tersebut, mereka mendorong kode berbahaya langsung ke cabang main repositori keyv, lalu menerbitkan rilis baru di seluruh keluarga paket keyv dan cacheable .

Gelombang awal mencakup 11 paket dalam dua namespace tersebut, antara lain keyv, cacheable-request, cache-manager, @cacheable/utils, flat-cache, dan file-entry-cache . Peneliti keamanan dari Aikido Security, StepSecurity—yang melacak malware ini dengan nama ChainDrop—Socket, dan Chainguard mengonfirmasi kompromi tersebut secara independen pada jam-jam pertama .

Payload berbahaya: setup.mjs dan Math_Symbol.js

Setiap paket yang telah diracuni mengikuti pola infeksi yang sama. Penyerang menambahkan dua berkas baru, yaitu setup.mjs dan Math_Symbol.js, serta menyisipkan entri berikut ke dalam package.json:

"preinstall": "node setup.mjs"

Ketika pengembang atau sistem CI menjalankan npm install, skrip preinstall tersebut berjalan otomatis sebelum proses instalasi selesai .

Berkas setup.mjs berfungsi sebagai dropper, yakni pemuat tahap awal. Skrip ini mengunduh biner runtime JavaScript Bun yang sah dari GitHub Releases, kemudian menggunakannya untuk menjalankan payload tahap kedua Math_Symbol.js, yang berukuran sekitar 710–728 KB dan telah disamarkan secara berat .

Microsoft Threat Intelligence mengonfirmasi bahwa payload ini merupakan varian Mini Shai-Hulud . Malware tersebut dirancang untuk mengumpulkan berbagai rahasia dari lingkungan pengembang dan CI/CD, termasuk :

• token autentikasi npm;
• GitHub Personal Access Token (PAT);
• kunci AWS;
• secret Kubernetes;
• token HashiCorp Vault;
• kunci Stripe;
• token Slack;
• kunci SSH;
• berkas Terraform state;
• kredensial Docker; dan
• konfigurasi VPN.

Mengapa worm ini bisa menyebar begitu cepat?

Bahaya terbesar serangan ini terletak pada kemampuan menyebarkan diri sendiri. Setelah mencuri token penerbitan npm dan GitHub PAT dari lingkungan yang terinfeksi, worm menggunakan akses tersebut untuk menerbitkan versi berbahaya pada paket lain yang dikelola pihak berbeda .

Jumlah paket terdampak meningkat dengan cepat:

• Dalam sekitar dua jam, StepSecurity melacak 435 paket dan 1.557 versi yang telah diracuni .
• Pada awal siang waktu CEST, Aikido Security menghitung 868 paket di 1.381 versi .
• Pada akhir hari, jumlahnya telah melampaui 1.280 paket dan 1.680 versi, menurut BleepingComputer dan sejumlah laporan lain .

Worm ini juga melintasi batas namespace. Penyebarannya tidak berhenti pada keluarga keyv dan cacheable, tetapi menjangkau paket milik pengelola yang tidak terkait langsung. Organisasi yang paketnya disebut dalam laporan antara lain Deliveroo, Ornikar, OneReach, Picsart, Qlik, dan ServiceTitan .

Ke mana kredensial curian dikirim?

Kredensial yang dicuri dieksfiltrasi ke repositori GitHub yang dikendalikan penyerang. Worm tersebut dapat membuat repositori baru atau menggunakan repositori khusus untuk menampung hasil pencurian .

Payload juga memiliki beberapa kanal eksfiltrasi cadangan, sehingga pengambilan satu kanal saja tidak serta-merta menghentikan seluruh aliran data .

Langkah pemulihan yang direkomendasikan

Peneliti keamanan menyarankan agar tim memperlakukan setiap sistem yang pernah menyentuh versi paket terdampak sebagai sistem yang berpotensi telah sepenuhnya terkompromi. Langkah yang disarankan meliputi hal-hal berikut .

1. Kunci atau kembalikan versi paket

Segera hapus versi yang terdampak dan gunakan versi yang telah diverifikasi bersih. Manfaatkan fitur overrides pada package.json, atau mekanisme setara di npm, Yarn, dan pnpm, untuk mencegah pemasangan ulang versi berbahaya secara tidak sengaja .

Periksa pula seluruh lockfile—package-lock.json, yarn.lock, dan pnpm-lock.yaml—termasuk dependensi transitif yang mungkin membawa versi terinfeksi .

2. Anggap host yang terdampak telah terkompromi

Jangan hanya menghapus berkas berbahaya dari komputer atau runner yang pernah menjalankan npm install pada versi terdampak . Asumsikan semua rahasia yang tersedia di host tersebut, termasuk variabel lingkungan dan kredensial yang tersimpan, mungkin telah dicuri.

3. Cabut dan buat ulang seluruh kredensial

Cabut, lalu buat ulang semua kredensial yang mungkin terekspos , termasuk:

• token npm, baik classic maupun granular;
• GitHub PAT dan token fine-grained;
• kunci AWS IAM dan access key;
• token akun layanan Kubernetes;
• token HashiCorp Vault;
• kunci Stripe;
• token Slack;
• kunci SSH;
• kredensial Docker; dan
• token VPN.

4. Hapus pemantau pencabutan token sebelum rotasi

Ini merupakan detail penting dalam proses pemulihan. Malware terkadang memasang GitHub workflow watcher yang dapat menangkap atau mengekspos kembali token baru segera setelah token tersebut dibuat .

Karena itu, peneliti menyarankan untuk menonaktifkan atau menghapus layanan pemantau dan mekanisme persistensi tersebut terlebih dahulu, baru kemudian melakukan rotasi kredensial .

5. Bersihkan cache dan bangun ulang dari awal

Bersihkan cache npm, pnpm, dan Yarn, serta cache build Docker, baik pada komputer pengembang maupun runner CI/CD .

Seluruh artefak sebaiknya dibangun ulang dari awal agar dependensi yang telah tercemar tidak bertahan di cache build atau lapisan Docker .

6. Audit GitHub dan lingkungan CI/CD

Periksa repositori yang baru dibuat, workflow yang tidak sah, commit mencurigakan, serta perubahan pada lingkungan pengembangan dan pipeline CI/CD . Peneliti juga menyarankan pemeriksaan terhadap berkas persistensi seperti .claude/settings.json dan .vscode/tasks.json yang mungkin dibuat oleh worm .

Pelajaran penting dari serangan ini

Serangan Shai-Hulud pada 4 Agustus 2026 menunjukkan bagaimana satu akun pengelola yang berhasil dibajak dapat menjadi titik awal kompromi berskala besar. Tanpa perlu menguasai seluruh paket sejak awal, penyerang dapat memanfaatkan token yang dicuri untuk menerbitkan malware ke paket milik pihak lain.

Penggunaan runtime Bun yang sah untuk mengeksekusi payload, kemampuan propagasi melalui token penerbitan, serta kanal eksfiltrasi berlapis membuat serangan ini lebih kompleks dibandingkan serangan rantai pasok sebelumnya .

Bagi tim engineering dan keamanan, insiden ini menegaskan pentingnya mengunci versi dependensi, membatasi skrip preinstall dan postinstall jika memungkinkan, memantau aktivitas GitHub yang tidak biasa, serta menyiapkan runbook respons insiden khusus untuk kompromi rantai pasok perangkat lunak.