अगर आपकी कंपनी GitLab को अपने सर्वर पर चलाती है, तो उसे आज ही अपडेट करें। 12 अक्टूबर 2026 को GitLab ने एक क्रिटिकल सुरक्षा पैच जारी किया जो 24 खामियों को ठीक करता है। इनमें सबसे गंभीर, CVE-2026-97229, को सबसे ऊँचा संभव गंभीरता स्कोर मिला: 10 में से 10। यह ऐसे व्यक्ति को, जिसका आपके सर्वर पर कोई अकाउंट नहीं है, उस पर अपना कोड चलाने देती है। 19.2.8 से पहले के 19.2, 19.3.5 से पहले के 19.3 या 19.4.2 से पहले के 19.4 वर्ज़न चलाने वाला हर सर्वर प्रभावित है। GitLab जो एकमात्र समाधान बताता है, वह है 19.4.2, 19.3.5 या 19.2.8 पर अपग्रेड करना। अगर आप GitLab.com पर क्लाउड सेवा इस्तेमाल करते हैं, तो आपको कुछ भी करने की ज़रूरत नहीं है।

GitLab क्या है, और एक बिज़नेस मालिक को इसकी परवाह क्यों करनी चाहिए?

GitLab वह जगह है जहाँ आपकी तकनीकी टीम आपके सिस्टम और ऐप्स का सोर्स कोड रखती है, और जहाँ नए वर्ज़न बनाकर आपके सर्वरों पर भेजे जाते हैं। कई कंपनियाँ कोड और डेटा को संगठन के भीतर रखने के लिए इसे क्लाउड सेवा की बजाय अपने इन-हाउस सर्वर पर चलाती हैं। उस सर्वर पर आम तौर पर मालिक की उम्मीद से ज़्यादा चीज़ें होती हैं: पूरा सोर्स कोड, डेटाबेस पासवर्ड, वे कुंजियाँ जो आपको पेमेंट गेटवे और सरकारी सेवाओं से जोड़ती हैं, और उन सर्वरों पर डिप्लॉय करने का अधिकार जिन्हें आपके ग्राहक इस्तेमाल करते हैं। जिसके नियंत्रण में यह सर्वर है, वह यह सब पढ़ सकता है, और आपके कोड को ग्राहकों तक पहुँचने से पहले बदल भी सकता है।

GitLab ने ठीक-ठीक क्या घोषणा की?

GitLab की आधिकारिक पैच रिलीज़ घोषणा के अनुसार, खामी उस हिस्से में है जो बिल्ड और डिप्लॉयमेंट पाइपलाइन सेटिंग्स (CI/CD) के अंदर रेगुलर एक्सप्रेशन को प्रोसेस करता है। रेगुलर एक्सप्रेशन टेक्स्ट का एक छोटा टुकड़ा होता है जो किसी खोज पैटर्न का वर्णन करता है। घोषणा कहती है कि इन एक्सप्रेशन की अपर्याप्त जाँच के कारण यह खामी किसी बिना प्रमाणीकरण वाले उपयोगकर्ता को विशेष रूप से तैयार किए गए रेगुलर एक्सप्रेशन के ज़रिए GitLab सर्वर पर मनमाना कोड चलाने दे सकती है। एक शोधकर्ता ने इसे HackerOne पर GitLab के बग बाउंटी प्रोग्राम के माध्यम से रिपोर्ट किया।

घोषणा यह नहीं कहती कि इस खामी का दुरुपयोग हुआ है। लेकिन 10 का स्कोर बताता है कि इसका दुरुपयोग इंटरनेट पर, बिना पासवर्ड के और किसी कर्मचारी की मदद के बिना किया जा सकता है। हमलावर आम तौर पर सुधार सार्वजनिक होने के कुछ ही दिनों में ऐसी खामियाँ खोजना शुरू कर देते हैं, क्योंकि सुधार ही बता देता है कि कमज़ोरी कहाँ है।

पैच में और क्या है?

यही पैच 23 अन्य खामियों को भी ठीक करता है, जिनमें से पाँच को उच्च गंभीरता दी गई है:

  • सिंटैक्स हाइलाइटिंग में दुर्भावनापूर्ण स्क्रिप्ट इंजेक्शन (XSS), स्कोर 8.7।
  • पाइपलाइन बनाते समय एक ऑथराइज़ेशन खामी, स्कोर 8.5।
  • फ़ाइल एक्सेस को प्रभावित करने वाला एक ज़रूरत से ज़्यादा ढीला रेगुलर एक्सप्रेशन, स्कोर 8.2।
  • पेड एडिशन में पाइपलाइन एक्ज़िक्यूशन नीतियों में एक ऑथराइज़ेशन खामी, स्कोर 7.7।
  • पेड एडिशन में GitLab Duo AI एजेंट में प्रॉम्प्ट इंजेक्शन खामी, स्कोर 7.3।

