TeamPCP ने Shai‑Hulud सप्लाई‑चेन वर्म का सोर्स कोड ओपन‑सोर्स किया

सबसे खास बात यह थी कि यह हमला सिर्फ एक पैकेज तक सीमित नहीं रहा—मैलवेयर ने खुद को आगे फैलाने की क्षमता दिखाई, जिससे यह वर्म‑जैसे व्यवहार वाला सप्लाई‑चेन अटैक बन गया।

MIT लाइसेंस के साथ कोड जारी करना क्यों बड़ा मामला है

आम तौर पर हमलावर अपने मैलवेयर को गुप्त रखते हैं। लेकिन Shai‑Hulud का कोड MIT लाइसेंस के साथ जारी किया गया, जो सबसे उदार ओपन‑सोर्स लाइसेंसों में से एक है। इसका मतलब है कि लगभग कोई भी व्यक्ति इस कोड को कॉपी, संशोधित या दोबारा उपयोग कर सकता है।

इसका असर दो दिशाओं में पड़ता है:

सुरक्षा विशेषज्ञों के लिए फायदे

• वास्तविक कोड देखकर सटीक डिटेक्शन नियम (YARA, Sigma आदि) बनाना आसान
• सैंडबॉक्स में हमले का व्यवहार परीक्षण करना
• CI/CD सुरक्षा सिस्टम की जांच कि वे ऐसे हमले पकड़ पाते हैं या नहीं

हमलावरों के लिए जोखिम

• नए हमलावरों के लिए प्रवेश बाधा कम हो जाती है
• कोई भी कोड में बदलाव कर नए पैकेज इकोसिस्टम या प्लेटफॉर्म को निशाना बना सकता है
• हमले के नए वेरिएंट जल्दी सामने आ सकते हैं

यानी एक वास्तविक साइबर हमले की तकनीक अब सार्वजनिक “ब्लूप्रिंट” बन चुकी है।

Shai‑Hulud वर्म की प्रमुख क्षमताएँ

सुरक्षा विश्लेषणों के अनुसार यह वर्म कई उन्नत सप्लाई‑चेन तकनीकों का संयोजन करता है।

CI/CD पाइपलाइन से OIDC टोकन चोरी

इस वर्म की सबसे महत्वपूर्ण क्षमताओं में से एक है CI/CD पाइपलाइन से OpenID Connect (OIDC) टोकन निकालना, खासकर GitHub Actions जैसे ऑटोमेशन वर्कफ़्लो से।

इन टोकनों का उपयोग कर हमलावर वैध पब्लिशिंग प्रक्रिया का फायदा उठाते हुए मैलिशियस पैकेज सीधे आधिकारिक चैनलों से जारी कर सकते हैं।

वैध provenance के साथ दुर्भावनापूर्ण पैकेज

हमले में एक और महत्वपूर्ण पहलू यह था कि संक्रमित पैकेजों को SLSA Build Level 3 provenance attestations के साथ प्रकाशित किया गया। इसका मतलब यह था कि वे पैकेज भरोसेमंद बिल्ड पाइपलाइन से आए हुए लगते थे।

इससे कई स्वचालित सुरक्षा जांच प्रणालियों को धोखा मिल गया।

डेवलपर सिस्टम से क्रेडेंशियल चोरी

पैकेज इंस्टॉल होने के बाद वर्म एक क्रेडेंशियल‑स्टीलिंग पेलोड सक्रिय करता है जो डेवलपर सिस्टम और CI वातावरण से संवेदनशील जानकारी इकट्ठा करता है। संभावित लक्ष्य शामिल थे:

• AWS और अन्य क्लाउड क्रेडेंशियल्स
• SSH प्राइवेट की
• npm और PyPI पब्लिशिंग टोकन
• GitHub personal access tokens
• Kubernetes और HashiCorp Vault सीक्रेट्स

कुछ रिपोर्टों के अनुसार मैलवेयर 100 से अधिक संभावित क्रेडेंशियल स्टोरेज पाथ स्कैन करता था।

पैकेज इकोसिस्टम में स्वयं फैलना

चुराए गए टोकन और पब्लिशिंग वर्कफ़्लो का उपयोग करके वर्म नए पैकेजों में खुद को इंजेक्ट कर सकता था। इससे npm और PyPI जैसे इकोसिस्टम में स्वचालित रूप से फैलने वाली चेन‑रिएक्शन संक्रमण की स्थिति बन सकती थी।

