CI/CD सप्लाई चेन हमले: हमलावर आपकी पाइपलाइन तक कैसे पहुँचते हैं

एक घंटे में हमलावर आपकी पाइपलाइन के साथ क्या कर सकता है

अगर कोई एक घंटे के लिए आपके बिल्ड सिस्टम में घुस जाए, तो वह क्या ले सकता है और क्या बदल सकता है?

बिल्ड पाइपलाइन में घुसने के तीन रास्तों का वैचारिक चित्रण। यह किसी असली सिस्टम का आरेख नहीं है। चित्र के लेबल अंग्रेज़ी में हैं और चित्रण का हिस्सा हैं।

CI/CD पाइपलाइन वह स्वचालित रास्ता है जो आपके सॉफ़्टवेयर को बनाता, परखता और भेजता है। यह काम करने के लिए उसके पास आपका सोर्स कोड, दूसरे सिस्टम तक पहुँचने के लिए ज़रूरी सीक्रेट और डिप्लॉय करने का अधिकार होता है। यहाँ सीक्रेट का मतलब वह पासवर्ड, टोकन या कुंजी है जो किसी दूसरी सेवा को साबित करती है कि आप कौन हैं।

यह मेल पाइपलाइन को अच्छा निशाना बना देता है। जो हमलावर उस तक पहुँच जाए, उसे आपके एप्लिकेशन में सेंध लगाने की ज़रूरत ही नहीं पड़ती। वह कुंजियाँ ले सकता है, या बदल सकता है कि क्या भेजा जाएगा।

एक ही पखवाड़े में हुई तीन घटनाएँ दिखाती हैं कि यह कैसे होता है। वे अलग दिखती हैं, लेकिन एक ही जगह खत्म होती हैं। यह लेख हर घटना को बारी-बारी से समझाता है, फिर एक घंटे की जाँच देता है।

हमलावर पाइपलाइनों को निशाना क्यों बनाते हैं

पाइपलाइन पर डिज़ाइन से ही भरोसा किया जाता है। वह निजी कोड पढ़ सकती है, क्लाउड सेवाओं को बुला सकती है, पैकेज प्रकाशित कर सकती है, और उसके हर कदम पर कोई नज़र नहीं रखता। पाइपलाइन में रखा सीक्रेट अक्सर डेवलपर के लैपटॉप वाले सीक्रेट से ज़्यादा शक्तिशाली होता है।

सप्लाई चेन अटैक का मतलब है आपके सॉफ़्टवेयर पर सीधे हमला करने के बजाय उस चीज़ पर हमला करना जिस पर आपका सॉफ़्टवेयर निर्भर है। इस लेख में इसका मतलब है आपकी रिपॉज़िटरी की वर्कफ़्लो फ़ाइलें, आपका बिल्ड जो पैकेज इंस्टॉल करता है, और खुद CI सिस्टम। हमलावर उसी दरवाज़े से आता है जिसे आप पहले ही खोल चुके हैं।

इस चित्र का सुलभ टेक्स्ट विकल्प

पाइपलाइन बाएँ से दाएँ चलती है: कोड और वर्कफ़्लो फ़ाइलों वाली सोर्स रिपॉज़िटरी, इंस्टॉल, कंपाइल और टेस्ट करने वाला बिल्ड और टेस्ट चरण, और रजिस्ट्री, क्लाउड तथा क्लस्टर तक पहुँचने वाला डिप्लॉय चरण। टोकन, क्लाउड कुंजियाँ और पब्लिशिंग कुंजियाँ जैसे सीक्रेट बिल्ड वातावरण में रहते हैं।

तीन हमले अलग-अलग जगह घुसते हैं। हमला 1: चुराया गया टोकन रिपॉज़िटरी में नकली वर्कफ़्लो फ़ाइल जोड़ता है। हमला 2: भरोसेमंद पैकेज बिल्ड में इंस्टॉल के समय कोड चलाता है। हमला 3: खुद CI सिस्टम की खामी, जैसे GitLab या Argo CD, CI सर्वर पर भुनाई जाती है।

