बड़े उद्यम अपने AI वर्कलोड को निजी फायरवॉल और स्व-होस्ट किए गए गेटवे के पीछे अलग करने के लिए लाखों खर्च करते हैं। वे अपने डेटा प्रवाह पर पूर्ण नियंत्रण और बाहरी खतरों के खिलाफ एक मजबूत सुरक्षा घेरे की अपेक्षा करते हैं। GitLab AI गेटवे संस्करण 19.4 की वास्तविक शोषण क्षमता (exploitability) दर्शाती है कि सबसे अलग-थलग वातावरण भी सरल इनपुट खामियों के प्रति संवेदनशील बने रहते हैं। Duo एजेंट प्लेटफॉर्म तक पहुंच रखने वाला एक अकेला लॉग-इन उपयोगकर्ता उस सैंडबॉक्स को बायपास कर सकता है जिसे AI प्रॉम्प्ट को सीमित रखने के लिए बनाया गया है। यह बचाव सीधे उस सर्वर पर मनमाना कमांड निष्पादन (arbitrary command execution) की ओर ले जाता है जो बड़े भाषा मॉडल (LLMs) के साथ संगठन के कनेक्शन को प्रबंधित करता है।
मैंने वर्षों यह विश्लेषण करने में बिताए हैं कि कैसे डेवलपर्स टेम्पलेट इंजन को सुरक्षित क्षेत्र मानते हैं। एक आम गलतफहमी है कि यदि उपयोगकर्ता पहले से ही प्रमाणित है, तो सैंडबॉक्स एस्केप का जोखिम गौण है। यह मानसिकता खतरनाक है। CVE-2026-90970 के मामले में, GitLab ने CVSS पैमाने पर इस खामी को 10 में से 9.9 रेटिंग दी है। यह स्कोर एक स्पष्ट संकेतक है कि सुरक्षा समुदाय इसे एक मिशन-क्रिटिकल विफलता के रूप में देखता है। यह खामी कोई सूक्ष्म मेमोरी करप्शन या जटिल टाइमिंग अटैक नहीं है। यह कस्टम फ्लो के प्रॉम्प्ट टेम्पलेट में एक विफलता है, जो बहु-चरणीय कार्यों को स्वचालित करने के लिए डिज़ाइन की गई एक सुविधा है।
GitLab AI गेटवे एक आंतरिक GitLab इंस्टेंस और बाहरी AI प्रदाताओं के बीच कनेक्शन के लिए एक अभेद्य डिजिटल तिजोरी के रूप में कार्य करता है। डिज़ाइन के अनुसार, यह गेटवे JSON वेब टोकन (JWT) साइनिंग कीज़ रखता है। ये कीज़ संवेदनशील क्रेडेंशियल हैं जो सुरक्षित संचार की सुविधा प्रदान करती हैं। यदि कोई हमलावर गेटवे पर कमांड निष्पादित करता है, तो वे अब केवल सैंडबॉक्स के भीतर एक उपयोगकर्ता नहीं रह जाते हैं। उनके पास वही अनुमतियाँ होती हैं जो स्वयं गेटवे सेवा के पास होती हैं। पहुंच का यह स्तर एक दुर्भावनापूर्ण अभिनेता को अनुरोधों को इंटरसेप्ट करने या संभावित रूप से उन AI प्रतिक्रियाओं में हेरफेर करने की अनुमति देता है जिन पर कंपनी के अन्य डेवलपर्स कोड जनरेशन और सुरक्षा स्कैनिंग के लिए भरोसा करते हैं।
जोखिम के दृष्टिकोण से, इसका प्रभाव प्रणालीगत है। डेटा को नियंत्रित वातावरण के भीतर रखने के लिए अक्सर स्व-होस्ट किए गए गेटवे को विशेष रूप से चुना जाता है। जब उस गेटवे के साथ समझौता किया जाता है, तो गोपनीयता बढ़ाने के लिए बनाया गया उपकरण ही एक बड़ी घुसपैठ का आधार बन जाता है। गेटवे संगठन के AI मॉडल प्रदाताओं और प्राथमिक GitLab इंस्टेंस से जुड़ता है। यहाँ एक समझौता विकास वातावरण और उसे शक्ति प्रदान करने वाली इंटेलिजेंस लेयर के बीच विश्वास संबंध का समझौता है।
इस खामी की तकनीकी वास्तविकता CWE-1336 में निहित है, जो वेब पेज टेम्पलेट्स में निर्देशों के अनुचित बेअसर (improper neutralization) को कवर करती है। GitLab उपयोगकर्ताओं को Duo एजेंट प्लेटफॉर्म पर कस्टम फ्लो बनाने की अनुमति देता है। ये फ्लो AI द्वारा जानकारी संसाधित करने के तरीके को संरचित करने के लिए प्रॉम्प्ट टेम्पलेट्स का उपयोग करते हैं। वैध पहुंच वाला उपयोगकर्ता एक ऐसा फ्लो कॉन्फ़िगरेशन तैयार कर सकता है जो टेम्पलेट इंजन को उसकी इच्छित सीमाओं के बाहर कोड निष्पादित करने के लिए धोखा देता है। यह क्लासिक सैंडबॉक्स एस्केप है। सिस्टम हमलावर के दुर्भावनापूर्ण इनपुट को डेटा के बजाय कमांड के रूप में मानता है।
पर्दे के पीछे, गेटवे प्रॉम्प्ट टेम्पलेट की संरचना को ठीक से मान्य करने में विफल रहता है। मुझे एक समान मामला याद है जिस पर मैंने पिछले साल सिग्नल कनेक्शन पर एक व्हाइट-हैट हैकर के साथ चर्चा की थी। हमने एक टेम्पलेट इंजन देखा जिसने उपयोगकर्ताओं को सिस्टम फ़ंक्शंस कॉल करने की अनुमति दी यदि वे अपने ब्रैकेट को एक विशिष्ट तरीके से नेस्ट करते थे। यह पार्सर में एक साधारण चूक थी। GitLab का हालिया इतिहास बताता है कि यह एक आवर्ती विषय है। फरवरी में, उन्होंने CVE-2026-1868 को पैच किया, जो एक और 9.9 रेटिंग वाली खामी थी जिसमें क्राफ्टेड फ्लो परिभाषाएं भी शामिल थीं। इस भेद्यता वर्ग की पुनरावृत्ति इंगित करती है कि टेम्पलेट सुरक्षा AI-एकीकृत प्लेटफार्मों के लिए एक कठिन बाधा बनी हुई है।
केवल उन संगठनों को कार्रवाई करने की आवश्यकता है जो अपना स्वयं का AI गेटवे होस्ट करते हैं। GitLab, GitLab.com और GitLab Dedicated पर ग्राहकों के लिए गेटवे का प्रबंधन करता है। सक्रिय रूप से कहें तो, वे ग्राहक पहले से ही सुरक्षित हैं क्योंकि GitLab ने सार्वजनिक एडवाइजरी से पहले अपने स्वयं के बुनियादी ढांचे को अपडेट कर दिया था। रक्षा का बोझ अब उन सिस्टम एडमिनिस्ट्रेटर के कंधों पर है जो अपनी स्वयं की डॉकर इमेज या हेल्म चार्ट का प्रबंधन करते हैं।
वास्तुकला के स्तर पर, गेटवे एक स्टैंडअलोन सेवा है। जब आप मुख्य GitLab इंस्टेंस को अपडेट करते हैं तो यह स्वचालित रूप से अपडेट नहीं होता है। यह अलगाव महत्वपूर्ण है। एक आम गलती यह मान लेना है कि पैच किए गए GitLab Rails एप्लिकेशन का अर्थ पैच किया गया AI वातावरण है। गेटवे एक अलग डॉकर इमेज है जिसका अपना संस्करण और जीवनचक्र है। यदि आप 18.1.6 और 19.2.4 के बीच का कोई संस्करण, या नवीनतम रिलीज़ से पहले 19.3 और 19.4 लाइनों में कोई भी संस्करण चला रहे हैं, तो आप असुरक्षित हैं।
पैचिंग ही एकमात्र प्रभावी उपाय है क्योंकि GitLab ने कोई वर्कअराउंड प्रदान नहीं किया है। डॉकर-आधारित परिनियोजन को सुरक्षित करने के लिए, आपको मौजूदा कंटेनर को रोकना होगा और उसे हटाना होगा। फिर आप अपडेट किए गए इमेज टैग को पुल करते हैं। अधिकांश उद्यम उपयोगकर्ताओं के लिए, यह self-hosted-v19.4.1-ee टैग या 19.2 और 19.3 लाइनों के लिए इसके समकक्ष होगा।
कुबेरनेट्स (Kubernetes) का उपयोग करने वालों के लिए, प्रक्रिया में हेल्म चार्ट में इमेज सेटिंग को अपडेट करना शामिल है। नीचे दी गई तालिका प्रभावित संस्करणों के लिए आवश्यक अपडेट पथों का सारांश प्रस्तुत करती है:
| उपयोग में गेटवे संस्करण | पहला फिक्स्ड संस्करण |
|---|---|
| 18.1.6 से 19.2.3 | 19.2.4 |
| 19.3.0 से 19.3.1 | 19.3.2 |
| 19.4.0 | 19.4.1 |
GitLab की रखरखाव नीति आम तौर पर वर्तमान और पिछले दो लघु रिलीज़ को कवर करती है। नतीजतन, फिक्स 19.2, 19.3 और 19.4 लाइनों के लिए उपलब्ध हैं। यदि आप 19.1 जैसा पुराना संस्करण चला रहे हैं, तो कोई आधिकारिक फिक्स सूचीबद्ध नहीं है। पुराने संस्करणों के लिए समर्थन की यह कमी एक बारीक विवरण है जिसे प्रशासकों को अनदेखा नहीं करना चाहिए। गेटवे के असमर्थित संस्करण को चलाना प्रभावी रूप से डिजिटल तिजोरी को खुला छोड़ना है।
आज तक, अमेरिकी साइबर सुरक्षा और बुनियादी ढांचा सुरक्षा एजेंसी (CISA) इस खामी के शोषण को 'शून्य' के रूप में सूचीबद्ध करती है। कोई सार्वजनिक प्रूफ ऑफ कॉन्सेप्ट नहीं है और जंगल में सक्रिय शोषण का कोई सबूत नहीं है। हालांकि, एडवाइजरी यह जांचने का तरीका प्रदान नहीं करती है कि अपडेट से पहले गेटवे पर हमला किया गया था या नहीं। फोरेंसिक दृश्यता की यह कमी एक महत्वपूर्ण अंतर है। विशिष्ट लॉग सिग्नेचर या समझौते के संकेतकों के बिना, प्रशासकों को यह आश्चर्य करने के लिए छोड़ दिया जाता है कि भेद्यता की अवधि के दौरान उनकी साइनिंग कीज़ तक पहुंच बनाई गई थी या नहीं।
इस तरह के उपकरण से जुड़े उल्लंघन की स्थिति में, लक्ष्य अक्सर गुप्त दृढ़ता (stealthy persistence) होता है। एक हमलावर गेटवे को क्रैश नहीं कर सकता है। इसके बजाय वे बाद में AI मॉडल तक अनधिकृत पहुंच की सुविधा के लिए JWT साइनिंग कीज़ को चुपचाप निर्यात कर सकते हैं। यही कारण है कि पैच के बाद संवेदनशील क्रेडेंशियल्स का तत्काल रोटेशन एक मानक उद्योग अभ्यास है। जहाज के पतवार में छेद को पैच करना पहला कदम है, लेकिन आपको यह भी जांचना चाहिए कि छेद खुला होने के दौरान कोई माल ओवरबोर्ड तो नहीं फेंका गया था।
हम अक्सर AI को एक भविष्यवादी परत के रूप में मानते हैं जो हमारे मौजूदा कोड के ऊपर बैठती है। वास्तव में, GitLab गेटवे जैसी AI सेवाएं सिर्फ अधिक सॉफ्टवेयर हैं। वे कमांड इंजेक्शन और टेम्पलेट एस्केप जैसी पुरानी स्कूल की भेद्यताओं के अधीन हैं। मानवीय फायरवॉल रक्षा की पहली पंक्ति बनी हुई है। जिन उपयोगकर्ताओं के पास Duo एजेंट प्लेटफॉर्म की पहुंच है, वे ही इस खामी तक पहुंच सकते हैं। इन प्लेटफार्मों तक पहुंच को केवल उन लोगों तक सीमित करना जिन्हें इसकी सख्त जरूरत है, न्यूनतम विशेषाधिकार (least privilege) के सिद्धांत का पालन करता है।
जीरो ट्रस्ट हर आंतरिक दरवाजे पर एक वीआईपी क्लब बाउंसर की तरह है। भले ही कोई उपयोगकर्ता इमारत के अंदर हो, बाउंसर को टेम्पलेट इंजन कॉन्फ़िगरेशन के पास जाने देने से पहले उनके क्रेडेंशियल्स की जांच करनी चाहिए। यदि आपका संगठन प्रत्येक डेवलपर को बिना किसी निरीक्षण के कस्टम AI फ्लो बनाने की अनुमति देता है, तो आप अपना अटैक सरफेस बढ़ा रहे हैं। इन AI एकीकरणों की जटिलता दानेदार पहुंच नियंत्रण (granular access control) को एक सुझाव के बजाय एक आवश्यकता बनाती है।
इस महत्वपूर्ण खामी को दूर करने के लिए, प्रशासकों को कार्यों के एक विशिष्ट अनुक्रम का पालन करना चाहिए। सबसे पहले, वर्तमान में वातावरण में चल रहे AI गेटवे इमेज के सटीक संस्करण की पहचान करें। यह न मानें कि संस्करण मुख्य GitLab एप्लिकेशन से मेल खाता है। दूसरा, GitLab द्वारा प्रदान की गई डॉकर या हेल्म प्रक्रियाओं का उपयोग करके तुरंत प्रासंगिक पैच लागू करें। तीसरा, यदि पैच लागू होने से पहले गेटवे अविश्वसनीय आंतरिक उपयोगकर्ताओं के संपर्क में था, तो JWT साइनिंग कीज़ को रोटेट करने पर विचार करें।
अंत में, उन उपयोगकर्ताओं की सूची का ऑडिट करें जिनके पास Duo एजेंट प्लेटफॉर्म पर कस्टम फ्लो कॉन्फ़िगर करने की अनुमति है। यदि किसी उपयोगकर्ता के पास इन कॉन्फ़िगरेशन को संशोधित करने का कोई मिशन-क्रिटिकल कारण नहीं है, तो उनकी पहुंच हटा दें। भेद्यता तक पहुँचने वाले लोगों की संख्या को कम करना उतना ही महत्वपूर्ण है जितना कि कोड को स्वयं ठीक करना। सुरक्षा शोधन की एक निरंतर प्रक्रिया है, एक बार का अपडेट नहीं।
अस्वीकरण: यह लेख केवल सूचनात्मक और शैक्षिक उद्देश्यों के लिए है। यह एक पेशेवर साइबर सुरक्षा ऑडिट या घटना प्रतिक्रिया सेवा की जगह नहीं लेता है। सिस्टम अपडेट करने से पहले हमेशा आधिकारिक विक्रेता दस्तावेज़ देखें।



हमारा एंड-टू-एंड एन्क्रिप्टेड ईमेल और क्लाउड स्टोरेज समाधान सुरक्षित डेटा एक्सचेंज का सबसे शक्तिशाली माध्यम प्रदान करता है, जो आपके डेटा की सुरक्षा और गोपनीयता सुनिश्चित करता है।
/ एक नि: शुल्क खाता बनाएं