Shai-Hulud Muncul Lagi: Lebih dari 300 Paket NPM Terinfeksi

 (helixguard.ai)
17 poin oleh GN⁺ 2025-11-25 | 5 komentar | Bagikan ke WhatsApp
  • Di registri NPM, lebih dari 1.000 komponen terinfeksi dengan pola yang sama dalam hitungan jam, lalu versi baru yang berisi kode berbahaya didistribusikan
  • Paket berbahaya menyamar sebagai skrip instalasi runtime Bun dengan menambahkan setup_bun.js dan bun_environment.js yang diobfuscate; saat dijalankan, ia menggunakan TruffleHog untuk mencuri kredensial lokal
  • Informasi sensitif yang dikumpulkan, seperti token AWS/GCP/Azure·GitHub·NPM, dikirim keluar melalui runner GitHub Action bernama SHA1HULUD
  • Skrip berbahaya secara otomatis menjalankan npm publish untuk melakukan replikasi diri berbentuk worm, yang pada akhirnya menginfeksi lebih dari 27.000 repositori GitHub
  • Kasus ini dinilai kembali menyoroti ancaman keamanan rantai pasok di seluruh ekosistem open source

Ringkasan serangan

  • Pada 24 November 2025, HelixGuard mendeteksi lebih dari 1.000 paket di registri NPM yang terinfeksi dengan teknik yang sama dalam beberapa jam
    • Versi baru tersebut menyamar seolah-olah menambahkan runtime Bun dan menyertakan skrip preinstall: node setup_bun.js
    • File bun_environment.js yang didistribusikan bersama merupakan kode berbahaya yang diobfuscate, yang saat dijalankan akan mengunduh dan mengeksekusi TruffleHog
  • TruffleHog memindai dan mencuri token NPM, kredensial AWS/GCP/Azure, variabel lingkungan, dan lainnya dari lingkungan lokal
  • Informasi yang dicuri dieksfiltrasi dengan membuat runner GitHub Action SHA1HULUD, lalu dikirim keluar melalui repositori GitHub dengan deskripsi Sha1-Hulud: The Second Coming.
  • HelixGuard mengindikasikan bahwa serangan ini kemungkinan dilakukan oleh pelaku yang sama dengan insiden “Shai-Hulud” pada September 2025

Analisis cara kerja malware

  • Dari analisis terhadap paket @asyncapi/specs, versi yang dipublikasikan ke NPM terbukti telah terinfeksi, sementara repositori sumber asli di GitHub tetap aman
  • Penyerang memodifikasi package.json untuk menambahkan setup_bun.js, lalu mengatur agar skrip tersebut memanggil bun_environment.js
  • bun_environment.js adalah file JavaScript yang sangat diobfuscate dengan ukuran lebih dari 10MB, dengan fungsi utama sebagai berikut
    • Mengumpulkan kredensial cloud dan token dari variabel lingkungan
    • Memindai secret key menggunakan TruffleHog
    • Mengeksfiltrasi data melalui GitHub Actions
  • Selain itu, package.json juga dimodifikasi untuk menyisipkan kode infeksi, lalu npm publish dijalankan otomatis guna melakukan penyebaran berbentuk worm

Infeksi GitHub dan eksfiltrasi data

  • Skrip berbahaya membuat file .github/workflows/formatter_123456789.yml dan mendaftarkan runner SHA1HULUD
  • Workflow tersebut mengemas secret repositori ke dalam file actionsSecrets.json yang dienkode Base64 ganda
  • Setelah itu, data diunggah dengan membuat repositori GitHub bernama acak yang memiliki deskripsi Sha1-Hulud: The Second Coming.
  • HelixGuard mengonfirmasi bahwa lebih dari 27.000 repositori GitHub telah terinfeksi
  • Informasi rahasia yang dicuri mencakup berbagai kredensial layanan seperti AWS_ACCESS_KEY_ID, SLACK_WEBHOOK_URL, CODECOV_TOKEN, WEBFLOW_TOKEN, dan lainnya