तीनों हमले सीक्रेट तक ले जाते हैं, इसीलिए बिल्ड वातावरण के सीक्रेट साझा निशाना हैं।

पैटर्न 1: चुराया गया टोकन नकली वर्कफ़्लो जोड़ता है (GhostAction)

GitHub Actions आपकी पाइपलाइन को रिपॉज़िटरी में .github/workflows/ के तहत रखी वर्कफ़्लो फ़ाइलों से चलाता है। जिसके पास रिपॉज़िटरी में लिखने की अनुमति है, वह कोई भी फ़ाइल जोड़ सकता है। GhostAction इसी कमज़ोरी का इस्तेमाल करता है।

इस अभियान की पहली रिपोर्ट September 2025 में आई थी। GitGuardian August 2026 की एक नई लहर गिनता है, और इस पखवाड़े की गतिविधि 8 और 9 October को चरम पर पहुँची।

StepSecurity के अनुसार हमलावरों ने रिपॉज़िटरियों में “Security Audit” या “Github Actions Security” नाम का एक वर्कफ़्लो जोड़ा। वह एक मददगार जाँच जैसा दिखता है। वह हर पुश पर चलता है और डेटा को पहले से तय सर्वर पते पर भेजता है।

पुराना संस्करण रिपॉज़िटरी के नाम वाले सीक्रेट भेजता था। October संस्करण इससे आगे गया। उसने वर्किंग फ़ाइलों और पूरी git हिस्ट्री में क्लाउड, AI-सेवा और सॉफ़्टवेयर-एज़-ए-सर्विस कुंजियों जैसे लगभग 13 तरह के क्रेडेंशियल खोजे। StepSecurity की सलाह साफ़ है: मौजूदा ब्रांच से सीक्रेट हटाने से कुछ नहीं होता, क्योंकि हिस्ट्री भी स्कैन होती है।

हमलावरों को लिखने की पहुँच कैसे मिली? StepSecurity कहता है कि October वाले खातों के लिए यह पुष्ट नहीं है। सबसे संभावित स्रोत क्रेडेंशियल चुराने वाले मैलवेयर या डेटा डंप से लीक हुए पर्सनल एक्सेस टोकन हैं। एक मामले में, समझौता किया गया खाता एक बड़ी कंपनी की रिपॉज़िटरी में लिख सकता था, इसलिए नया वर्कफ़्लो बिना समीक्षा के चला गया।

संख्याओं के दो समूह हैं, और वे अलग-अलग चीज़ें नापते हैं:

• StepSecurity ने 8 October को दो स्वीप में 345 रिपॉज़िटरियों के प्रभावित होने की गिनती की। 9 October को लगभग 378 रिपॉज़िटरियों में हानिकारक वर्कफ़्लो चालू था।
• GitGuardian अपने 13 October के अपडेट में कहता है कि लगभग 1,900 खातों से समझौता हुआ। वह कहता है कि 30,000 से ज़्यादा रिपॉज़िटरियों को निशाना बनाया गया और अभियान ने 3,174 सीक्रेट निकालने की कोशिश की। ये निशाने और कोशिशें हैं, पुष्ट चोरियाँ नहीं, और GitGuardian October में वास्तव में चुराए गए सीक्रेट की कोई गिनती नहीं देता।

GitGuardian यह भी बताता है कि GitHub ने 9 October से हानिकारक वर्कफ़्लो को रोकना शुरू किया, और 10 तथा 12 October की लहरों में कोई सीक्रेट नहीं निकला। यह GitGuardian की रिपोर्ट है, और इस पर यहाँ GitHub का कोई बयान उद्धृत नहीं किया गया है।

GitGuardian ने देखा कि कुछ पीड़ित 2025 और 2026 दोनों में प्रभावित हुए, जो बताता है कि पहली लहर के सीक्रेट कभी बदले नहीं गए। वह यह भी चेताता है कि चुराए गए सीक्रेट बदलना काफ़ी नहीं है। वर्कफ़्लो जोड़ने में इस्तेमाल हुआ GitHub क्रेडेंशियल ढूँढकर रद्द करना होगा, वरना कोई उसे दोबारा इस्तेमाल कर सकता है।

