पोस्टमॉर्टम: TanStack npm सप्लाई चेन समझौता

(tanstack.com)

1 पॉइंट द्वारा GN⁺ 2026-05-12 | 1 टिप्पणियां | WhatsApp पर शेयर करें

2026-05-11 19:20~19:26 UTC पर हमलावर ने 42 @tanstack/ npm पैकेजों में कुल 84 malicious versions publish किए
attack chain ने pull_request_target “Pwn Request”, GitHub Actions cache poisoning, और runner memory से OIDC token extraction को जोड़ा
npm token और publish workflow चोरी या compromise नहीं हुए; malicious code ने OIDC trusted publisher अधिकार के साथ registry पर सीधे POST किया
प्रभावित version install होने पर AWS, GCP, Kubernetes, Vault, GitHub, npm, SSH credentials उजागर हो सकते थे, इसलिए उन्हें बदलना ज़रूरी है
सभी प्रभावित versions को deprecated कर दिया गया है, npm security के साथ tarball removal किया गया है, और tracking issue व GitHub Security Advisory प्रकाशित कर दिए गए हैं

घटना का सारांश

2026-05-11 19:20~19:26 UTC के बीच हमलावर ने 42 @tanstack/* npm पैकेजों में कुल 84 malicious versions publish किए
attack chain ने pull_request_target “Pwn Request” पैटर्न, fork↔base trust boundary को पार करने वाला GitHub Actions cache poisoning, और GitHub Actions runner process memory से OIDC token extraction को जोड़ा
पुष्टि हुई कि npm tokens चोरी नहीं हुए थे, और npm publish workflow स्वयं भी compromise नहीं हुआ था
malicious versions को बाहरी researcher ashishkurmi ने stepsecurity में सार्वजनिक रूप से 20 मिनट के भीतर detect किया
सभी प्रभावित versions को deprecated कर दिया गया, और npm security के साथ मिलकर registry से tarball removal किया गया
जिन उपयोगकर्ताओं ने 2026-05-11 को प्रभावित versions install किए, उन्हें install host से सुलभ AWS, GCP, Kubernetes, Vault, GitHub, npm, SSH credentials बदलने चाहिए
tracking issue TanStack/router#7383 है, और GitHub Security Advisory GHSA-g7cv-rxg3-hmpx है

प्रभाव का दायरा

प्रभावित पैकेज
- प्रभाव 42 पैकेजों और 84 versions तक सीमित है, और प्रति पैकेज 2 versions लगभग 6 मिनट के अंतराल पर publish किए गए
- पूरी सूची tracking issue में शामिल है
- पुष्टि किए गए अप्रभावित product families हैं @tanstack/query*, @tanstack/table*, @tanstack/form*, @tanstack/virtual*, @tanstack/store, और @tanstack/start meta package
- @tanstack/start-* पुष्टि किए गए अप्रभावित सूची में शामिल नहीं है
malicious code का व्यवहार
- यदि developer या CI environment प्रभावित version पर npm install, pnpm install, yarn install चलाता है, तो npm malicious optionalDependencies entry को resolve करता है और fork network के orphan payload commit को fetch करता है
- इसके बाद prepare lifecycle script चलती है, और प्रभावित tarball के भीतर छिपी लगभग 2.3MB obfuscated router_init.js execute होती है
- malicious script AWS IMDS/Secrets Manager, GCP metadata, Kubernetes service-account token, Vault token, ~/.npmrc, GitHub token, gh CLI, .git-credentials, SSH private key जैसी सामान्य locations से credentials इकट्ठा करती है
- चुराया गया data Session/Oxen messenger file-upload network के माध्यम से exfiltrate किया जाता है, और target हैं filev2.getsession.org, seed{1,2,3}.getsession.org
- यह network end-to-end encrypted है और इसमें attacker-controlled C2 नहीं है, इसलिए network mitigation केवल IP/domain blocking तक सीमित है
- self-propagation logic registry.npmjs.org/-/v1/search?text=maintainer:<user> से पीड़ित द्वारा maintain किए जाने वाले अन्य packages को enumerate करती है, फिर उसी injection method से दोबारा publish करती है
- क्योंकि payload npm install lifecycle के हिस्से के रूप में execute होती है, इसलिए जिन hosts ने 2026-05-11 को प्रभावित versions install किए, उन्हें संभावित रूप से compromised माना जाना चाहिए

टाइमलाइन

हमले से पहले: कैश पॉइज़निंग चरण
- 2026-05-10 17:16 UTC पर हमलावर ने TanStack/router का fork github.com/zblgg/configuration बनाया और fork सूची खोज से बचने के लिए उसका नाम बदल दिया
- 2026-05-10 23:29 UTC पर छेड़छाड़ की गई पहचान claude <claude@users.noreply.github.com> के साथ दुर्भावनापूर्ण commit 65bf499d16a5e8d25ba95d69ec9790a6dd4a1f14 fork में बनाया गया
- उस commit ने लगभग 30,000 लाइनों वाला bundled JS payload packages/history/vite_setup.mjs जोड़ा और push event की CI को दबाने के लिए commit message में [skip ci] लगाया
- 2026-05-11 लगभग 10:49 UTC पर zblgg ने TanStack/router main के खिलाफ “WIP: simplify history build” शीर्षक वाला PR #7378 खोला
- bundle-size.yml और labeler.yml दोनों PR के लिए pull_request_target पर अपने-आप चले, और pull_request_target पहले योगदानकर्ता approval gate को bypass करता है, इसलिए अलग approval की ज़रूरत नहीं थी
- pull_request इस्तेमाल करने वाला pr.yml approval की प्रतीक्षा में blocked रहा और चला नहीं
- 2026-05-11 11:01~11:11 UTC के बीच zblgg ने PR head पर कई बार force-push किया, जिससे अतिरिक्त pull_request_target runs ट्रिगर हुए
- 2026-05-11 11:11 UTC पर दुर्भावनापूर्ण commit 65bf499d PR head पर पहुंच गया, और bundle-size.yml के benchmark-pr job ने refs/pull/7378/merge checkout करने के बाद pnpm install और pnpm nx run @benchmarks/bundle-size:build चलाया, जिससे vite_setup.mjs सक्रिय हुआ
- 2026-05-11 11:29 UTC पर Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11 नाम का 1.1GB GitHub Actions cache TanStack/router में store किया गया
- यह cache refs/heads/main scope में store किया गया था और इसे इस तरह configure किया गया था कि अगली main push पर release.yml जिस key को lookup करेगा, उससे यह match हो जाए
- 2026-05-11 11:31 UTC पर हमलावर ने PR को उस समय के main HEAD b1c061af पर वापस कर दिया, जिससे visible PR 0-file no-op जैसा दिखने लगा, और उसी मिनट PR बंद कर branch हटा दी गई, लेकिन दूषित cache बना रहा
ट्रिगर: प्रकाशन चरण
- 2026-05-11 19:15 UTC पर Manuel ने PR #7369 merge किया, जिससे main push हुआ, और release.yml workflow run 25613093674 19:15:44 पर शुरू होने के बाद fail हो गया
- 2026-05-11 19:20:39 UTC पर npm registry ने @tanstack/history@1.161.9 और 41 sibling packages के publish प्राप्त किए
- कुल मिलाकर 42 packages में लगभग 84 versions publish किए गए, लेकिन इस सटीक क्षण पर इनमें से लगभग आधे ही दिखते हैं; बाकी दूसरे run में publish हुए
- publish authentication TanStack/router release.yml@refs/heads/main के लिए OIDC trusted-publisher binding के जरिए हुई, लेकिन यह tests fail होने के कारण skipped workflow के Publish Packages step में नहीं हुआ
- वास्तविक publisher tests/cleanup चरण में चला malware था, जिसने id-token: write permission के साथ OIDC token mint किया और फिर registry.npmjs.org पर सीधे POST किया
- 2026-05-11 19:20:47 UTC पर run 25613093674 failure status के साथ पूरा हुआ
- 2026-05-11 19:16 UTC पर Manuel ने PR #7382 merge किया, जिससे दूसरी main push हुई, और 19:16:22 पर workflow run 25691781302 शुरू हुआ
- दूसरे run ने भी वही दूषित cache restore किया, और 2026-05-11 19:26:14 UTC पर @tanstack/history@1.161.12 सहित हर package के लिए दूसरा version set उसी OIDC mechanism से publish किया गया
- 2026-05-11 19:26:20 UTC पर run 25691781302 भी failure status के साथ पूरा हुआ
पहचान और प्रतिक्रिया
- 2026-05-11 लगभग 19:50 UTC पर बाहरी researcher carlini ने issue #7383 खोला, जिसमें दुर्भावनापूर्ण optionalDependencies fingerprint और package list शामिल थी
- शुरुआती सूची 42 में से 14 की थी, और researcher ने npm security को भी सीधे सूचित किया
- 2026-05-11 लगभग 20:00 UTC पर Manuel ने #7383 में incident की पुष्टि की और प्रतिक्रिया शुरू की
- 2026-05-11 लगभग 20:10 UTC पर Manuel ने user machines के compromise की संभावना को देखते हुए दूसरे team members की GitHub push permissions हटा दीं
- 2026-05-11 लगभग 20:30 UTC पर Tanner ने पूरी IOC list और registry-side tarball removal request security@npmjs.com पर भेजी, और npm के जरिए औपचारिक malware report जमा की
- 2026-05-11 लगभग 21:00 UTC पर 295 @tanstack/* packages की पूरी scan से scope की पुष्टि 42 packages और 84 versions के रूप में हुई
- Tanner ने सभी 84 प्रभावित packages के लिए npm deprecation शुरू किया, और @tan_stack तथा maintainers ने Twitter/X, LinkedIn और Bluesky पर सार्वजनिक अलर्ट जारी किए
- 2026-05-11 21:30 UTC पर bundle-size.yml के pull_request_target cache poisoning vector और zblgg/configuration fork की पहचान की गई
- सभी TanStack/* GitHub repositories की cache entries API के जरिए हटा दी गईं
- hardening PR merge किया गया, bundle-size.yml को फिर से configure किया गया, repository_owner guard जोड़ा गया, और third-party action refs को SHA पर pin किया गया
- आधिकारिक GitHub Security Advisory publish की गई और CVE का अनुरोध किया गया

मूल कारण

तीन कमजोरियों का संयोजन
- हमले के लिए तीनों कमजोरियां जरूरी थीं, और इनमें से कोई एक अकेले पर्याप्त नहीं थी
- fork PR code का base repository cache तक पहुंचना, base repository cache का release workflow runtime तक पहुंचना, और release workflow runtime का npm registry write permission तक पहुंचना—इस तरह हर कमजोरी दूसरे की trust boundary को जोड़ती है
pull_request_target “Pwn Request” पैटर्न
- bundle-size.yml fork PR के लिए pull_request_target पर चला, और उसी trigger context में fork के PR merge ref को checkout करने के बाद build चलाया गया
- मुख्य संरचना इस प्रकार है
```
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
```
- workflow लेखक ने comment-pr job और benchmark-pr job को अलग करके trust boundary बांटने की कोशिश की थी, और YAML comment में benchmark-pr को “untrusted with read-only permissions” बनाए रखने का इरादा लिखा था
- लेकिन actions/cache@v5 का post-job save, permissions: से नहीं रुकता, और cache write workflow GITHUB_TOKEN नहीं बल्कि runner के internal token का उपयोग करता है
- इसलिए permissions: contents: read सेटिंग cache mutation को नहीं रोक सकी
- cache scope repository स्तर का है, और base repository cache scope का उपयोग करने वाला pull_request_target run और main push इसे साझा करते हैं
- base repository cache scope में चलने वाला PR बाद में main के production workflow द्वारा restore किए जाने वाले cache entry को दूषित कर सकता है
GitHub Actions cache poisoning
- malicious vite_setup.mjs को इस तरह डिज़ाइन किया गया था कि वह उस pnpm-store key के अनुसार data लिखे जिसे सामान्य release.yml workflow calculate और lookup करेगा
- target key का फ़ॉर्मेट Linux-pnpm-store-${hashFiles('**/pnpm-lock.yaml')} है
- benchmark-pr job के अंत में actions/cache@v5 post-step दूषित pnpm store को ठीक उसी key के साथ save करता है
- बाद में main push पर जब release.yml चला, तो Setup Tools step ने डिज़ाइन के मुताबिक उसी दूषित entry को restore किया
- इस तरह का हमला 2024 में Adnan Khan द्वारा दस्तावेजीकृत GitHub Actions cache poisoning परिवार का हिस्सा है, और यह केवल TanStack तक सीमित bug नहीं बल्कि GitHub Actions का एक design issue है जिसके लिए जानबूझकर mitigation की जरूरत है
runner memory से OIDC token निकालना
- release.yml npm OIDC trusted publishing के लिए जरूरी होने के कारण वैध रूप से id-token: write घोषित करता है
- जब दूषित pnpm store runner पर restore होता है, तो attacker-controlled binary disk पर मौजूद होती है और build step के दौरान call की जाती है
- यह binary /proc/*/cmdline के जरिए GitHub Actions Runner.Worker process को ढूंढती है, और /proc/<pid>/maps तथा /proc/<pid>/mem पढ़कर worker memory dump करती है
- इसके बाद runner द्वारा id-token: write सेटिंग के तहत lazy mint किया गया OIDC token memory से निकाल लिया जाता है
- निकाले गए token से registry.npmjs.org पर सीधे POST request authenticate की जाती है, जिससे workflow के Publish Packages step को पूरी तरह bypass कर दिया जाता है
- यह memory extraction तरीका मार्च 2025 के tj-actions/changed-files compromise में इस्तेमाल किए गए तरीके जैसा ही है, और attribution comment सहित वही Python script इस्तेमाल की गई थी
- attacker ने कोई नई तकनीक ईजाद नहीं की, बल्कि सार्वजनिक research को फिर से संयोजित किया
क्यों हर तत्व अकेले पर्याप्त नहीं था
- pull_request_target अपने-आप में label या comment जैसे trusted कामों के लिए इस्तेमाल किया जा सकता है
- पहले से compromised dependency के अंदर cache poisoning अकेले पर्याप्त नहीं है; इसके लिए अलग publish vehicle भी चाहिए
- केवल OIDC token extraction से काम नहीं चलता; runner पर पहले से code execution होना जरूरी है

detection और IOC

detection path
- detection अंदरूनी रूप से नहीं, बल्कि बाहर से हुई
- carlini ने publish के लगभग 20 मिनट बाद issue #7383 खोलकर पूरा technical analysis दिया
- Tanner को war room शुरू करने के तुरंत बाद Socket.dev से स्थिति की पुष्टि करने के लिए call मिला
downstream maintainer और security tools के लिए fingerprint
- @tanstack/* package manifest में नीचे दिया गया optionalDependencies entry मुख्य IOC है
```
"optionalDependencies": {
  "@tanstack/setup": "github:tanstack/router#79ac49eedf774dd4b0cfa308722bc463cfe5885c"
}
```
- file IOC package root में router_init.js है, इसका आकार लगभग 2.3MB है, और यह "files" में शामिल नहीं है
- cache key है Linux-pnpm-store-6f9233a50def742c09fde54f56553d6b449a535adf87d4083690539f49ae4da11
- stage 2 payload URL हैं https://litter.catbox.moe/h8nc9u.js, https://litter.catbox.moe/7rrc6l.mjs
- exfiltration network है filev2.getsession.org, seed{1,2,3}.getsession.org
- forged commit identity है claude <claude@users.noreply.github.com>, जो वास्तविक Anthropic Claude नहीं बल्कि हेरफेर किया गया GitHub no-reply email है
- वास्तविक attacker account हैं zblgg id 127806521, voicproducoes id 269549300
- attacker fork है github.com/zblgg/configuration, जिसे TanStack/router fork को search evasion के उद्देश्य से rename किया गया था
- fork network के भीतर orphan payload commit है 79ac49eedf774dd4b0cfa308722bc463cfe5885c
- malicious publish चलाने वाला workflow run है github.com/TanStack/router/actions/runs/25613093674 attempt 4 और github.com/TanStack/router/actions/runs/25691781302

सबक

क्या अच्छा रहा
- बाहरी शोधकर्ताओं ने घटना के लगभग 20 मिनट के भीतर इसका पता लगाकर पूरी तकनीकी जानकारी के साथ रिपोर्ट किया
- maintainer team ने कई time zone में तुरंत समन्वय किया
- detection community ने कुछ घंटों के भीतर स्पष्ट सार्वजनिक IOC pattern तैयार कर लिए
किन बातों में सुधार की ज़रूरत थी
- कोई internal alerting नहीं था, और compromise की जानकारी तीसरे पक्ष से मिली
- अपने publish monitoring की ज़रूरत है, और ऐसे मुद्दों का तेज़ी से पता लगाने वाली ecosystem security research कंपनियों के साथ अधिक नज़दीकी से काम करके feedback loop को छोटा करने की योजना है
- pull_request_target workflow लंबे समय से एक जोखिमपूर्ण pattern के रूप में जाना जाता था, लेकिन उसका audit नहीं किया गया था
- third-party action के floating ref @v6.0.2, @main ने इस घटना से अलग भी स्थायी supply-chain risk पैदा किया
- npm की “dependent होने पर unpublish नहीं कर सकते” नीति के कारण लगभग सभी प्रभावित package के लिए unpublish संभव नहीं था
- registry-side tarball हटाने के लिए npm security पर निर्भर रहना पड़ा, जिससे malicious tarball कुछ अतिरिक्त घंटों तक install किए जा सकने की स्थिति में रहे
- npm scope में 7 maintainer की सूची का मतलब था कि एक ही blast radius के लिए credential theft के 7 अलग-अलग target मौजूद थे
- OIDC trusted-publisher binding में हर publish के लिए review नहीं होता, और एक बार सेट हो जाने पर workflow के भीतर कोई भी code path publish करने योग्य token mint कर सकता है
- ज़रूरी विकल्प है manual review वाले short-term classic token पर जाना, या provenance-source-verification जोड़ना जो workflow के किसी अप्रत्याशित step में publish का पता लगा सके
किस्मत साथ रही
- attacker ने ऐसा payload चुना जिसने test तोड़ दिए, इसलिए सामान्य publish step skip हो गया और अधिक साफ़ दिखने वाला tarball नहीं बना
- इसी वजह से हमला पर्याप्त शोर के साथ सामने आया और जल्दी पकड़ में आ गया
- अगर attacker अधिक सावधान होता और test नहीं तोड़ता, तो वह कई घंटों तक और चुपचाप publish कर सकता था
- attacker ने attribution comment वाला एक सार्वजनिक memory-dump script दोबारा इस्तेमाल किया, और नया code नहीं लिखा, जिससे IOC matching और तेज़ हो गई

बचे हुए सवाल

यह पुष्टि करनी है कि क्या bundle-size.yml के Setup Tools step ने वास्तव में actions/cache@v5 को call किया था
PR #7378 के pull_request_target run में से एक का post-job log पढ़कर सत्यापन करना है; उदाहरण run id 25666610798 है
यह जाँचना है कि force-push से गायब होने से पहले शुरुआती PR head commit में क्या था; संभव है कि वह GitHub reflog में बचा हो
यह सत्यापित करना है कि malicious commit fork के git object store में सीधे git push से गया था या GitHub web UI के ज़रिए बना था, जिससे audit-log entry रह जाती
voicproducoes वास्तविक account है या sock puppet, यह उसकी activity history से मिलान करके देखना है
npm cache, जो 6 duplicate linux-npm-store-* entry जैसा दिखता है, क्या वह भी contaminate हुआ था और क्या उसका वास्तव में उपयोग हुआ, यह देखना है
यह पुष्टि करनी है कि क्या हमले के लिए Nx Cloud ज़रूरी था, या केवल GitHub Actions cache से भी यह काम कर सकता था
यह देखना है कि क्या TanStack/router fork network के भीतर orphan payload commit वाले अन्य fork की पहचान की जा सकती है
अगर कोई दूसरा fork उस commit को host कर रहा है, तो github:tanstack/router#79ac49ee... की पहुँच बनी रह सकती है, जिससे cleanup और कठिन हो जाएगा
यह audit ज़रूरी है कि router, query, table, form, virtual जैसे अन्य TanStack repo भी वही bundle-size.yml शैली का pattern इस्तेमाल करते हैं या नहीं
publish window के दौरान प्रभावित version वास्तव में डाउनलोड करने वाले users की संख्या npm support से लेनी है
यह जाँचना है कि 7 maintainer की machines अलग से compromise हुई थीं या नहीं
malicious publish में maintainer npm token का उपयोग नहीं हुआ था, लेकिन maintainer machine self-propagation logic के secondary target हो सकते हैं

संदर्भ सामग्री

TanStack/router#7383: tracking issue
GHSA-g7cv-rxg3-hmpx: GitHub Security Advisory
The Monsters in Your Build Cache: Github Actions Cache Poisoning: Adnan Khan का 2024 GitHub Actions cache poisoning शोध
Keeping your GitHub Actions and workflows secure: Preventing pwn requests: GitHub Security Lab की pwn request रोकथाम सामग्री
Harden-Runner detection: tj-actions/changed-files action is compromised: StepSecurity की मार्च 2025 की संबंधित detection सामग्री
Unpublish: npm unpublish नीति
Provenance: npm provenance दस्तावेज़
GHSA-g7cv-rxg3-hmpx: सभी प्रभावित version की सूची शामिल करने वाला GitHub Security Advisory

1 टिप्पणियां

GN⁺ 2026-05-12

Hacker News टिप्पणियाँ

टोकन को revoke करते समय सावधान रहना चाहिए। payload शायद ~/.local/bin/gh-token-monitor.sh में dead-man's switch इंस्टॉल करता है, और Linux पर इसे systemd user service के रूप में, macOS पर LaunchAgent com.user.gh-token-monitor के रूप में रजिस्टर करता है
चुराए गए टोकन से हर 60 सेकंड में api.github.com/user को poll किया जाता है, और टोकन revoke होने पर HTTP 40x आने लगे तो rm -rf ~/ चलाया जाता है
https://github.com/TanStack/router/issues/7383#issuecomment-...
- व्यावहारिक रूप से, अगर आपने malware इंस्टॉल कर लिया है तो वैसे भी कंप्यूटर को पूरी तरह wipe करना पड़ेगा
- हैरान करने वाला। यह mutually assured destruction जैसी स्थिति है
  अगले 5 साल software दुनिया में सचमुच बहुत उथल-पुथल वाले लगते हैं, और air-gapped systems बहुत महत्वपूर्ण हो सकते हैं
- वैसे तो हमेशा backup सेट होना चाहिए, लेकिन अगर इस घटना की वजह से लोग backup रखना शुरू करें तो कम से कम वही सही
@mistralai/mistralai npm पैकेज भी इस worm के हिस्से के रूप में compromise हुआ
https://github.com/mistralai/client-ts/issues/217
अभी इसे npm registry से हटा दिया गया है
दुर्भाग्य से, यह इस बात का सबूत लगता है कि सिर्फ Trusted Publishing CI में सुरक्षित deployment के लिए पर्याप्त नहीं है। अगर CI pipeline के अंदर attacker हो या repository admin अधिकार चोरी हो जाएँ, तो deployment आसानी से किया जा सकता है
यह कोई नई जानकारी नहीं है, और Trusted Publishing को इसके लिए डिज़ाइन भी नहीं किया गया था, लेकिन local deployment और 2-factor authentication से Trusted Publishing पर जाने पर CI compromise के जरिए ऐसा attack path बनता है। local में काम करते समय जो दूसरा factor npm publish को रोकता था, वह गायब हो जाता है
अभी जो घटनाक्रम दिख रहा है, उसमें attacker ने CI/CD pipeline पर कब्जा किया और npm publish पर दूसरा factor न होने के कारण OIDC token चुराकर deployment पूरा कर लिया। दिलचस्प लेकिन अलग बात यह है कि deployment job खुद fail हुई, फिर भी malicious commit के payload ने workflow के OIDC token से खुद को publish कर लिया
ज़रूरत यह है कि long-term token रहित Trusted Publisher model बना रहे, लेकिन CI deployment में GitHub के बाहर का दूसरा factor भी मौजूद हो। यानी staged deployment चाहिए, जहाँ npm पक्ष पर कोई 2-factor authentication के साथ artifact को सचमुच public state में promote करे
अगर deployment सिर्फ GitHub trust model के भीतर ही संभव हो, तो repository admin token चुराने वाला या pipeline में malicious code डालने वाला कोई भी व्यक्ति deployment आसानी से पूरा कर सकता है। अगर GitHub context के बाहर असली दूसरा factor हो, तो कोई repository खराब कर सकता है या malware डाल सकता है, लेकिन registry के दूसरे factor के बिना publish नहीं कर सकता
- मेरे पास एक moderately popular package है, और मैं अब भी local deployment और 2-factor authentication का इस्तेमाल करता हूँ। Trusted Publishing बहुत जटिल लगता है और ऐसा भी लगता है कि इसे बार-बार hack किया जा रहा है, इसलिए लगता है कि यह सुरक्षित संचालन के लिए ज़रूरत से ज़्यादा complex है और शायद इसे दोबारा design से शुरू करना चाहिए
- फिर भी मुझे लगता है कि Trusted Publishing एक बड़ा सुधार है, लेकिन release को वास्तव में public mark करते समय दूसरा factor माँगने का विचार अच्छा है। इससे ऐसे CI worm चलाना बहुत कठिन हो जाएगा
- मैं YubiKey जैसी किसी चीज़ से touch signing करना चाहूँगा। यह विचार ही गलती जैसा लगता है कि cloud को credentials संभालने के लिए भरोसा किया जाए
- astral blog ने हाल में दिखाया था कि Trusted Publishing का उपयोग करते हुए भी release gate कैसे रखा जा सकता है, यानी release workflow में manual approval डालकर। अफसोस की बात है कि NPM/PyPI/Rubygems के Trusted Publishing docs इस संभावना का ज़िक्र तक नहीं करते, और इसे default के रूप में भी नहीं देते
- मुझे हमेशा समझ नहीं आया कि लोग क्यों कहते हैं कि इस तरह के supply chain attack में Trusted Publishing कोई खास फर्क पैदा करता है
पोस्टमॉर्टम: https://tanstack.com/blog/npm-supply-chain-compromise-postmo...
- TanStack का पोस्टमॉर्टम सराहनीय है, लेकिन npm ecosystem के पूरे नज़रिए से देखें तो security issue अभी भी जारी चिंता नहीं है क्या?
  मैं जानना चाहता हूँ कि क्या इस बात का कोई सबूत है कि वे downstream packages सुरक्षित माने जा सकते हैं जिन्होंने TanStack packages को fetch या include किया हो सकता है
postinstall script घातक हैं। सबको pnpm इस्तेमाल करना चाहिए
यह बात समझ से बाहर है कि FORK पर push किए गए “orphan” commits npm client में ऐसा व्यवहार ट्रिगर कर सकते हैं। मेरी नज़र में GitHub की भी बड़ी ज़िम्मेदारी है। यह पूरी तरह पागलपन भरी संरचना है कि malicious fork के commits GitHub के shared object store के जरिए ऐसे URI से उपलब्ध हैं जिन्हें legitimate repository से अलग नहीं किया जा सकता
- updated dependency के साथ app चलाने पर वह code वैसे भी execute होगा। root हो या non-root, उससे खास फर्क नहीं पड़ता; महत्वपूर्ण चीज़ें उस user privileges से accessible होती हैं जिनसे application चल रही है
- समझ नहीं आता कि यह GitHub का P0 incident क्यों नहीं है। क्या कोई समझा सकता है?
  पहली बार पढ़ते समय मुझे लगा कि “fork” शब्द का गलत इस्तेमाल हुआ है और असल में official repository की branch की बात हो रही है। मुझे लगा यह सच नहीं हो सकता, लेकिन हे भगवान
https://tanstack.com/blog/npm-supply-chain-compromise-postmo...
TanStack ने अभी इस घटना पर postmortem प्रकाशित किया है
यह npm environment को सुरक्षित तरीके से configure करने का reminder है
https://gajus.com/blog/3-pnpm-settings-to-protect-yourself-f...
सिर्फ कुछ settings से बड़े जोखिम कम किए जा सकते हैं
- npm v11 या उससे ऊपर में allow-git=none भी है: https://github.blog/changelog/2026-02-18-npm-bulk-trusted-pu...
- मुझे लगता है यह लेख npm के minimum release age के बारे में गलत है। 1) setting का नाम min-release-age है। 2) किसी वजह से इसे minutes में नहीं बल्कि days में बनाया गया है: https://docs.npmjs.com/cli/v11/using-npm/config#min-release-...
  dependency manager की दुनिया पूरी तरह अनावश्यक रूप से fragmented हो चुकी है
- यह दावा कि minimum age को 7 दिन पर सेट करके npm supply chain vulnerabilities से “कभी नहीं” जूझना पड़ेगा, बढ़ा-चढ़ाकर कहा गया है
- सभी dependencies को ज़रूर pin करना चाहिए
  अगर package version dependency ^1.0.0 जैसी है, या उससे भी खराब "*" है, तो आगे मत पढ़िए और तुरंत इसे किसी सुरक्षित version पर pin कीजिए
इसे Claude से जल्दी-जल्दी बनाकर फैलाव कम करने में मदद करने की कोशिश की थी। जाहिर है, खुद verify करना चाहिए, लेकिन यह बताए गए compromised packages के आपकी मशीन पर होने के लिए scan करता है: https://github.com/PaulSinghDev/tanstack-shai-hulud-fix
अब लगता है कि हम उस चरण पर पहुँच गए हैं जहाँ हर किसी को हर project अलग VM में चलाना चाहिए
हाल की local privilege escalation vulnerabilities को देखते हुए Docker बिल्कुल पर्याप्त नहीं है। वैसे भी container को मुख्य security boundary के रूप में design नहीं किया गया था
- Devcontainers इस तरह के “isolated development environment” विचार का सबसे जाना-पहचाना रूप है, लेकिन यह पूरा VM नहीं है और इस मामले में पूरी सुरक्षा भी नहीं देता। क्योंकि GitHub credentials अपने-आप container के अंदर आ जाते हैं
  अगर container के अंदर access की ज़रूरत वाली दूसरी cloud services भी हों, तो यह credentials stealer उन्हें भी ले जाएगा। फिर भी यह blast radius कम करता है, इसलिए कम से कम सुधार तो है
- QubesOS सही दिशा में है। root पर कई VM रखकर layered security चाहिए
- अगर container ज़रूर इस्तेमाल करना है, तो हर container के लिए एक VM रखने का तरीका भी है। पिछले कुछ हफ्ते काफी सुकून से गुज़रे क्योंकि मैं random Kubernetes services नहीं, बल्कि सब कुछ VM में चला रहा था
- शुक्र है, C और C++ जैसी अधिक सुरक्षित language ecosystems इस्तेमाल करने वाले projects ऐसे मुद्दों से बचे हुए हैं :-)
वाह, यह एक और बड़ा package है। Axios और LiteLLM compromise होने के बाद जो public service announcement पोस्ट किया था, उसे फिर से साझा कर रहा हूँ। lifecycle scripts वाली बात यहाँ भी लागू होती है
npm/bun/pnpm/uv अब सभी package के minimum release age setting को support करते हैं। मैंने ~/.npmrc में ignore-scripts=true भी रखा है, और विश्लेषण के अनुसार सिर्फ इससे भी vulnerability mitigate हो सकती थी। bun और pnpm default रूप से lifecycle scripts नहीं चलाते
global setting के रूप में minimum release age को 7 दिन पर सेट करने का तरीका यह है
~/.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
अगर global setting को override करना हो, तो CLI flags इस्तेमाल किए जा सकते हैं
npm install --min-release-age 0
pnpm add --minimum-release-age 0
uv add --exclude-newer "0 days"
bun add --minimum-release-age 0
एक और बात जोड़ूँ तो, लगता है कुछ लोगों को चिंता है कि dependencies के लिए waiting period बड़े पैमाने पर लागू करने से vulnerabilities की खोज देर से होगी, या dependency waiting period किसी तरह का free-riding है; मैं इससे सहमत नहीं हूँ। dependency waiting period के बदले जो लिया जा रहा है, वह time preference है, और हमेशा ऐसे लोग रहेंगे जिनकी time preference मुझसे अधिक होगी
0: https://news.ycombinator.com/item?id=47582220
1: https://news.ycombinator.com/item?id=47513932
- सहमत। अच्छा हुआ कि मार्च में, पिछली दो लहरों से पहले ही, मैंने ये settings चालू कर दी थीं। इसके अलावा repository में lockfile commit करके रखना चाहिए और नई dependency जोड़ते समय सावधान रहना चाहिए
  अनपेक्षित बदलावों से बचने के लिए pnpm install --frozen-lockfile इस्तेमाल किया जा सकता है। अगर min-release-age सेट नहीं है, तो याद रखें कि affected packages transitive dependencies के जरिए भी आ सकते हैं। संभव हो तो package manager version भी pin करना अच्छा है

पोस्टमॉर्टम: TanStack npm सप्लाई चेन समझौता

घटना का सारांश

प्रभाव का दायरा

प्रभावित पैकेज

malicious code का व्यवहार

टाइमलाइन

हमले से पहले: कैश पॉइज़निंग चरण

ट्रिगर: प्रकाशन चरण

पहचान और प्रतिक्रिया

मूल कारण

तीन कमजोरियों का संयोजन

pull_request_target “Pwn Request” पैटर्न

GitHub Actions cache poisoning

runner memory से OIDC token निकालना

क्यों हर तत्व अकेले पर्याप्त नहीं था

detection और IOC

detection path

downstream maintainer और security tools के लिए fingerprint

सबक

क्या अच्छा रहा

किन बातों में सुधार की ज़रूरत थी

किस्मत साथ रही

बचे हुए सवाल

संदर्भ सामग्री

संबंधित पढ़ाई

1 टिप्पणियां

Hacker News टिप्पणियाँ

`pull_request_target` “Pwn Request” पैटर्न