Shai-Hulud npm वर्म का पूरा विश्लेषण: एक अकाउंट से 1,280+ पैकेज तक फैला हमला

शुरुआत कैसे हुई?

लगभग 09:00 UTC पर हमलावरों ने jaredwray GitHub अकाउंट का नियंत्रण हासिल किया । इस पहुंच का इस्तेमाल कर उन्होंने keyv रिपॉजिटरी की main ब्रांच में malicious code डाला और keyv तथा cacheable परिवार के कई पैकेजों के नए संस्करण प्रकाशित किए ।

शुरुआती संक्रमण में दोनों namespaces के 11 पैकेज शामिल थे। इनमें keyv, cacheable-request, cache-manager, @cacheable/utils, flat-cache और file-entry-cache जैसे पैकेज शामिल थे । Aikido Security, StepSecurity, Socket और Chainguard के शोधकर्ताओं ने शुरुआती घंटों में इस compromise की स्वतंत्र रूप से पुष्टि की ।

पैकेज में क्या बदला गया?

हर संक्रमित पैकेज में एक जैसा infection pattern पाया गया :

• setup.mjs नाम की dropper फाइल
• obfuscated payload Math_Symbol.js
• package.json में जोड़ा गया यह lifecycle hook: "preinstall": "node setup.mjs"

जब किसी डेवलपर या CI सिस्टम ने प्रभावित संस्करण पर npm install चलाया, तो installation पूरी होने से पहले setup.mjs अपने-आप चल गया। इस dropper ने GitHub Releases से वैध Bun JavaScript runtime डाउनलोड किया और उसके जरिए करीब 710–728 KB आकार वाले obfuscated payload Math_Symbol.js को execute किया ।

Microsoft Threat Intelligence ने इसे Mini Shai-Hulud variant के रूप में पहचाना । payload का लक्ष्य संक्रमित developer मशीनों और CI/CD environments से कई तरह के secrets इकट्ठा करना था :

• npm authentication tokens
• GitHub personal access tokens (PATs)
• AWS keys
• Kubernetes secrets
• HashiCorp Vault tokens
• Stripe keys
• Slack tokens
• SSH keys
• Terraform state files
• Docker credentials
• VPN configurations

वर्म खुद दूसरे पैकेजों तक कैसे पहुंचा?

इस हमले को सामान्य malicious package से ज्यादा खतरनाक बनाने वाली बात इसकी self-propagation क्षमता थी। संक्रमित environment से npm publishing tokens और GitHub PATs चुराने के बाद वर्म ने उन credentials का इस्तेमाल दूसरे, असंबंधित maintainers के पैकेजों के malicious versions प्रकाशित करने में किया ।

संक्रमण का विस्तार बहुत तेजी से हुआ:

• करीब दो घंटे में StepSecurity ने 435 पैकेज और 1,557 versions के संक्रमित होने की जानकारी दी ।
• शुरुआती दोपहर तक Aikido Security 868 पैकेजों के 1,381 versions को प्रभावित बता रहा था ।
• दिन खत्म होने तक यह संख्या 1,280 से ज्यादा पैकेजों और 1,680 से ज्यादा versions तक पहुंच गई ।

वर्म केवल keyv और cacheable परिवार तक सीमित नहीं रहा। यह namespace boundaries पार कर Deliveroo, Ornikar, OneReach, Picsart, Qlik और ServiceTitan जैसी संस्थाओं से जुड़े पैकेजों तक भी फैल गया ।

चुराए गए डेटा को कहां भेजा गया?

चुराए गए credentials को हमलावर के नियंत्रण वाले GitHub repository में exfiltrate किया गया। रिपोर्टों के अनुसार वर्म ने इस काम के लिए नया repository बनाया या dedicated exfiltration repository का इस्तेमाल किया । payload में कई redundant exfiltration channels भी थे, ताकि किसी एक channel को बंद किए जाने पर डेटा चोरी पूरी तरह न रुके ।