Daftar paket yang terinfeksi

  • HelixGuard melaporkan bahwa ratusan paket NPM telah terinfeksi
    • Contohnya mencakup paket dari organisasi besar seperti @asyncapi, @ensdomains, @posthog, @zapier, @postman, @voiceflow
    • Tiap paket memiliki banyak versi yang terinfeksi, misalnya @asyncapi/specs@6.8.2, @postman/csv-parse@4.0.5
  • Sebagian besar paket yang terinfeksi menyamar sebagai proyek open source normal, dengan kode berbahaya disisipkan dalam proses distribusi otomatis

Implikasi keamanan

  • Serangan ini merupakan contoh infeksi skala besar pada ekosistem open source dengan memanfaatkan kelemahan keamanan rantai pasok
  • Ini menunjukkan perlunya penguatan pengelolaan keamanan di seluruh infrastruktur pengembangan, termasuk NPM, GitHub, dan kredensial cloud
  • HelixGuard menyarankan untuk segera menghentikan instalasi paket yang terinfeksi dan segera mencabut token serta kredensial terkait

Bacaan terkait

5 komentar

 
ahwjdekf 2025-11-27

Ekosistem js memang benar-benar tempat sampah yang kacau balau.
 
developerjhp 2025-11-25

Saya sudah membuat skrip pemindai real-time.

Di path repositori yang dicurigai,
jalankan npx sha1-hulud-scanner.

Kode sumber: https://github.com/developerjhp/sha1-hulud-scanner
 
