Analisis pascainsiden: kompromi rantai pasok npm TanStack

(tanstack.com)

1 poin oleh GN⁺ 2 jam lalu | 1 komentar | Bagikan ke WhatsApp

Pada 2026-05-11 19:20~19:26 UTC, penyerang menerbitkan 84 versi berbahaya di 42 paket npm @tanstack/
Rantai serangan menggabungkan “Pwn Request” pull_request_target, peracunan cache GitHub Actions, dan ekstraksi token OIDC dari memori runner
Token npm dan workflow publish tidak dicuri atau dikompromikan, dan malware melakukan POST langsung ke registry dengan hak OIDC trusted publisher
Jika versi terdampak terpasang, kredensial AWS, GCP, Kubernetes, Vault, GitHub, npm, dan SSH mungkin terekspos sehingga perlu diganti
Semua versi terdampak sudah ditandai deprecated, penghapusan tarball bersama npm security telah dilakukan, dan issue pelacakan serta GitHub Security Advisory telah dipublikasikan

Ringkasan insiden

Antara 2026-05-11 19:20~19:26 UTC, penyerang menerbitkan 84 versi berbahaya di 42 paket npm @tanstack/*
Rantai serangan menggabungkan pola pull_request_target “Pwn Request”, peracunan cache GitHub Actions yang melintasi batas kepercayaan fork↔base, dan ekstraksi token OIDC dari memori proses runner GitHub Actions
Dipastikan token npm tidak dicuri, dan workflow npm publish itu sendiri juga tidak dikompromikan
Versi berbahaya terdeteksi secara publik dalam 20 menit oleh peneliti eksternal ashishkurmi dari stepsecurity
Semua versi terdampak sudah ditandai deprecated, dan penghapusan tarball dari registry sedang dilakukan bersama npm security
Pengguna yang memasang versi terdampak pada 2026-05-11 harus mengganti kredensial AWS, GCP, Kubernetes, Vault, GitHub, npm, dan SSH yang dapat diakses dari host instalasi
Issue pelacakan adalah TanStack/router#7383, dan GitHub Security Advisory adalah GHSA-g7cv-rxg3-hmpx

Cakupan dampak

Paket yang terdampak
- Cakupan dampak mencakup 42 paket dan 84 versi, dengan 2 versi per paket diterbitkan dalam selang sekitar 6 menit
- Daftar lengkap disertakan dalam issue pelacakan
- Lini produk yang telah dikonfirmasi tidak terdampak adalah @tanstack/query*, @tanstack/table*, @tanstack/form*, @tanstack/virtual*, @tanstack/store, dan meta package @tanstack/start
- @tanstack/start-* tidak termasuk dalam daftar yang telah dikonfirmasi tidak terdampak
Perilaku malware
- Ketika lingkungan developer atau CI menjalankan npm install, pnpm install, atau yarn install terhadap versi terdampak, npm akan memproses entri optionalDependencies berbahaya dan mengambil orphan payload commit dari fork network
- Setelah itu, skrip lifecycle prepare dijalankan, dan router_init.js yang diobfuskasi berukuran sekitar 2.3MB yang disembunyikan di dalam tarball terdampak akan berjalan
- Skrip berbahaya mengumpulkan kredensial dari lokasi umum seperti AWS IMDS/Secrets Manager, metadata GCP, token service-account Kubernetes, token Vault, ~/.npmrc, token GitHub, CLI gh, .git-credentials, SSH private key, dan lainnya
- Data yang dicuri dieksfiltrasi melalui jaringan unggah file Session/Oxen messenger, dengan target filev2.getsession.org, seed{1,2,3}.getsession.org
- Karena jaringan tersebut terenkripsi end-to-end dan tidak memiliki C2 yang dikendalikan penyerang, mitigasi jaringan hanya berupa pemblokiran IP/domain
- Logika propagasi mandiri mencantumkan paket lain yang dikelola korban melalui registry.npmjs.org/-/v1/search?text=maintainer:<user> lalu menerbitkannya ulang dengan metode injeksi yang sama
- Karena payload dijalankan sebagai bagian dari lifecycle npm install, host yang memasang versi terdampak pada 2026-05-11 harus dianggap berpotensi telah dikompromikan

Linimasa

Sebelum serangan: tahap peracunan cache
- Pada 2026-05-10 17:16 UTC, penyerang membuat github.com/zblgg/configuration, sebuah fork dari TanStack/router, lalu mengganti namanya untuk menghindari pencarian daftar fork
- Pada 2026-05-10 23:29 UTC, commit berbahaya 65bf499d16a5e8d25ba95d69ec9790a6dd4a1f14 dibuat di fork tersebut dengan identitas yang dimanipulasi claude <claude@users.noreply.github.com>
- Commit itu menambahkan packages/history/vite_setup.mjs, payload JS bundle sekitar 30.000 baris, dan menambahkan [skip ci] pada pesan commit untuk menekan CI pada event push
- Sekitar 2026-05-11 10:49 UTC, zblgg membuka PR #7378 ke main TanStack/router dengan judul “WIP: simplify history build”
- bundle-size.yml dan labeler.yml sama-sama berjalan otomatis untuk PR melalui pull_request_target, dan karena pull_request_target melewati gate persetujuan kontributor pertama, tidak diperlukan persetujuan terpisah
- pr.yml yang menggunakan pull_request diblokir dalam status menunggu persetujuan dan tidak dijalankan
- Pada 2026-05-11 11:01~11:11 UTC, zblgg melakukan force-push beberapa kali ke head PR, memicu eksekusi pull_request_target tambahan
- Pada 2026-05-11 11:11 UTC, commit berbahaya 65bf499d masuk ke head PR, lalu job benchmark-pr dari bundle-size.yml melakukan checkout refs/pull/7378/merge dan menjalankan pnpm install serta pnpm nx run @benchmarks/bundle-size:build, yang mengeksekusi vite_setup.mjs
- Pada 2026-05-11 11:29 UTC, cache GitHub Actions sebesar 1,1 GB bernama Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11 disimpan ke TanStack/router
- Cache ini disimpan dalam scope refs/heads/main dan dikonfigurasi agar cocok dengan key yang akan diambil release.yml pada push main berikutnya
- Pada 2026-05-11 11:31 UTC, penyerang mengembalikan PR ke b1c061af, HEAD main saat itu, sehingga PR yang terlihat tampak seperti no-op 0-file, lalu pada menit yang sama menutup PR dan menghapus branch, tetapi cache yang tercemar tetap ada
Pemicu: tahap publikasi
- Pada 2026-05-11 19:15 UTC, Manuel me-merge PR #7369 sehingga terjadi push ke main, dan workflow run 25613093674 dari release.yml dimulai pada 19:15:44 lalu gagal
- Pada 2026-05-11 19:20:39 UTC, npm registry menerima publikasi @tanstack/history@1.161.9 dan 41 package saudara
- Secara keseluruhan, sekitar 84 versi diterbitkan di 42 package, tetapi yang terlihat pada detik ini hanya sekitar separuhnya, sementara sisanya diterbitkan pada run kedua
- Autentikasi publish dilakukan melalui OIDC trusted-publisher binding untuk TanStack/router release.yml@refs/heads/main, tetapi itu bukan terjadi dari step Publish Packages pada workflow yang dilewati karena kegagalan pengujian
- Penerbit sebenarnya adalah malware yang dijalankan pada tahap pengujian/pembersihan, yang mencetak token OIDC dengan izin id-token: write lalu melakukan POST langsung ke registry.npmjs.org
- Pada 2026-05-11 19:20:47 UTC, run 25613093674 selesai dengan status failure
- Pada 2026-05-11 19:16 UTC, Manuel me-merge PR #7382 sehingga terjadi push main kedua, dan workflow run 25691781302 dimulai pada 19:16:22
- Run kedua juga me-restore cache tercemar yang sama, dan pada 2026-05-11 19:26:14 UTC, set versi kedua per package seperti @tanstack/history@1.161.12 diterbitkan melalui mekanisme OIDC yang sama
- Pada 2026-05-11 19:26:20 UTC, run 25691781302 juga selesai dengan status failure
Deteksi dan respons
- Sekitar 2026-05-11 19:50 UTC, peneliti eksternal carlini membuka issue #7383 yang menyertakan fingerprint optionalDependencies berbahaya dan daftar package
- Daftar awal mencakup 14 dari 42 package, dan peneliti juga memberi tahu npm security secara langsung
- Sekitar 2026-05-11 20:00 UTC, Manuel mengonfirmasi insiden di #7383 dan mulai merespons
- Sekitar 2026-05-11 20:10 UTC, Manuel mencabut izin push GitHub anggota tim lain sebagai antisipasi kemungkinan kompromi pada mesin pengguna
- Sekitar 2026-05-11 20:30 UTC, Tanner mengirim daftar IOC lengkap dan permintaan penghapusan tarball sisi registry ke security@npmjs.com, lalu mengajukan laporan malware resmi melalui npm
- Sekitar 2026-05-11 21:00 UTC, pemindaian penuh terhadap 295 package @tanstack/* mengonfirmasi cakupan 42 package dan 84 versi
- Tanner mulai melakukan deprecation npm untuk seluruh 84 package terdampak, dan @tan_stack serta para maintainer menyampaikan pemberitahuan publik di Twitter/X, LinkedIn, dan Bluesky
- Pada 2026-05-11 21:30 UTC, vektor peracunan cache pull_request_target pada bundle-size.yml dan fork zblgg/configuration teridentifikasi
- Semua entri cache untuk seluruh repository GitHub TanStack/* dihapus melalui API
- PR hardening di-merge, bundle-size.yml dikonfigurasi ulang, guard repository_owner ditambahkan, dan ref action pihak ketiga dipatok ke SHA
- GitHub Security Advisory resmi dipublikasikan dan CVE diminta

Akar masalah

Kombinasi tiga kerentanan
- Serangan ini membutuhkan ketiga kerentanan sekaligus, dan tidak ada satu pun yang cukup bila berdiri sendiri
- Kode fork PR mengalir ke cache base repository, lalu cache base repository mengalir ke runtime release workflow, dan runtime release workflow terhubung ke izin tulis npm registry, sehingga tiap kerentanan saling menghubungkan batas kepercayaan satu sama lain
Pola pull_request_target “Pwn Request”
- bundle-size.yml dijalankan dengan pull_request_target untuk fork PR, lalu dalam trigger context tersebut melakukan checkout ke PR merge ref milik fork dan menjalankan build
- Struktur intinya adalah sebagai berikut
```
on:
  pull_request_target:
    paths: ['packages/**', 'benchmarks/**']

jobs:
  benchmark-pr:
    steps:
      - uses: actions/checkout@v6.0.2
        with:
          ref: refs/pull/${{ github.event.pull_request.number }}/merge # fork's merged code

      - uses: TanStack/config/.github/setup@main # transitively calls actions/cache@v5

      - run: pnpm nx run @benchmarks/bundle-size:build # executes fork-controlled code
```
- Penulis workflow berusaha memisahkan job comment-pr dan benchmark-pr untuk membagi batas kepercayaan, dan komentar YAML menyebutkan niat untuk menjaga benchmark-pr sebagai “untrusted with read-only permissions”
- Namun, penyimpanan post-job dari actions/cache@v5 tidak bisa diblokir dengan permissions:, dan penulisan cache tidak menggunakan workflow GITHUB_TOKEN melainkan token internal runner
- Karena itu, pengaturan permissions: contents: read tidak dapat mencegah mutasi cache
- Scope cache berada di tingkat repository, dan run pull_request_target yang memakai scope cache base repository dibagikan bersama push ke main
- PR yang berjalan dalam scope cache base repository karena itu dapat mencemari entri cache yang nanti akan di-restore oleh workflow produksi di main
Peracunan cache GitHub Actions
- vite_setup.mjs berbahaya dirancang untuk menulis data agar cocok dengan key pnpm-store yang akan dihitung dan dicari oleh workflow release.yml yang sah
- Key target berbentuk Linux-pnpm-store-${hashFiles('**/pnpm-lock.yaml')}
- Saat job benchmark-pr berakhir, post-step actions/cache@v5 menyimpan pnpm store yang telah tercemar tepat dengan key tersebut
- Setelah itu, ketika release.yml berjalan pada push ke main, step Setup Tools me-restore entri tercemar itu sesuai rancangan serangan
- Jenis serangan ini termasuk keluarga GitHub Actions cache poisoning yang didokumentasikan oleh Adnan Khan pada 2024, dan bukan bug yang terbatas pada TanStack, melainkan isu desain GitHub Actions yang memerlukan mitigasi sadar
Ekstraksi token OIDC dari memori runner
- release.yml secara sah mendeklarasikan id-token: write karena diperlukan untuk npm OIDC trusted publishing
- Ketika pnpm store yang telah tercemar di-restore ke runner, binary yang dikendalikan penyerang akan ada di disk dan dipanggil pada step build
- Binary tersebut mencari proses GitHub Actions Runner.Worker melalui /proc/*/cmdline, lalu membaca /proc/<pid>/maps dan /proc/<pid>/mem untuk membuang memori worker
- Setelah itu, token OIDC yang di-mint secara lazy oleh runner dalam konfigurasi id-token: write diekstrak dari memori
- Dengan token yang diekstrak itu, penyerang mengautentikasi permintaan POST langsung ke registry.npmjs.org, sepenuhnya melewati step Publish Packages milik workflow
- Metode ekstraksi memori ini sama dengan yang dipakai dalam kompromi tj-actions/changed-files pada Maret 2025, dan script Python identik dengan komentar atribusi yang sama ikut digunakan
- Penyerang tidak menemukan teknik baru, melainkan merangkai ulang riset publik
Mengapa tiap elemen tidak cukup bila berdiri sendiri
- pull_request_target sendiri masih bisa dipakai untuk pekerjaan tepercaya seperti label atau comment
- Cache poisoning di dalam dependency yang sudah terkompromi saja tetap memerlukan kendaraan publish terpisah
- Ekstraksi token OIDC saja tetap memerlukan code execution yang sudah ada di runner

Deteksi dan IOC

Jalur deteksi
- Deteksi datang dari luar, bukan dari internal
- carlini membuka issue #7383 sekitar 20 menit setelah publish dan memberikan analisis teknis lengkap
- Tanner menerima telepon dari Socket.dev yang mengonfirmasi situasi sesaat setelah memulai war room
Fingerprint untuk maintainer downstream dan alat keamanan
- Pada manifest paket @tanstack/*, entri optionalDependencies berikut adalah IOC utama
```
"optionalDependencies": {
  "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c"
}
```
- IOC file adalah router_init.js di root package, berukuran sekitar 2,3MB, dan tidak tercantum dalam "files"
- Key cache-nya adalah Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11
- URL payload tahap kedua adalah https://litter.catbox.moe/h8nc9u.js, https://litter.catbox.moe/7rrc6l.mjs
- Jaringan eksfiltrasi adalah filev2.getsession.org, seed{1,2,3}.getsession.org
- Identitas commit palsu adalah claude <claude@users.noreply.github.com>, yang bukan Anthropic Claude asli melainkan email no-reply GitHub yang dimanipulasi
- Akun penyerang yang sebenarnya adalah zblgg id 127806521, voicproducoes id 269549300
- Fork penyerang adalah github.com/zblgg/configuration, yaitu fork TanStack/router yang di-rename untuk menghindari pencarian
- Commit payload orphan dalam network fork adalah 79ac49eedf774dd4b0cfa308722bc463cfe5885c
- Workflow run yang menjalankan publish berbahaya adalah github.com/TanStack/router/actions/runs/25613093674 attempt 4 dan github.com/TanStack/router/actions/runs/25691781302

Pelajaran

Hal yang berjalan baik
- Para peneliti eksternal mendeteksi insiden dalam sekitar 20 menit setelah kejadian dan melaporkannya beserta seluruh detail teknis
- Tim maintainer segera berkoordinasi lintas beberapa zona waktu
- Komunitas deteksi memperoleh pola IOC publik yang jelas dalam hitungan jam
Hal yang perlu diperbaiki
- Tidak ada alerting internal, dan fakta compromise diketahui dari pihak ketiga
- Diperlukan monitoring publish internal, serta rencananya akan bekerja sama lebih erat dengan perusahaan riset keamanan ekosistem yang bisa mendeteksi masalah seperti ini dengan cepat dan memperpendek feedback loop
- Workflow pull_request_target sudah lama dikenal sebagai pola berbahaya, tetapi belum diaudit
- Floating ref untuk action pihak ketiga seperti @v6.0.2, @main menciptakan supply-chain risk yang terus-menerus, terlepas dari insiden ini
- Karena kebijakan npm “tidak bisa unpublish jika ada dependent”, unpublish tidak dimungkinkan untuk hampir semua paket yang terdampak
- Harus bergantung pada npm security untuk penghapusan tarball di sisi registry, sehingga ada tambahan beberapa jam saat tarball berbahaya tetap bisa diinstal
- Daftar 7 maintainer pada scope npm berarti ada 7 target pencurian kredensial terpisah untuk blast radius yang sama
- OIDC trusted-publisher binding tidak memiliki review per publish, dan setelah dikonfigurasi, jalur kode mana pun di dalam workflow dapat mencetak token yang bisa digunakan untuk publish
- Alternatif yang dibutuhkan adalah beralih ke classic token jangka pendek dengan review manual, atau menambahkan provenance-source-verification yang mendeteksi publish dari step workflow yang tidak terduga
Hal yang menguntungkan
- Penyerang memilih payload yang merusak test sehingga step publish normal dilewati, dan tarball yang tampak lebih bersih tidak jadi dibuat
- Karena itu, serangan terlihat cukup mencolok sehingga cepat terdeteksi
- Jika penyerang yang lebih hati-hati tidak merusak test, mereka bisa publish diam-diam selama beberapa jam lebih lama
- Penyerang menggunakan ulang script memory dump publik yang berisi attribution comment, dan tidak menulis kode baru, sehingga pencocokan IOC menjadi lebih cepat

Pertanyaan yang tersisa

Perlu dipastikan apakah step Setup Tools di bundle-size.yml benar-benar memanggil actions/cache@v5
Perlu diverifikasi dengan membaca post-job log dari salah satu run pull_request_target untuk PR #7378, dengan contoh run id 25666610798
Perlu dipastikan apa yang ada di head commit PR awal sebelum hilang karena force-push, dan kemungkinan masih tersisa di GitHub reflog
Perlu dipastikan apakah cara malicious commit masuk ke git object store fork adalah lewat git push langsung, atau melalui pembuatan di GitHub web UI yang akan meninggalkan audit-log entry
Perlu dicocokkan riwayat aktivitas voicproducoes untuk memastikan apakah itu akun nyata atau sock puppet
Perlu dipastikan apakah cache npm yang tampak sebagai 6 entri duplikat linux-npm-store-* juga terkontaminasi, dan apakah benar-benar digunakan
Perlu dipastikan apakah serangan membutuhkan Nx Cloud, atau akan tetap berfungsi hanya dengan GitHub Actions cache
Perlu dipastikan apakah fork lain di dalam jaringan fork TanStack/router yang memuat orphan payload commit bisa diidentifikasi
Jika fork lain meng-host commit tersebut, aksesibilitas github:tanstack/router#79ac49ee... akan tetap ada sehingga cleanup menjadi lebih sulit
Repo TanStack lain seperti router, query, table, form, virtual, dan lainnya perlu diaudit apakah menggunakan pola gaya bundle-size.yml yang sama
Jumlah pengguna yang benar-benar mengunduh versi terdampak selama window publish perlu diminta dari npm support
Perlu dipastikan apakah mesin milik 7 maintainer juga dikompromikan secara terpisah
Malicious publish tidak menggunakan token npm milik maintainer, tetapi mesin maintainer bisa menjadi target sekunder dari logika self-propagation

Referensi

TanStack/router#7383: isu pelacakan
GHSA-g7cv-rxg3-hmpx: GitHub Security Advisory
The Monsters in Your Build Cache: Github Actions Cache Poisoning: riset cache poisoning GitHub Actions tahun 2024 oleh Adnan Khan
Keeping your GitHub Actions and workflows secure: Preventing pwn requests: materi GitHub Security Lab tentang pencegahan pwn request
Harden-Runner detection: tj-actions/changed-files action is compromised: materi deteksi terkait dari StepSecurity pada Maret 2025
Unpublish: kebijakan unpublish npm
Provenance: dokumentasi provenance npm
GHSA-g7cv-rxg3-hmpx: GitHub Security Advisory yang membahas daftar lengkap versi terdampak

1 komentar

GN⁺ 2 jam lalu

Komentar Hacker News

Hati-hati saat mencabut token. Payload tampaknya memasang dead-man's switch ke ~/.local/bin/gh-token-monitor.sh, lalu mendaftarkannya sebagai layanan pengguna systemd di Linux, dan sebagai LaunchAgent com.user.gh-token-monitor di macOS
Token yang dicuri dipakai untuk melakukan polling ke api.github.com/user setiap 60 detik, dan jika token dicabut lalu muncul HTTP 40x, ia menjalankan rm -rf ~/
https://github.com/TanStack/router/issues/7383#issuecomment-...
- Secara realistis, kalau sudah memasang malware, pada akhirnya komputer memang harus diinisialisasi ulang sepenuhnya
- Mengejutkan. Rasanya seperti situasi saling menjamin kehancuran
  Dunia software lima tahun ke depan sepertinya akan benar-benar brutal, dan sistem air-gap tampaknya akan jadi jauh lebih penting
- Seharusnya dari awal selalu menyiapkan backup, tetapi kalau kejadian ini membuat orang mulai punya backup, setidaknya itu hal baik
Paket npm @mistralai/mistralai juga terdampak sebagai bagian dari worm ini
https://github.com/mistralai/client-ts/issues/217
Sekarang sudah diturunkan dari registry npm
Disayangkan, tetapi ini tampaknya bukti bahwa Trusted Publishing saja tidak cukup untuk melakukan deployment aman dari CI. Jika ada penyerang di dalam pipeline CI atau hak admin repositori dicuri, deployment bisa dilakukan dengan mudah
Ini bukan informasi baru, dan Trusted Publishing memang tidak dirancang untuk menjamin hal itu, tetapi saat berpindah dari deployment lokal + autentikasi dua faktor ke Trusted Publishing, jalur serangan melalui kompromi CI seperti ini jadi terbuka. Faktor kedua yang dulu mencegah npm publish saat bekerja secara lokal menjadi hilang
Dari perkembangan yang terlihat sekarang, penyerang tampaknya mengambil alih pipeline CI/CD, lalu karena npm publish tidak punya faktor kedua, mereka bisa mencuri token OIDC dan menyelesaikan deployment. Menariknya, walau job deployment itu sendiri gagal, payload di dalam commit berbahaya tampaknya bisa melakukan publish sendiri memakai token OIDC dari workflow
Yang diinginkan adalah tetap mempertahankan model Trusted Publisher tanpa token jangka panjang, tetapi dengan deployment CI yang masih memiliki faktor kedua di luar GitHub. Artinya dibutuhkan deployment bertahap di mana seseorang harus mempromosikan artefak ke status benar-benar publik dengan autentikasi dua faktor di sisi npm
Jika deployment hanya bisa dilakukan di dalam model kepercayaan GitHub, siapa pun yang berhasil mencuri token admin repositori atau menyisipkan kode berbahaya ke pipeline akan mudah menyelesaikan deployment. Jika ada faktor kedua yang nyata di luar konteks GitHub, mereka mungkin tetap bisa merusak repositori atau menyisipkan malware, tetapi tidak bisa melakukan deployment tanpa faktor kedua untuk registry
- Saya punya satu paket yang cukup populer, dan masih memakai deployment lokal dan autentikasi dua faktor. Trusted Publishing terlihat terlalu rumit dan seperti terus diretas, jadi rasanya mungkin terlalu kompleks untuk kami operasikan dengan aman dan mungkin perlu didesain ulang dari nol
- Saya tetap menganggap Trusted Publishing sebagai peningkatan besar, tetapi ide mewajibkan faktor kedua saat menandai rilis sebagai benar-benar publik itu bagus. Itu akan membuat worm CI seperti ini jadi sangat sulit dijalankan
- Saya ingin tanda tangan sentuh dengan sesuatu seperti YubiKey. Gagasan mempercayai cloud untuk mengelola kredensial atas nama kita sendiri terasa seperti kesalahan
- Blog astral baru-baru ini menunjukkan cara tetap memakai Trusted Publishing sambil menambahkan gerbang rilis, yaitu dengan menaruh persetujuan manual di workflow rilis. Sayangnya, dokumentasi Trusted Publishing untuk NPM/PyPI/Rubygems bahkan tidak menyebut kemungkinan ini, apalagi menjadikannya default
- Saya tidak pernah benar-benar paham kenapa orang bilang Trusted Publishing membuat perbedaan untuk jenis serangan rantai pasok seperti ini
Postmortem: https://tanstack.com/blog/npm-supply-chain-compromise-postmo...
- Terima kasih untuk postmortem dari TanStack, tetapi dari sudut pandang seluruh ekosistem npm, isu keamanan ini tampaknya masih merupakan kekhawatiran yang sedang berlangsung
  Saya penasaran apakah ada bukti bahwa subpaket yang mungkin mengambil atau menyertakan paket TanStack bisa dianggap aman
Skrip postinstall itu fatal. Semua orang seharusnya memakai pnpm
Sulit dipercaya bahwa commit “yatim” yang di-push ke FORK bisa memicu hal seperti ini di klien npm. Menurut saya GitHub juga sangat bertanggung jawab. Bahwa commit dari fork berbahaya bisa diakses dengan URI yang tidak bisa dibedakan dari repositori normal melalui shared object store GitHub adalah desain yang benar-benar gila
- Kalau menjalankan aplikasi dengan dependensi yang sudah diperbarui, kode itu tetap akan berjalan. Root atau non-root juga tidak terlalu penting, karena hal-hal penting bisa diakses dengan hak pengguna yang menjalankan aplikasi
- Saya tidak paham bagaimana ini bukan insiden P0 di GitHub. Ada yang bisa menjelaskan?
  Saat pertama membaca, saya kira mereka salah pakai istilah “fork” dan sebenarnya maksudnya branch di repositori resmi. Saya pikir itu tidak mungkin benar, tapi astaga
https://tanstack.com/blog/npm-supply-chain-compromise-postmo...
TanStack baru saja mempublikasikan postmortem untuk insiden ini
Ini pengingat untuk mengamankan lingkungan npm
https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f...
Hanya dengan beberapa pengaturan, banyak masalah besar bisa dikurangi
- Di npm v11 ke atas juga ada allow-git=none: https://github.blog/changelog/2026-02-18-npm-bulk-trusted-pu...
- Sepertinya tulisan ini salah tentang usia rilis minimum di npm. 1) Nama konfigurasinya min-release-age. 2) Entah kenapa dibuat dalam satuan hari, bukan menit: https://docs.npmjs.com/cli/v11/using-npm/config#min-release-...
  Menurut saya ruang dependency manager sudah terfragmentasi sepenuhnya tanpa perlu
- Klaim bahwa menetapkan usia minimum ke 7 hari membuat Anda “tidak akan pernah” mengalami kerentanan rantai pasok npm jelas berlebihan
- Semua dependensi harus benar-benar dipin
  Jika dependensi versi paket Anda berupa ^1.0.0 atau bahkan "*", berhentilah membaca dan segera pin ke versi yang aman
Saya membuat ini buru-buru dengan Claude untuk membantu mengurangi penyebaran. Tentu tetap harus diverifikasi sendiri, tetapi ini memindai apakah paket yang terkompromi yang disebutkan ada di mesin Anda: https://github.com/PaulSinghDev/tanstack-shai-hulud-fix
Sepertinya sekarang kita sudah sampai di tahap di mana semua orang perlu menjalankan tiap proyek di VM terpisah
Melihat kerentanan eskalasi hak lokal belakangan ini, Docker saja jelas tidak cukup. Dari awal pun container memang tidak dirancang sebagai batas keamanan utama
- Devcontainers adalah bentuk paling dikenal dari konsep “lingkungan pengembangan terisolasi” ini, tetapi itu bukan VM penuh dan tidak sepenuhnya melindungi dari kejadian kali ini. Kredensial GitHub masuk otomatis ke dalam container
  Jika ada layanan cloud lain yang perlu diakses dari dalam container, pencuri kredensial ini juga akan mengambil itu. Meski begitu, setidaknya radius dampaknya jadi lebih kecil, jadi tetap merupakan perbaikan
- QubesOS tampaknya mengambil arah yang benar. Kita jadi ingin punya banyak VM di atas host utama dan lapisan keamanan berlapis-lapis
- Kalau memang harus memakai container, ada juga pendekatan satu VM untuk tiap container. Beberapa minggu terakhir terasa cukup tenang karena semuanya dijalankan di VM, bukan layanan Kubernetes sembarang
- Untungnya, proyek yang memakai ekosistem bahasa yang lebih aman seperti C dan C++ terbebas dari masalah seperti ini :-)
Wah, ini paket besar lain lagi. Saya mengunggah ulang pengumuman layanan masyarakat yang saya buat setelah Axios dan LiteLLM terkompromi. Bagian tentang skrip lifecycle juga berlaku di sini
npm/bun/pnpm/uv sekarang semuanya mendukung pengaturan usia rilis minimum paket. Saya juga menaruh ignore-scripts=true di ~/.npmrc, dan dari analisis yang ada, itu saja sudah bisa memitigasi kerentanan ini. bun dan pnpm secara default tidak menjalankan skrip lifecycle
Cara menetapkan usia rilis minimum global ke 7 hari adalah sebagai berikut
~/.config/uv/uv.toml
exclude-newer = "7 days"
~/.npmrc
min-release-age=7 # days
ignore-scripts=true
~/Library/Preferences/pnpm/rc
minimum-release-age=10080 # minutes
~/.bunfig.toml
[install]
minimumReleaseAge = 604800 # seconds
Jika perlu menimpa pengaturan global, cukup pakai flag CLI
npm install --min-release-age 0
pnpm add --minimum-release-age 0
uv add --exclude-newer "0 days"
bun add --minimum-release-age 0
Satu hal lagi, tampaknya ada kekhawatiran bahwa jika masa tunggu dependensi diterapkan secara luas, penemuan kerentanan jadi lebih lambat, atau bahwa masa tunggu dependensi semacam ini adalah tindakan numpang aman. Saya tidak setuju. Yang dipertukarkan oleh masa tunggu dependensi adalah preferensi waktu, dan akan selalu ada orang yang preferensi waktunya lebih tinggi daripada saya
0: https://news.ycombinator.com/item?id=47582220
1: https://news.ycombinator.com/item?id=47513932
- Setuju. Untung saya sudah mengaktifkan pengaturan ini pada bulan Maret, sebelum dua gelombang terakhir. Selain itu, commit juga lockfile ke repositori dan berhati-hatilah saat menambahkan dependensi baru
  Untuk menghindari perubahan tak terduga, gunakan pnpm install --frozen-lockfile. Perlu diingat, jika min-release-age tidak diatur, paket yang terdampak bisa tetap tertarik melalui dependensi transitif. Kalau bisa, sebaiknya pin juga versi package manager

Analisis pascainsiden: kompromi rantai pasok npm TanStack

Ringkasan insiden

Cakupan dampak

Paket yang terdampak

Perilaku malware

Linimasa

Sebelum serangan: tahap peracunan cache

Pemicu: tahap publikasi

Deteksi dan respons

Akar masalah

Kombinasi tiga kerentanan

Pola pull_request_target “Pwn Request”

Peracunan cache GitHub Actions

Ekstraksi token OIDC dari memori runner

Mengapa tiap elemen tidak cukup bila berdiri sendiri

Deteksi dan IOC

Jalur deteksi

Fingerprint untuk maintainer downstream dan alat keamanan

Pelajaran

Hal yang berjalan baik

Hal yang perlu diperbaiki

Hal yang menguntungkan

Pertanyaan yang tersisa

Referensi

Bacaan terkait

1 komentar

Komentar Hacker News

Pola `pull_request_target` “Pwn Request”