प्रभावित टीमों को तुरंत क्या करना चाहिए?

सुरक्षा शोधकर्ताओं की साझा सलाह है कि जिस system ने प्रभावित पैकेज का version चलाया या इंस्टॉल किया, उसे केवल malicious files हटाकर सुरक्षित न मानें। ऐसे host को पूरी तरह compromised मानना चाहिए ।

1. प्रभावित versions को pin या roll back करें

सभी प्रभावित direct और transitive dependencies की पहचान करें। package-lock.json, yarn.lock और pnpm-lock.yaml में इस्तेमाल हुए versions की जांच करें ।

ज्ञात clean versions पर वापस जाएं और accidental reinstall रोकने के लिए npm, Yarn या pnpm overrides इस्तेमाल करें। उदाहरण के लिए package.json में "overrides" का उपयोग किया जा सकता है ।

2. संक्रमित host को पूरी तरह exposed मानें

अगर किसी मशीन या CI/CD runner पर प्रभावित version के साथ npm install चला है, तो केवल setup.mjs, Math_Symbol.js या node_modules हटाना पर्याप्त नहीं है । उस environment में मौजूद सभी secrets के उजागर होने की आशंका मानकर जांच और recovery करें।

3. सभी संभावित credentials revoke और rotate करें

निम्न credentials को रद्द कर नए credentials जारी करें :

• npm classic और granular tokens
• GitHub PATs और fine-grained tokens
• AWS IAM और access keys
• Kubernetes service-account tokens
• HashiCorp Vault tokens
• Stripe keys
• Slack tokens
• SSH keys
• Docker credentials
• VPN tokens

4. Token-revocation watcher पहले हटाएं

यह एक महत्वपूर्ण क्रम है। malware कुछ मामलों में GitHub workflow watchers स्थापित कर सकता है, जो नया token बनते ही उसे फिर से उजागर कर दें । इसलिए credentials rotate करने से पहले ऐसे unauthorized watchers या monitoring workflows को disable या remove करने की सलाह दी गई है ।

5. सभी caches साफ करें और clean rebuild करें

Developer machines और CI/CD runners—दोनों पर npm, pnpm और Yarn caches साफ करें। Docker build caches और संबंधित build artifacts भी हटाएं । इसके बाद images और artifacts को scratch से rebuild करें, ताकि संक्रमित dependency किसी पुराने cache या Docker layer से वापस न आ जाए ।

6. GitHub और CI/CD environments का audit करें

नए बनाए गए repositories, अनधिकृत workflows, संदिग्ध commits और असामान्य publishing activity की जांच करें । शोधकर्ताओं ने .claude/settings.json और .vscode/tasks.json जैसे संभावित persistence artifacts को भी खोजने की सलाह दी है ।

इस हमले से सबसे बड़ी सीख

4 अगस्त 2026 का Shai-Hulud हमला दिखाता है कि एक ही maintainer account के compromise से JavaScript सप्लाई-चेन में संक्रमण कितनी तेजी से फैल सकता है। हमलावरों को हर प्रभावित पैकेज पर सीधे नियंत्रण की जरूरत नहीं थी; चुराए गए publishing tokens ने वर्म को एक namespace से दूसरे namespace तक पहुंचने में मदद की ।

वैध Bun runtime के जरिए payload चलाना, npm और GitHub tokens की मदद से self-propagation, तथा कई exfiltration channels का इस्तेमाल इस अभियान को विशेष रूप से प्रभावशाली बनाता है ।

डेवलपमेंट और सुरक्षा टीमों के लिए व्यावहारिक सबक स्पष्ट हैं: dependencies को pin करें, जहां संभव हो preinstall और postinstall scripts को सीमित करें, GitHub activity पर नजर रखें और सप्लाई-चेन compromise के लिए पहले से incident-response runbook तैयार रखें।