इसलिए 19.2 से पुराने वर्ज़न, जिन पर क्रिटिकल खामी का असर नहीं है, ज़रूरी नहीं कि सुरक्षित हों। GitLab की आधिकारिक मेंटेनेंस नीति कहती है कि सुरक्षा सुधार केवल मौजूदा रिलीज़ और पिछली दो मासिक रिलीज़ में ही बैकपोर्ट किए जाते हैं। इससे पुराने किसी भी वर्ज़न वाले सर्वर को अब कोई सुरक्षा सुधार नहीं मिलता, और उसे हर हाल में अपग्रेड करने की ज़रूरत है।

किसे कदम उठाना चाहिए?

  • GitLab.com क्लाउड उपयोगकर्ता: कुछ करने की ज़रूरत नहीं; GitLab कहता है कि सेवा पहले से पैच किए गए वर्ज़न पर चल रही है।
  • GitLab Dedicated ग्राहक: घोषणा के अनुसार इन्हें भी कुछ करने की ज़रूरत नहीं है।
  • GitLab को अपने सर्वर पर चलाने वाला हर व्यक्ति: तुरंत अपग्रेड करें। हर सेल्फ-मैनेज्ड इंस्टॉलेशन के लिए GitLab की यही स्पष्ट सिफ़ारिश है।
  • जिसे पक्का नहीं पता कि उसका GitLab कहाँ चलता है: आज ही अपनी टीम से या उस वेंडर से पूछें जिसने आपके सिस्टम बनाए। कई इन-हाउस सर्वर किसी पुराने वेंडर ने सेट किए और फिर उन्हें भुला दिया गया।

इस हफ़्ते के व्यावहारिक कदम

  1. वर्ज़न पता करें: अपने तकनीकी प्रमुख से कहें कि वे GitLab में Help पेज खोलें, वहाँ दिखाया गया वर्ज़न नंबर पढ़ें और उसकी तुलना ऊपर दिए गए नंबरों से करें।
  2. अपग्रेड महीने के अंत में नहीं, आज ही शेड्यूल करें: GitLab की घोषणा के अनुसार, सिंगल-नोड सर्वर पैच के दौरान तब तक बंद रहता है जब तक डेटाबेस माइग्रेशन पूरे नहीं हो जाते, जबकि मल्टी-नोड सेटअप को सही ज़ीरो-डाउनटाइम प्रक्रिया का पालन करने पर बिना डाउनटाइम के पैच किया जा सकता है। कामकाजी घंटों के बाहर एक घंटे का डाउनटाइम एक हैक हुए सर्वर से कहीं कम महँगा पड़ता है।
  3. अगर आप 19.3 पर हैं: 19.3.4 पर नहीं, सीधे 19.3.5 पर जाएँ। घोषणा बताती है कि 19.3.4 में एक बग था जो Ona इंटीग्रेशन चालू होने पर मर्ज रिक्वेस्ट पेजों को प्रभावित करता था, और इसे 19.3.5 में ठीक किया गया।
  4. इंटरनेट पर एक्सपोज़र घटाएँ: अगर कंपनी के बाहर किसी को आपके GitLab सर्वर तक पहुँचने की ज़रूरत नहीं है, तो उसे केवल कंपनी नेटवर्क से या VPN के ज़रिए कनेक्शन स्वीकार करने दें। यह पैचिंग की जगह नहीं लेता, लेकिन अगली बार दरवाज़ा संकरा कर देता है।
  5. पैच के बाद जाँच करें: हाल में बनाए गए उपयोगकर्ताओं, कुंजियों और एक्सेस टोकन की समीक्षा करें। अगर कुछ ऐसा दिखे जिसे कोई नहीं पहचानता, तो सर्वर पर रखे पासवर्ड और कुंजियाँ बदल दें।

हर इंस्टॉलेशन तरीके के लिए अपग्रेड के कदम GitLab की आधिकारिक अपग्रेड गाइड में दिए गए हैं।

Origami की राय

हम GitLab हर दिन इस्तेमाल करते हैं, क्योंकि हमारी रिपॉज़िटरी वहीं हैं, इसलिए हम इसकी सुरक्षा घोषणाओं पर उतनी ही नज़र रखते हैं जितनी अपने इनवॉइस पर। सबक GitLab से बड़ा है: डेटा को इन-हाउस रखने के लिए आप जो भी सिस्टम खुद चलाते हैं, उसके साथ यह ज़िम्मेदारी आती है कि जिस दिन सुधार जारी हो, उसी दिन उसे पैच किया जाए। हम सबसे ज़्यादा जो समस्या देखते हैं, वह यह फ़ैसला नहीं, बल्कि यह है कि अपडेट की ज़िम्मेदारी किसकी है, इसका कोई नाम तय नहीं होता। तीन साल पहले किसी वेंडर द्वारा सेट किया गया सर्वर, जिसके बारे में कोई नहीं जानता कि उसका रखरखाव कौन करता है, वही पहली चीज़ है जिसे हमलावर ढूँढता है। हमने Magento स्टोर की खामी के बारे में भी यही कहा था: पैच देर से आए तो सिर्फ़ पैच करना काफ़ी नहीं है। अगर आपको अपने सर्वरों की समीक्षा करने या उनके अपडेट की ज़िम्मेदारी लेने के लिए किसी की ज़रूरत है, तो हमसे संपर्क करें।

स्रोत