wfx-loot क्रेडेंशियल चुराने का एक अभियान था। इसमें हमलावरों ने हैक किए गए GitHub खातों से रिपॉज़िटरी की जाँच की और जहाँ उन खातों को बदलाव करने की अनुमति मिली, वहाँ ऐसा कोड डाला जिसका मकसद लगातार एकीकरण (CI) के माहौल से गोपनीय जानकारी चुराना था। Aikido के मुताबिक, 4,837 खातों से 61,764 रिपॉज़िटरी में जाँच के लिए पुल रिक्वेस्ट भेजी गईं। उसकी प्रकाशित गिनती में कम-से-कम 1,835 रिपॉज़िटरी ऐसी थीं जहाँ पेलोड चला और क्रेडेंशियल बाहर भेजे गए।
4
9
wfx-loot कब हुआ और कितने समय चला?
यह गतिविधि 10 नवंबर 2026 को लगभग 12:45 UTC पर शुरू हुई। एक रिपोर्ट के अनुसार, जाँच वाली पुल रिक्वेस्ट 11 नवंबर को 15:00 UTC तक आती रहीं—यानी करीब 26 घंटे 15 मिनट।
6
7 यह जाँच का दर्ज किया गया समय है; इससे यह साबित नहीं होता कि पेलोड की सारी गतिविधि या चुराए गए क्रेडेंशियल का बाद का इस्तेमाल भी उसी समय रुक गया था।
अभियान से जुड़ी अलग-अलग संख्याएँ हमले के अलग-अलग चरण बताती हैं:
- 4,837 खाते हैक हुए बताए गए।
- 61,764 रिपॉज़िटरी में जाँच के लिए पुल रिक्वेस्ट भेजी गईं। यह उन रिपॉज़िटरी की संख्या है जिन्हें परखा गया—यह नहीं कि हर जगह मैलवेयर चला।
- Aikido की प्रकाशित गिनती के मुताबिक कम-से-कम 1,835 रिपॉज़िटरी में पेलोड चला और क्रेडेंशियल बाहर भेजे गए।
9
उसी समय की कुछ रिपोर्टों में इससे कम, 1,806 का आँकड़ा दिया गया था।
6
10 उपलब्ध रिपोर्टें इस अंतर की वजह नहीं बतातीं, इसलिए इन आँकड़ों को अलग-अलग प्रकाशित गिनतियों के रूप में देखना चाहिए, न कि जोड़कर या एक मानकर। उपलब्ध रिपोर्टिंग बाद में सामने आए इस दावे की भी पुष्टि नहीं करती कि 66,000 से ज़्यादा लक्ष्यों में करीब 1,970 सार्वजनिक मामलों की पुष्टि हुई थी।
हमलावरों ने पहुँच की जाँच कैसे की?
हमलावरों ने docs: dependency audit notes शीर्षक वाली पुल रिक्वेस्ट wfx-docs नाम की शाखाओं से खोलीं। इन रिक्वेस्ट का मकसद यह परखना था कि चोरी हुए खाते को संबंधित रिपॉज़िटरी में बदलाव करने की अनुमति है या नहीं।
3
4
9
जहाँ ऐसी अनुमति थी, वहाँ हमलावरों ने CI माहौल में क्रेडेंशियल चुराने वाला पेलोड डाला। अभियान में GitHub Actions की किसी सुरक्षा खामी के बजाय चोरी हुए वैध क्रेडेंशियल का इस्तेमाल हुआ।
4
9 OX Security ने मैलवेयर को लगभग 1,500 पंक्तियों की एक शेल स्क्रिप्ट बताया।
31
कुछ मामलों में दुर्भावनापूर्ण बदलाव और वर्कफ़्लो लॉग मिटा दिए गए, जिससे जाँच मुश्किल हो सकती थी।
1
6 उपलब्ध जानकारी जाँच, पेलोड चलाने और गतिविधि छिपाने के इस आम तरीके का समर्थन करती है; लेकिन इससे यह साबित नहीं होता कि हर मामले में तैनाती का एक ही तरीका या कमिट संदेश इस्तेमाल हुआ।
पेलोड किन चीज़ों को निशाना बना रहा था?
रिपोर्टों के मुताबिक, इसका मकसद CI जॉब को उपलब्ध क्रेडेंशियल हासिल करना था—जिनमें GitHub Actions के सीक्रेट और क्लाउड क्रेडेंशियल शामिल थे। AI सेवाओं के टोकन हासिल करने की कोशिशों का भी ज़िक्र है।
3
9 OX Security के विश्लेषण में AWS, Azure और Google Cloud के क्रेडेंशियल भी निशाने पर बताए गए हैं।
31 अलग-अलग रिपोर्टों के अनुसार, मैलवेयर रनर प्रोसेस की मेमोरी में भी सीक्रेट खोज सकता था; हालांकि उपलब्ध अंश यह नहीं बताते कि यह तरीका कितनी बार सफल हुआ।
17
29
एक उपलब्ध सारांश में AWS की ट्रस्ट पॉलिसी में बदलाव और Azure के फ़ेडरेटेड क्रेडेंशियल के ज़रिए पहुँच बढ़ाने की कोशिशों का उल्लेख है।
5 इसे रिपोर्ट किया गया व्यवहार समझें—इससे यह साबित नहीं होता कि हर प्रभावित रिपॉज़िटरी या हर क्लाउड खाते में बदलाव किया गया। उपलब्ध साक्ष्य का केंद्र क्रेडेंशियल की चोरी है; इससे सोर्स कोड या ग्राहक डेटाबेस की चोरी साबित नहीं होती।
9
15
रिपोर्ट किए गए संकेत क्या बताते हैं—और क्या नहीं?
एक रिपोर्ट के मुताबिक, सहयोगी या संगठन की पहुँच के ज़रिए भेजी गई 10,431 जाँच-पुल रिक्वेस्ट में से 92% जाँच के समय खुली थीं।
10
19 इससे संकेत मिलता है कि तब तक कई रिक्वेस्ट पर कार्रवाई नहीं हुई थी; लेकिन यह साबित नहीं होता कि किसी रिपॉज़िटरी के मालिक या सुरक्षा टीम ने उन्हें देखा ही नहीं था। यह प्रतिशत सभी पुल रिक्वेस्ट पर लागू नहीं होता।
एक जाँच-पुस्तिका ने Fly.io GitHub App के ज़रिए टोकन इस्तेमाल करने वाले 19 खातों से आई 173 जाँच-पुल रिक्वेस्ट का भी ज़िक्र किया। यह अपने आप में न तो Fly.io के ढाँचे में सेंध का प्रमाण है, न ही यह साबित करता है कि उन टोकन से पहुँची हर रिपॉज़िटरी में पेलोड चला।
37
सुरक्षा टीमों को क्या जाँचना चाहिए?
अगर आपके संगठन पर असर पड़ने की आशंका है, तो अपनी जाँच में जाँच हुई, पेलोड डाला गया, पेलोड चला और क्रेडेंशियल बाहर भेजे गए—इन चरणों को अलग-अलग दर्ज करें। ये एक ही बात नहीं हैं।
- जाँच के संकेत खोजें। उन रिपॉज़िटरी में
docs: dependency audit notes शीर्षक वाली पुल रिक्वेस्ट और wfx-docs नाम की शाखाएँ देखें जहाँ आपके खातों को बदलाव करने की अनुमति थी।
9
- CI और ऑडिट रिकॉर्ड देखें। वर्कफ़्लो रन, कमिट, शाखा गतिविधि और उपलब्ध क्लाउड लॉग की जाँच करें। वर्कफ़्लो रन नंबरों में खाली जगह ध्यान देने लायक संकेत हो सकती है, क्योंकि रिपोर्टों में रन और लॉग मिटाए जाने का ज़िक्र है; लेकिन सिर्फ़ यह अंतर सेंध का प्रमाण नहीं है।
1
24
- संदिग्ध पहुँच रद्द करें। जिन GitHub टोकन के चोरी होने की आशंका हो, उन्हें रद्द करें। खातों, सहयोगियों और GitHub App की पहुँच भी जाँचें।
- उजागर हुए सीक्रेट बदलें। अगर पेलोड चला था, तो उस वर्कफ़्लो को उपलब्ध सभी सीक्रेट और क्लाउड भूमिकाओं को संभावित रूप से प्रभावित मानें—सिर्फ़ वे क्रेडेंशियल नहीं जो बचे हुए लॉग में दिख रहे हों।
3
9
- क्लाउड में टिके रहने के संकेत खोजें। AWS की अनपेक्षित ट्रस्ट-पॉलिसी और Azure ऐप्लिकेशन या फ़ेडरेटेड क्रेडेंशियल में संदिग्ध बदलावों के साथ-साथ अनधिकृत कुंजियों और पहुँच में हुए दूसरे बदलावों की जाँच करें।
5
- सबूत सुरक्षित रखें। सफ़ाई के बदलाव करने से पहले बचे हुए ऑडिट रिकॉर्ड और लॉग सहेजें। फिर दर्ज करें कि हमले के किस चरण की पुष्टि उपलब्ध साक्ष्य से होती है।