संभावित “Dead‑Man’s Switch” या वाइपर

कुछ सुरक्षा विश्लेषणों में यह भी बताया गया है कि वर्म में एक विनाशकारी फेल‑सेफ या वाइपर घटक भी हो सकता है। यानी कुछ स्थितियों में यह संक्रमित सिस्टम के डेटा को नष्ट कर सकता है।

इस वजह से विशेषज्ञ सलाह देते हैं कि संक्रमित डेवलपर वातावरण को पूरी तरह से समझौता हुआ सिस्टम मानकर ही जांच की जाए।

TeamPCP के पहले के हमलों से संबंध

मई 2026 का यह हमला अचानक नहीं हुआ था। इससे पहले भी TeamPCP को सप्लाई‑चेन हमलों से जोड़ा गया है।

Cloud Security Alliance के शोध के अनुसार 29–30 अप्रैल 2026 के बीच npm, PyPI और Packagist में एक और हमला हुआ था जिसमें लगभग 1,800 रिपॉजिटरी प्रभावित हुई थीं।

दोनों अभियानों की तुलना से हमले की तकनीक का विकास दिखाई देता है:

• शुरुआती हमलों में चोरी किए गए registry टोकनों का उपयोग हुआ
• बाद के हमलों में CI/CD पब्लिशिंग पाइपलाइन को ही हाईजैक किया गया
• Shai‑Hulud संस्करण में स्वयं फैलने वाला वर्म व्यवहार जोड़ा गया

डेवलपर्स और सुरक्षा टीमों के लिए तात्कालिक जोखिम

अगर किसी संगठन ने 11 मई 2026 के आसपास प्रभावित पैकेज इंस्टॉल किए हैं, तो खतरा सिर्फ उस पैकेज तक सीमित नहीं है।

सुरक्षा मार्गदर्शन के अनुसार ऐसे किसी भी सिस्टम को संभावित रूप से समझौता हुआ वातावरण मानना चाहिए क्योंकि वर्म क्रेडेंशियल चोरी कर सकता है और CI/CD सिस्टम में स्थायी पहुँच बना सकता है।

यह घटना यह भी दिखाती है कि सिर्फ signed builds या provenance प्रमाण पर्याप्त सुरक्षा की गारंटी नहीं देते, यदि भरोसेमंद बिल्ड पाइपलाइन ही हाईजैक हो जाए।

संगठनों को तुरंत क्या करना चाहिए

संभावित जोखिम की जांच करते समय सुरक्षा टीमों को कुछ प्राथमिक कदम लेने चाहिए:

• 11 मई 2026 के बाद इंस्टॉल या बिल्ड हुए सभी npm और PyPI निर्भरताओं की पहचान करें।
• प्रोजेक्ट्स को साफ वातावरण और सुरक्षित lockfiles से दोबारा rebuild करें।
• सभी डेवलपर, क्लाउड, CI/CD और पैकेज‑रजिस्ट्री क्रेडेंशियल्स को तुरंत rotate करें।
• GitHub Actions या अन्य CI वर्कफ़्लो में अनधिकृत बदलाव और संदिग्ध publish घटनाओं का ऑडिट करें।
• पैकेज पब्लिशिंग को सुरक्षित runners और सीमित OIDC अनुमतियों तक सीमित करें।

साथ ही संगठनों को नए वेरिएंट के लिए निगरानी बढ़ानी चाहिए, क्योंकि वर्म का सोर्स कोड सार्वजनिक होने से कॉपीकैट हमलों की संभावना बढ़ जाती है।

सप्लाई‑चेन सुरक्षा के लिए चेतावनी संकेत

Shai‑Hulud घटना ने एक महत्वपूर्ण बदलाव उजागर किया है: हमलावर अब सिर्फ कमजोर सॉफ़्टवेयर लाइब्रेरी नहीं, बल्कि पूरे डेवलपर वर्कफ़्लो और ऑटोमेशन सिस्टम को निशाना बना रहे हैं।

GitHub पर वर्म का कोड सार्वजनिक होने के बाद यह घटना सिर्फ एक साइबर हमला नहीं रह गई—यह अब एक तकनीकी उदाहरण बन चुकी है, जिसे समझना और उसके खिलाफ बचाव बनाना पूरे सॉफ्टवेयर उद्योग के लिए जरूरी होगा।