Shai-Hulud: सितंबर 2025 का npm वर्म और इंस्टॉल के समय भरोसे की सीमा

सितंबर 2025 के Shai-Hulud अभियान ने समझौता किए गए npm अनुरक्षक खातों और दुर्भावनापूर्ण postinstall हुक का उपयोग करके क्रेडेंशियल चुराए और अतिरिक्त संक्रमित पैकेज प्रकाशित किए।^[1]

💡 आसान भाषा में (ELI5)

मानिए किसी कारखाने को पुर्ज़ों का डिब्बा मिलता है जिसकी खोलने की हिदायतें अपने आप चलती हैं। वे कारखाने के माल भेजने वाले पहचान पत्रों की नक़ल बनाकर दूसरे कारखानों को बदले हुए डिब्बे भेजती हैं। अपने आप चलने वाली हिदायतें रोकने से यह रास्ता बंद होता है, पर पुर्ज़ों को उपयोग से पहले फिर भी जाँचना होगा।^[1]

इस पेज के मुख्य शब्द

Lifecycle hook: सितंबर के अभियान में npm postinstall ने स्थापना के दौरान दुर्भावनापूर्ण कोड चलाया। यह पैकेज का व्यवहार है, CVE वाला npm स्मृति दोष नहीं।
Publishing credential: npm टोकन में खाते या पैकेज के लिए तय अनुमतियाँ होती हैं। चुराई प्रकाशन अनुमति से वर्म फैला; अवधि, दायरा और MFA नीति पर निर्भर हैं।
Trusted publishing / OIDC: OIDC से अधिकृत CI प्रक्रिया संग्रहित npm टोकन के बिना अल्पकालीन प्रकाशन अधिकार ले सकती है। समझौता हुई अधिकृत प्रक्रिया फिर भी असुरक्षित है।

फ्रेमवर्क मैपिंग

इस गाइड में बताई गई कमजोरी के लिए CWE संदर्भ: CWE-506 CWE-829

घटना का समयक्रम (Timeline)

2025-09-14

GitHub के अनुसार उसे Shai-Hulud की सूचना मिली।^[1]

2025-09-22

GitHub ने 500 से अधिक संक्रमित पैकेज हटाने और दुर्भावनापूर्ण संकेतों वाले अपलोड रोकने की सूचना दी।^[1]

हमले का चरण-दर-चरण प्रवाह

चरण 1

समझौता हुआ प्रकाशन

अनुरक्षक खाते से बदला हुआ पैकेज प्रकाशित हुआ। फ़िशिंग पहली पहुँच का अनुमान था, हर प्रभावित खाते के लिए प्रमाणित कारण नहीं।^{[1], [2]}

चरण 2

स्थापना पर निष्पादन

सितंबर का postinstall डेवलपर या CI के अधिकार में चला। नवंबर के preinstall को पिछली लहर का हिस्सा नहीं मानना चाहिए।^{[1], [3], [2]}

चरण 3

क्रेडेंशियल जोखिम

दुर्भावनापूर्ण कोड ने सेटिंग और वातावरण में npm, GitHub और क्लाउड के क्रेडेंशियल खोजे; जोखिम प्रकाशन टोकन से बड़ा था।^{[1], [2]}

चरण 4

प्रसार

चुराए प्रकाशन अधिकार से पीड़ित द्वारा सँभाले दूसरे पैकेज भी बदलकर प्रकाशित किए जा सके।^{[1], [2]}

सोर्स कोड: कमज़ोर बनाम सुरक्षित कार्यान्वयन

यह Python में सुरक्षित स्थापना योजना की तुलना है: कोई फ़ंक्शन npm नहीं चलाता, क्रेडेंशियल नहीं पढ़ता और रजिस्ट्री से नहीं जुड़ता। उदाहरण npm v10 दस्तावेज़ पर आधारित है। सुरक्षित योजना जाँची हुई लॉकफ़ाइल माँगती है, जीवनचक्र स्क्रिप्ट रोकती है और पुराना वातावरण नहीं लेती। असल रनर में भरोसेमंद npm प्रोग्राम तथा अलग गृह निर्देशिका और विन्यास चाहिए, जिनमें गोपनीय फ़ाइल या संवेदनशील माउंट न हों। --ignore-scripts बाद में आयातित कोड या स्पष्ट रूप से चलाई गई स्क्रिप्ट सुरक्षित नहीं बनाता; लॉकफ़ाइल से कोड की अच्छाई प्रमाणित नहीं होती।

कमज़ोर कार्यान्वयन

def install_plan(reviewed_lockfile, inherited_env):
    # केवल योजना लौटाता है: कोई पैकेज इंस्टॉल या कमांड निष्पादित नहीं होती।
    return {"argv": ["npm", "ci"],
            "env": dict(inherited_env)}

सुरक्षित और सुदृढ़ फ़िक्स

def install_plan(reviewed_lockfile, inherited_env):
    # केवल योजना लौटाता है: कोई पैकेज इंस्टॉल या कमांड निष्पादित नहीं होती।
    if reviewed_lockfile is not True:
        raise ValueError("Review the lockfile before installation")
    return {"argv": ["npm", "ci", "--ignore-scripts"],
            "env": {}}

इंजीनियरिंग और सिस्टम सुरक्षा चेकलिस्ट

✓स्थापना कार्य में जाँची हुई लॉकफ़ाइल और npm ci --ignore-scripts आवश्यक करें; CI नीति परीक्षण आदेश और क्रेडेंशियल रहित वातावरण जाँचें। ज़रूरी निर्माण हुक समीक्षा के बाद अलग पृथक कार्य में चलाएँ।^[3]
✓प्रकाशन और क्लाउड क्रेडेंशियल निर्भरता स्थापित करने वाले कार्य से दूर रखें, जिनमें गृह फ़ाइलें, माउंट और रनर पहचान भी शामिल हैं। जाँचें कि कार्य प्रकाशन अधिकार न ले सके।^{[1], [2]}
✓जहाँ उपलब्ध हो विश्वसनीय प्रकाशन अपनाएँ; अधिकृत प्रक्रिया, शाखा और वातावरण सीमित कर बदलाव की समीक्षा करें। फ़िशिंग प्रतिरोधी MFA रखें और अप्रयुक्त टोकन हटाएँ।^[1]
✓पुष्ट खुलासे पर रनर अलग करके नए बनाएँ, उजागर क्रेडेंशियल रद्द करें और पैकेज संस्करण व प्रक्रिया बदलाव जाँचें। निर्भरता का कोड देखें: लॉकफ़ाइल या नई रिलीज़ अपनाने में देरी अकेले सुरक्षा सिद्ध नहीं करती।^{[1], [2]}