GitHub के पास अपनी सुरक्षाएँ भी हैं। July से, github.com की सार्वजनिक रिपॉज़िटरियों पर, बिना किसी सेटअप के, वह उन वर्कफ़्लो रन को रोककर रखता है जिन्हें वह संभावित रूप से हानिकारक मानता है, जब तक लिखने की अनुमति वाला कोई सहयोगी उन्हें मंज़ूर न कर दे। 17 September से आम तौर पर उपलब्ध उसकी वर्कफ़्लो निष्पादन सुरक्षाएँ आपको यह नियम तय करने देती हैं कि वर्कफ़्लो को कौन और क्या शुरू कर सकता है। ये मदद करती हैं, लेकिन वर्कफ़्लो फ़ाइलों में बदलावों की समीक्षा का विकल्प नहीं हैं।

पैटर्न 2: भरोसेमंद पैकेज इंस्टॉल करते समय कोड चलाता है (TensorLake)

ज़्यादातर पैकेज मैनेजर पैकेज इंस्टॉल होते समय एक छोटी स्क्रिप्ट चला सकते हैं। इन्हें इंस्टॉल स्क्रिप्ट कहते हैं। ये नेटिव कोड कंपाइल करने जैसे अच्छे कारणों से मौजूद हैं। ये आपके डेवलपर लैपटॉप और बिल्ड सर्वर पर भी चलती हैं, इससे पहले कि किसी ने देखा हो कि वे क्या करती हैं।

8 October को tensorlake पैकेज का वर्शन 0.5.144 npm पर दिखाई दिया। Aikido इसे Shai-Hulud वर्म के एक रूपांतर वाला बताता है, जो क्रेडेंशियल चुराने वाले मैलवेयर का वह परिवार है जो पहले भी देखा जा चुका है। StepSecurity इसे वर्म कहता है और वही व्यवहार बताता है। इसकी preinstall स्क्रिप्ट ने एक JavaScript रनटाइम डाउनलोड किया और एक छिपाया गया पेलोड चलाया। उस पेलोड ने एनवायरनमेंट वेरिएबल, क्लाउड और Kubernetes क्रेडेंशियल, SSH कुंजियाँ और ब्राउज़र डेटा खोजा।

रक्षकों के लिए दो बातें मायने रखती हैं।

पहली, पैकेज के पास एक वैध npm प्रोवेनेंस अटेस्टेशन था। प्रोवेनेंस एक हस्ताक्षरित रिकॉर्ड है जो बताता है कि पैकेज कहाँ और कैसे बना। StepSecurity बताता है कि हमलावरों ने अपना कोड एक मेंटेनर की पहचान से, बिना पुल रिक्वेस्ट के, सीधे main ब्रांच पर पुश किया।

फिर प्रोजेक्ट के अपने रिलीज़ वर्कफ़्लो ने पैकेज बनाया और प्रकाशित किया। प्रोवेनेंस ने सच बताया कि वह कहाँ बना। लेकिन वह यह नहीं बता सकता था कि कोड सुरक्षित है।

दूसरी, मैलवेयर में वह था जिसे StepSecurity “होस्टेज टोकन” कहता है। वह चुराए गए GitHub टोकन को हर 60 सेकंड में, 24 घंटे तक जाँचता है, और अगर GitHub टोकन को अस्वीकार कर दे तो होम डायरेक्टरी मिटा देता है। चोरी के बाद की आम सलाह है कि पहले टोकन रद्द करें, लेकिन यहाँ वही नुकसान शुरू कर सकता है।

StepSecurity की सलाह है कि कुछ भी रद्द करने से पहले, बैकअप लेने के बाद, मैलवेयर की मॉनिटर सर्विस हटाएँ।

बाकी सलाह सरल है। आख़िरी अच्छे वर्शन 0.5.143 पर पिन करें। इंस्टॉल स्क्रिप्ट बंद करें। उस मशीन की पहुँच वाले हर क्रेडेंशियल को बदलें, और जिस मशीन को आप साफ़ साबित नहीं कर सकते उसे दोबारा बनाएँ।