GN⁺ 2025-11-25
Komentar Hacker News

  • Berbagi satu tip: lebih baik pakai PNPM daripada NPM
    PNPM 10.x memblokir beberapa vektor serangan
    1️⃣ Secara default tidak menjalankan skrip post-install, dan perlu persetujuan manual
    2️⃣ Bisa diatur agar instalasi baru dilakukan setelah lewat jangka waktu tertentu sejak rilis baru dipublikasikan, misalnya 4 hari
    NPM terlalu rapuh untuk lingkungan CLI produksi
    Sebaiknya kunci publisher dibatasi dengan hak akses minimum, diikat hanya ke paket tertentu, dan IP-nya dibatasi ke runner CI/CD
    Jangan simpan kunci publikasi di lokal; bila perlu pertimbangkan OIDC Trusted Publisher atau akses berbasis token

    • NPM terasa seperti hasil dari utang teknis yang menumpuk terlalu banyak
      Hanya untuk lockfile saja sudah dicoba lima kali, tapi tetap belum sempurna
      Kalau melihat struktur dan riwayat commit-nya, timnya jelas bekerja keras untuk memperbaikinya, tapi terasa seperti memulai dari lubang yang terlalu dalam
      Sampai sekarang masih gagal mendeteksi EOF dini saat transfer file, dan meninggalkan file yang tidak lengkap di cache, jadi pada koneksi internet lambat banyak waktu terbuang karena pembaruan gagal
    • Saya lebih suka pendekatan manajemen rahasia dinamis dari HashiCorp Vault / OpenBao
      Awalnya memang rumit, tapi rahasia bisa dikelola dengan konsep lease
      Setiap build CI membuat lease, lalu otomatis dibuang saat selesai, dan juga mendukung TTL serta rotasi otomatis
      Hasilnya, kredensial jangka panjang bisa disembunyikan, dan token berumur pendek hanya diterbitkan pada saat build
      Sisi positif dari serangan seperti ini adalah diskusi keamanan yang benar-benar serius jadi lebih hidup di dalam perusahaan
    • Cukup pakai npm ci
      Karena hanya menginstal versi yang tercantum di package-lock.json, risikonya terhadap serangan akibat pembaruan otomatis bisa dikurangi
      Yang penting adalah membiasakan diri melakukan pembaruan yang disengaja saja
    • Di ekosistem Python, perlindungan serupa bisa didapat dengan opsi pip install --only-binary=:all:
      Ini memblokir distribusi source sepenuhnya dan hanya memasang wheel
      Tapi memang bisa menimbulkan keterbatasan versi
      Di uv, opsi --exclude-newer bisa dipakai untuk meniru fitur “masa rilis minimum” ala PNPM
    • Baru-baru ini saya membaca tulisan tentang “dependency cooldown”, dan sangat setuju
      Saya mengunci semua dependensi dan meninjau notifikasi dependabot secara manual
      Saya masih bertanya-tanya apakah ini berlebihan atau justru kebiasaan yang benar

  • Ada tulisan yang sangat relevan hari ini: “We should all be using dependency cooldowns”
    Pembaruan dependensi otomatis bisa lebih berbahaya daripada kerentanan satu hari
    Jauh lebih sulit membalikkan paket yang terinfeksi yang sudah menyebar ke ribuan lock file

    • Saya rasa lebih baik memperbarui hanya saat memang perlu
      Kalau semuanya berjalan baik, tidak ada alasan untuk menyentuhnya
    • Tapi bahkan begitu pun, tetap perlu ada orang lain yang memperbaiki bug, dan kalau semua orang memakai cooldown, akhirnya bisa jadi tidak banyak kemajuan
    • Di uv untuk Python, efek serupa bisa didapat dengan perintah uv lock --exclude-newer $(date --iso -d "24 hours ago")
      Ada diskusi terkait di issue #14992
    • Dengan npm-check-updates juga bisa dilakukan dengan mudah
      Perintah npx npm-check-updates -c 7 bisa mengatur cooldown 7 hari
      Lihat dokumentasi npm-check-updates
    • Saya tidak setuju dengan logika ini
      Cooldown bisa memperpanjang waktu penyebaran kerentanan 0-day
      Kalau semua orang memakai cooldown yang sama, yang terjadi hanya keterlambatan penemuan

  • Saya adalah co-founder PostHog
    Kami termasuk korban serangan ini
    Versi yang terinfeksi adalah posthog-node 4.18.1, 5.13.3, 5.11.3 / posthog-js 1.297.3 / posthog-react-native 4.11.1 / posthog-docusaurus 2.0.6
    Kami sudah mengganti semua kunci dan kata sandi, lalu merilis versi baru
    Kami sedang menganalisis penyebabnya dan akan memberi pembaruan di status.posthog.com

    • Saya sarankan menyiapkan alarm bila rilis paket baru tidak terkait dengan eksekusi CI/CD
    • Saya penasaran apakah JS yang terinfeksi benar-benar berdampak pada pengguna nyata
      Jika situs web menyajikan versi yang terinfeksi, saya ingin tahu apakah pengunjung ikut terdampak
    • Jika penyebabnya belum diketahui, mungkin saja serangannya masih menyebar
    • Versi terbaru juga bisa saja terinfeksi lagi, jadi saya bertanya-tanya kenapa orang harus percaya kali ini
    • Syukurlah pembaruan di sini lebih mudah terlihat daripada pengumuman di Twitter. Semoga pemulihannya lancar

  • Pertanyaan serius: apakah masuk akal memulai proyek baru dengan Node
    Saya sedang membuat frontend SaaS dengan Astro, dan setiap kali memperbarui dependensi rasanya cemas
    Kurangnya keamanan di ekosistem npm terasa terlalu parah

    • Masalahnya bukan Node atau JS, melainkan model packaging-nya
      Ekosistem seperti Rust yang juga bergantung pada banyak subpaket suatu hari akan mengalami hal yang sama
      Tidak punya package manager seperti C, C++, atau Odin mungkin justru pilihan yang lebih bijak dari sisi keamanan
    • Menurut saya ini lebih merupakan masalah npm itu sendiri daripada Node
      Belakangan ini saya lebih percaya pada JSR milik Deno
      Paket berbasis JSR juga didistribusikan silang ke npm, dan ada pula paket khusus Deno
      Misalnya Lume memberi kesan sebagai SSG yang lambat tetapi stabil
    • Ini bukan masalah khusus Node
      npm hanyalah repositori terbesar, jadi dari sudut pandang penyerang nilainya lebih tinggi
      Hal yang sama sangat mungkin terjadi di RubyGems atau Cargo
    • Pendapat bahwa Node harus dihindari itu berlebihan
      Hanya karena ini ekosistem yang paling banyak dipakai, serangannya jadi terkonsentrasi di sini
      Cukup kelola dependensi dengan hati-hati dan jangan memperbarui setiap hari
    • Kami membangun platform analisis keamanan produk kami dengan PHP
      Keuntungannya adalah rendering halaman tidak membutuhkan lebih dari 100 dependensi
      Lihat tautan proyek

  • Sekarang saya melakukan semua pengembangan hanya di dalam kontainer Podman
    Kode yang belum saya baca pasti dijalankan di lingkungan terisolasi
    Ini memang tidak sempurna, tapi menurut saya setidaknya merupakan kebiasaan keamanan dasar

    • Kebanyakan orang tidak pernah bermasalah dalam 99,99% kasus, jadi rasa waspadanya tumpul
      Keamanan biasanya adalah bidang yang didelegasikan ke para ahli, jadi secara realistis sulit diubah
    • Pohon dependensi npm terlalu dalam; saya penasaran bagaimana isolasi kontainer bekerja dalam kasus seperti ini
    • Saya ingin tahu cara konkret menangani paket npm seperti SDK PostHog di dalam kontainer
    • Podman lebih aman daripada Docker, dan bila perlu isolasi tambahan seperti QEMU juga layak dipertimbangkan
    • Saya bahkan masuk lewat SSH sebagai pengguna lokal yang berbeda lalu mengembangkan dengan tmux

  • Dua belas tahun lalu NPM pernah down total sekali
    Waktu itu masih proyek open source biasa, tapi sekarang dimiliki Microsoft
    Kalau sudah dimiliki salah satu perusahaan terbesar di dunia, bukankah masalah seperti ini seharusnya bisa diselesaikan?
    Tapi sampai sekarang tampaknya tidak banyak yang berubah

    • MS bahkan tidak bisa mengelola Windows dengan baik
      Hal yang tidak menghasilkan uang lewat lisensi enterprise dibiarkan begitu saja
      Karena itu Windows 11 terasa seperti sekadar tumpukan pemasaran

  • Kami sedang memantau aktivitas serangan saat ini, dan memperbarui daftar paket yang terinfeksi di blog Wiz
    Kami sedang merekayasa balik payload berbahaya tersebut, dan berencana membagikan hasilnya dalam beberapa jam ke depan

  • Fitur chat “Talk to a human” milik PostHog ternyata hanya memberi respons robot, jadi terasa menyebalkan
    Tautan dukungan darurat juga tidak memberi arahan yang jelas
    Jadi saya ingin bertanya — versi mana yang harus dihindari?

    • Saya co-founder. Sudah kami umumkan di thread utama dan di status.posthog.com
      Versi yang terinfeksi adalah posthog-node 4.18.1, 5.13.3, 5.11.3 / posthog-js 1.297.3 / posthog-react-native 4.11.1 / posthog-docusaurus 2.0.6
      Aman jika diperbarui ke versi terbaru
    • Saya juga menerima daftar versi yang sama lewat kanal Slack

  • Saya penasaran kenapa kekacauan paket seperti ini selalu terjadi di ekosistem Node
    Saya tidak mengerti kenapa komunitas ini menganggap hook instalasi yang rumit dan pembaruan otomatis sebagai rekayasa yang baik
    Saya jadi paham kenapa pencipta Node sudah pergi sejak lama

    • Node seperti PHP versi baru
      Ekosistem raksasa, didominasi developer pemula, kesadaran keamanan rendah, dan bahkan fitur kecil pun bergantung pada library
    • Ekosistem yang serius seharusnya punya maintainer paket
      Seperti Debian, harus ada pengelola tepercaya yang memverifikasi, tetapi komunitas JS menolak ini sebagai gatekeeping
      Karena itu kejadian seperti ini terus berulang
    • Merendahkan orang lain hanya memberi rasa unggul sesaat
      Dengan sikap seperti itu, tidak ada yang akan berubah

  • Sedikit di luar topik, tapi saya penasaran siapa sebenarnya HelixGuard
    Situs webnya berantakan dan hampir tidak ada informasinya
    Katanya pelanggannya adalah bursa kripto, jadi terasa agak mencurigakan

    • Menurut akun X (Twitter)-nya, mereka berbasis di Singapura/Jepang
      Akun X HelixGuard
 
laeyoung 2025-11-25

2️⃣ Bisa diatur agar instalasi baru dilakukan setelah jangka waktu tertentu berlalu sejak rilis baru didistribusikan (misalnya: 4 hari)

Fitur yang sangat bagus. Google juga kadang mengunggah versi yang bermasalah karena bug ke NPM, jadi ada saat-saat saya panik sambil bertanya-tanya apakah ini bug di pihak saya.