आपका IDE प्लगइन मार्केटप्लेस अब एक AI क्रेडेंशियल जोखिम है: JetBrains अभियान बिल्डर्स को क्या सिखाता है

सत्तर हजार इंस्टॉलेशन। यह वह पैमाना है जिस पर कम से कम 15 दुर्भावनापूर्ण प्लगइन JetBrains Marketplace में फैल गए, इससे पहले कि शोधकर्ताओं ने इस अभियान को दस्तावेज़ीकृत किया — यह जानकारी BleepingComputer की जून 2026 की रिपोर्टिंग के अनुसार है। ये प्लगइन स्पष्ट जाल नहीं थे। ये उस तरह के टूल के रूप में प्रस्तुत किए गए थे जिन्हें AI-संचालित उत्पादकता के लिए कोई भी डेवलपर स्वाभाविक रूप से इंस्टॉल करता: कोडिंग असिस्टेंट, कोड-रिव्यू यूटिलिटी, Git हेल्पर। यहाँ की सीख केवल यह नहीं है कि सॉफ़्टवेयर इकोसिस्टम में बुरी चीज़ें मौजूद हैं। असली बात यह है कि डेवलपर्स जो वर्कफ़्लो AI-संचालित काम को तेज़ करने के लिए उपयोग करते हैं, वह संरचनात्मक रूप से उसी वर्कफ़्लो के समान है जो उनकी क्रेडेंशियल्स को उजागर करता है — और इस संरचना को समझना ही आपको अधिक सावधानी से निर्माण करने देता है।

एक्सफ़िल्ट्रेशन मैकेनिज्म कैसे काम करता था

Aikido Security ने इस अभियान की पहचान की और इसके तंत्र को विस्तार से दस्तावेज़ीकृत किया। दुर्भावनापूर्ण प्लगइन में ऐसा लॉजिक था जो एक एकल, विशिष्ट उपयोगकर्ता क्रिया पर सक्रिय होता था: प्लगइन के सेटिंग्स डायलॉग में AI API क्रेडेंशियल्स दर्ज करने के बाद "Apply" पर क्लिक करना। उसी क्षण, की को HTTP के ज़रिए IP पते 39.107.60[.]51 पर एक सर्वर को भेजा जाता था, जो प्लगइन के अंदर हार्डकोड किया हुआ था। BleepingComputer की जांच के SOC Defenders के सारांश के अनुसार, यह डिज़ाइन किसी भ्रम की स्थिति में नहीं था; एक्सफ़िल्ट्रेशन ठीक उसी क्षण को निशाना बनाता था जब एक डेवलपर स्वाभाविक रूप से यह मान लेता कि उनकी क्रेडेंशियल्स उनके IDE कॉन्फ़िगरेशन में स्थानीय रूप से सेव हो रही हैं।

यह अभियान अक्टूबर 2025 से सक्रिय था, और नए प्लगइन जून 2026 तक भी सामने आते रहे — जो मार्केटप्लेस पर लगभग सात विक्रेता खातों में फैले हुए थे। कई खातों का उपयोग करने का मतलब था कि अलग-अलग प्लगइन हटाने से ऑपरेशन निष्प्रभावी नहीं हुआ, क्योंकि वही लोग किसी अलग खाता नाम के तहत दोबारा प्रकाशित कर सकते थे।

वह सप्लाई-चेन पहलू जो बिल्डर्स को समझना चाहिए

इस अभियान की शिक्षाप्रद बात यह नहीं है कि दुर्भावनापूर्ण सॉफ़्टवेयर मौजूद है; बल्कि यह है कि ये प्लगइन कहाँ काम कर रहे थे। IDE प्लगइन मार्केटप्लेस एक विश्वसनीय इन्फ्रास्ट्रक्चर है। डेवलपर्स मार्केटप्लेस लिस्टिंग पर अंतर्निहित भरोसा उस तरह करते हैं जैसे वे किसी रैंडम डाउनलोड लिंक पर नहीं करते — और यही वह भरोसा था जिस पर यह अभियान निर्भर था।

IDE एक्सटेंशन सुरक्षा पर Knostic का विश्लेषण इसे सीधे तौर पर बताता है: IDE एक्सटेंशन डेवलपमेंट एनवायरनमेंट में एक विशेषाधिकार प्राप्त स्थान रखते हैं, जिसमें कॉन्फ़िगरेशन फ़ाइलों, क्रेडेंशियल्स और नेटवर्क एग्रेस तक पहुँच होती है — जो अधिकांश अन्य सॉफ़्टवेयर श्रेणियों को बिना स्पष्ट अनुमति के नहीं मिलती।

वही प्लगइन आर्किटेक्चर जो AI कोडिंग असिस्टेंट को वास्तव में उपयोगी बनाता है — प्रोजेक्ट फ़ाइलों और सेटिंग्स के साथ गहरा एकीकरण — वही इन दुर्भावनापूर्ण लिस्टिंग को खतरनाक बनाता था। यह एक संरचनात्मक अवलोकन है, न कि टूलिंग से बचने का कारण; यह एक कारण है कि आप मार्केटप्लेस लिस्टिंग पर वही जाँच-पड़ताल लागू करें जो आप अपने पैकेज मेनिफेस्ट में किसी डिपेंडेंसी पर करते हैं।