StepSecurity ने जब अपनी रिपोर्ट लिखी तब पाया कि वर्शन 0.5.144 अब भी डाउनलोड हो सकता था। npm रजिस्ट्री अब उस वर्शन को सूचीबद्ध नहीं करती (19 October को जाँचा गया), और पैकेज बाद की रिलीज़ तक आगे बढ़ चुका है।

अच्छी खबर भी है। GitHub ने 8 July 2026 को npm 12 आम तौर पर उपलब्ध कराया, जो इंस्टॉल स्क्रिप्ट को डिफ़ॉल्ट रूप से बंद रखता है और जब तक आप अनुमति न दें, git और रिमोट-URL डिपेंडेंसी को रोकता है। यह उस कदम को रोक देता है जिस पर यह हमला निर्भर था। यह तभी मदद करता है जब आपकी पाइपलाइन सच में npm 12 या उससे बाद का चलाती हो, पिन किए गए बिल्ड इमेज का कोई पुराना वर्शन नहीं।

पैटर्न 3: खुद CI सिस्टम में खामी (GitLab और Argo CD)

तीसरा पैटर्न अलग है। कोई पाइपलाइन को धोखा नहीं देता। पाइपलाइन चलाने वाले सॉफ़्टवेयर में ही बग है।

GitLab। 12 October को GitLab ने CVE-2026-97229 ठीक करने के लिए 19.4.2, 19.3.5 और 19.2.8 जारी किए। इसका गंभीरता स्कोर सबसे ऊँचा, CVSS 10.0 है। GitLab की एडवाइज़री का शीर्षक CI/CD कॉन्फ़िगरेशन में इस्तेमाल होने वाले रेगुलर एक्सप्रेशन कंपाइलर में इंटीजर ओवरफ़्लो बताता है, और GitLab कहता है कि कुछ शर्तों में यह बिना प्रमाणीकरण वाले उपयोगकर्ता को सर्वर पर कोड चलाने दे सकता है।

GitLab.com पहले ही पैच हो चुका है, और सभी GitLab Dedicated टेनेंट को रिलीज़ से पहले पैच कर दिया गया था। GitLab सेल्फ़-मैनेज्ड इंस्टॉलेशन को तुरंत अपग्रेड करने की पुरज़ोर सिफ़ारिश करता है।

स्कोर मानता है कि लॉगिन की ज़रूरत नहीं, लेकिन Rapid7 को एक शर्त मिली। हमलावर को किसी सार्वजनिक प्रोजेक्ट की एक ब्रांच पर एक तैयार की गई .gitlab-ci.yml फ़ाइल और विशेष रूप से नाम रखा गया रिपॉज़िटरी पाथ कमिट करने में सक्षम होना चाहिए। जिन इंस्टेंस में उपयोगकर्ताओं को सार्वजनिक प्रोजेक्ट बनाने की अनुमति है, वहाँ एक साधारण खाता यह शर्त पूरी कर सकता है।

Rapid7 ने बिना पैच वाले 19.4.1 पर कोड निष्पादन दोहराया और एक प्रूफ़ ऑफ़ कॉन्सेप्ट प्रकाशित किया। 16 October के उसके अपडेट तक, जंगल में किसी हमले की पुष्टि नहीं हुई थी।

Argo CD। Argo CD एक टूल है जो git रिपॉज़िटरी से Kubernetes पर एप्लिकेशन डिप्लॉय करता है। इसके मेंटेनरों ने 6 October को 3.5.4, 3.4.10 और 3.3.15 में फ़िक्स जारी किए। इनमें से एक समस्या CVE-2026-55797 है, जो SSH git रिपॉज़िटरी पर रिपॉज़िटरी प्रॉक्सी URL के ज़रिए repo server में कमांड इंजेक्शन है, और इसकी रेटिंग 8.8 है।

रिलीज़ नोट्स कुल आठ सुरक्षा फ़िक्स सूचीबद्ध करते हैं, जिनमें चार क्रिटिकल रेटिंग वाले हैं। इनमें repository server पर कमांड चलाने या फ़ाइलें पढ़ने के तरीके, और प्रोजेक्ट प्रतिबंधों को पार करने का एक तरीका शामिल है। इनमें से किसी के लिए हमलों की रिपोर्ट नहीं है। अगर आप Argo CD चलाते हैं, तो रिलीज़ नोट्स पढ़ें और अपग्रेड करें।

इनमें से कोई भी हमलों का सबूत नहीं है। ये इसलिए मायने रखते हैं कि आपकी पाइपलाइन चलाने वाले सिस्टमों के पास वही शक्तियाँ होती हैं जो आपकी पाइपलाइन के पास होती हैं।

तीनों पैटर्न में क्या समान है

हर हमले ने अलग रास्ता लिया। GhostAction चुराए गए टोकन और वर्कफ़्लो फ़ाइल से आया। TensorLake उस पैकेज से आया जो आपका बिल्ड इंस्टॉल करता है। GitLab और Argo CD प्लेटफ़ॉर्म से आते।

हर एक बिल्ड वातावरण में रखे सीक्रेट पर खत्म होता है। वही साझा बिंदु है। एप्लिकेशन कोड की रक्षा के लिए बने नियंत्रण, जैसे कोड समीक्षा और आपकी निर्भरताओं के वल्नरेबिलिटी स्कैन, अपने आप उस बिंदु को कवर नहीं करते। पाइपलाइन को अपनी सुरक्षा चाहिए।

आपको कितना जानना चाहिए

जानें। हर डेवलपर को समझना चाहिए कि पाइपलाइन एक निशाना है, सीक्रेट क्या होता है, और पैकेज इंस्टॉल कोड क्यों चला सकता है। आपको कुछ कॉन्फ़िगर करने की ज़रूरत नहीं।

इस्तेमाल करें। वर्कफ़्लो लिखने या समीक्षा करने वाले प्लेटफ़ॉर्म और DevOps इंजीनियरों को व्यावहारिक कौशल चाहिए। ये हैं टोकन अनुमतियाँ सीमित करना, वर्कफ़्लो फ़ाइलों की रक्षा करना, इंस्टॉल स्क्रिप्ट बंद करना, बिल्ड रनर से नेटवर्क पहुँच सीमित करना, और सीक्रेट सही क्रम में बदलना।

गहराई से सीखें। पाइपलाइन सुरक्षा के मालिकों को विफलता के लिए डिज़ाइन करना होगा। वे तय करते हैं कि सीक्रेट कैसे जारी होते हैं, कितने समय तक चलते हैं, और समझौता हुए बिल्ड को कैसे सीमित करके दोबारा बनाया जाएगा।

एक घंटे की जाँच

इसका ज़्यादातर हिस्सा आप एक घंटे में कर सकते हैं। उन चीज़ों से शुरू करें जिनमें कुछ खर्च नहीं होता।