JetBrains की घटना अकेले नहीं हुई। The Hacker News ने जनवरी 2026 में दुर्भावनापूर्ण VS Code AI एक्सटेंशन पर रिपोर्ट किया जिनमें 1.5 मिलियन इंस्टॉल हो चुके थे और जो डेवलपर सोर्स कोड चुरा रहे थे। Netwrix ने मई 2026 में विश्लेषण प्रकाशित किया जिसमें बताया गया कि AI डेस्कटॉप असिस्टेंट और कोडिंग टूल में क्रेडेंशियल स्टोरेज जोखिम हैं जो पारंपरिक क्रेडेंशियल हाइजीन समस्याओं से अलग हैं — क्योंकि इसमें शामिल क्रेडेंशियल्स (AI प्रोवाइडर API कीज़) सीधे वित्तीय जोखिम उठाती हैं और इनका उपयोग केवल डेवलपर के स्थानीय एनवायरनमेंट के बजाय AI प्रोवाइडर के इन्फ्रास्ट्रक्चर से डेटा एक्सफ़िल्ट्रेट करने के लिए किया जा सकता है।

बिल्डर्स अभी क्या कर सकते हैं

यहाँ व्यावहारिक दायित्व सीधे हैं, भले ही उनके आसपास का अनुपालन रुख अभी भी बन रहा हो। जांच के SOC Defenders के सारांश में तीन तत्काल कार्रवाइयाँ बताई गई हैं: अपने IDE एनवायरनमेंट से किसी भी संदिग्ध प्लगइन को हटाएं, अपने AI प्रोवाइडर खातों के विरुद्ध अनधिकृत API की उपयोग की निगरानी करें, और थर्ड-पार्टी प्लगइन इंस्टॉलेशन को एक सुविधा निर्णय के बजाय सप्लाई-चेन निर्णय के रूप में मानें।

वह तीसरा बिंदु स्थायी महत्व का है। यह ऑडिट करना कि कौन से प्लगइन आपके IDE में क्रेडेंशियल एंट्री पॉइंट तक पहुँच रखते हैं, पब्लिशर खाता इतिहास जाँचना, और सत्यापन योग्य संगठनात्मक पहचान वाले विक्रेताओं के प्लगइन को प्राथमिकता देना — ये कोई असाधारण सुरक्षा उपाय नहीं हैं; ये वही उचित-परिश्रम के कदम हैं जो सॉफ़्टवेयर टीमें ओपन-सोर्स डिपेंडेंसी पर पहले से ही लागू करती हैं।

AI APIs पर व्यावसायिक रूप से निर्माण करने वाली टीमों के लिए, क्रेडेंशियल प्रबंधन का निहितार्थ स्पष्ट रूप से कहने योग्य है। एक API की जो किसी प्लगइन के सेटिंग्स डायलॉग में दर्ज की गई और HTTP पर एक्सफ़िल्ट्रेट की गई, वह एक ऐसी की है जिसे आपका AI प्रोवाइडर वैध उपयोग से अलग नहीं कर सकता। किसी भी प्लगइन ऑडिट के बाद कीज़ रोटेट करना, कीज़ को न्यूनतम आवश्यक अनुमतियों तक सीमित करना, और जहाँ टूलिंग इसका समर्थन करे वहाँ IDE सेटिंग्स डायलॉग के बजाय एनवायरनमेंट वेरिएबल या सीक्रेट्स मैनेजर का उपयोग करना — ये भविष्य के किसी भी एक्सपोज़र के प्रभाव क्षेत्र को कम करते हैं।

इसके लिए किसी मार्केटप्लेस की वेटिंग प्रक्रिया में सुधार का इंतज़ार करने की ज़रूरत नहीं है; ये ऐसे नियंत्रण हैं जिन्हें एक बिल्डर आज लागू कर सकता है।

JetBrains का मामला इस प्रकार का आखिरी अभियान नहीं होगा। जैसे-जैसे AI API क्रेडेंशियल्स वित्तीय और परिचालन दृष्टि से अधिक मूल्यवान होती जाएंगी, डेवलपर टूलिंग इकोसिस्टम एक अधिक आकर्षक लक्ष्य बनता जाएगा। जो बिल्डर्स अपनी IDE एक्सटेंशन सूची को उतनी ही गंभीरता से लेते हैं जितनी वे अपने डिपेंडेंसी ग्राफ को लाते हैं, वे इस वातावरण में सबसे कम व्यवधान के साथ आगे बढ़ेंगे। JetBrains के अपने fixed security issues दस्तावेज़ीकरण पर नज़र रखें — जो मार्केटप्लेस-संबंधित खुलासों के लिए एक उपयोगी चल संदर्भ है — और Aikido Security की आगे की रिपोर्टिंग पर भी, जो इस वर्ग के सप्लाई-चेन जोखिम पर सबसे सटीक स्रोतों में से एक रही है।