1. जाँचें कि वर्कफ़्लो फ़ाइलें कौन बदल सकता है। पक्का करें कि .github/workflows/ में बदलावों के लिए समीक्षा ज़रूरी हो, जैसे कोड ओनर्स नियम और ब्रांच प्रोटेक्शन से। यह देखने के लिए कि वर्कफ़्लो फ़ाइलें कब जोड़ी गईं, git log --all --diff-filter=A --name-only -- .github/workflows चलाएँ। ऐसे नाम देखें जिन्हें आप नहीं पहचानते, जैसे आपके बिना माँगा हुआ कोई “security audit”।
2. टोकन का दायरा जाँचें। सबसे कम जीवनकाल और सबसे कम रिपॉज़िटरियों वाले फ़ाइन-ग्रेन्ड टोकन इस्तेमाल करें। वर्कफ़्लो टोकन के लिए डिफ़ॉल्ट permissions केवल-पढ़ने पर रखें और केवल वहीं बढ़ाएँ जहाँ किसी जॉब को ज़्यादा चाहिए।
3. इंस्टॉल स्क्रिप्ट जाँचें। अपनी पाइपलाइन जिस इमेज में चलती है उसी में npm --version चलाएँ। अगर वह 12 से पुराना है, तो .npmrc में ignore-scripts=true रखें और केवल उन्हीं पैकेजों को अनुमति दें जिन्हें सच में स्क्रिप्ट चाहिए।
4. जाँचें कि बिल्ड कहाँ तक पहुँच सकता है। अगर आपके रनर इंटरनेट पर किसी भी पते पर डेटा भेज सकते हैं, तो चुराया गया सीक्रेट आसानी से बाहर चला जाता है। केवल वही गंतव्य अनुमति दें जिनकी बिल्ड को ज़रूरत है।
5. अपना बदलाव क्रम जानें। अगर आपको बदलना पड़े, तो पहले उन क्रेडेंशियल से शुरू करें जो प्रकाशित या डिप्लॉय कर सकते हैं (पैकेज रजिस्ट्री, कंटेनर रजिस्ट्री, क्लाउड डिप्लॉय रोल), फिर क्लाउड और क्लस्टर पहुँच, फिर बाकी सब। हानिकारक पैकेज के बाद, पहले विक्रेता के हटाने के चरण पढ़ें।
6. अपना खुद का CI सिस्टम जाँचें। अगर आप GitLab या Argo CD खुद चलाते हैं, तो पक्का करें कि आप ठीक किए गए वर्शन पर हैं।

फ़िलहाल आप क्या अनदेखा कर सकते हैं

आपको हर प्रूफ़ ऑफ़ कॉन्सेप्ट का पीछा करने या हर मैलवेयर परिवार की अंदरूनी बातें सीखने की ज़रूरत नहीं। ब्योरे हफ़्ते-दर-हफ़्ते बदलते हैं, लेकिन ऊपर की जाँचें नहीं बदलतीं।

आपको TensorLake की वजह से प्रोवेनेंस जाँचें छोड़ने की भी ज़रूरत नहीं। वे बताती हैं कि पैकेज कहाँ बना, जो अब भी उपयोगी है। बस उन्हें इस बात का बयान न मानें कि कोड सुरक्षित है।

आगे क्या करें

एक रिपॉज़िटरी चुनें और चेकलिस्ट पर चलें। वर्कफ़्लो-फ़ाइल समीक्षा और टोकन के दायरे से शुरू करें, क्योंकि उनमें कुछ खर्च नहीं होता और वे GhostAction में इस्तेमाल हुआ दरवाज़ा बंद करते हैं।

अगर आप अपने सेटअप के बारे में इस हफ़्ते केवल एक चीज़ पढ़ें, तो यह पता करें कि आपका बिल्ड कौन से सीक्रेट तक पहुँच सकता है और वे कितने पुराने हैं।

पाइपलाइन आपकी हमला-सतह का हिस्सा है। उसकी रक्षा प्रोडक्शन की तरह करें।

और गहराई में

• StepSecurity, GhostAction Returns
• GitGuardian, GhostAction Returns
• GitHub, GitHub Actions holds potentially malicious workflows for approval और Workflow execution protections generally available
• Aikido, tensorlake NPM package compromised with Shai Hulud worm
• StepSecurity, Tensorlake npm package compromised: a worm with a hostage token
• GitHub, npm install-time security and GAT bypass-2FA deprecation
• GitLab, Critical patch release 19.4.2, 19.3.5, 19.2.8
• Rapid7, CVE-2026-97229: Critical unauthenticated remote code execution in GitLab
• Argo CD, v3.5.4 release notes और advisory GHSA-j6cw-g6p4-7hch
• npm, tensorlake package metadata, जहाँ वर्शन 0.5.144 अब सूचीबद्ध नहीं है (19 October 2026 को जाँचा गया)

संबंधित पठन के लिए, पाइपलाइनों को प्रभावित करने वाले एक और प्लेटफ़ॉर्म बदलाव को समझाने वाला GitHub Actions बदल रहा है: DevOps टीमों को क्या जानना चाहिए देखें।