Ing. Calogero Bono
12 अक्टूबर 2026 को GitLab ने Community Edition और Enterprise Edition के लिए संस्करण 19.4.2, 19.3.5 और 19.2.8 जारी किए। इनमें CVE-2026-97229 का सुधार है, एक ऐसी खामी जिसका CVSS स्कोर 10.0 है और जिससे सर्वर पर मनमाना कोड चल सकता है। गुरुवार को अमेरिकी एजेंसी CISA ने सक्रिय शोषण की पुष्टि की और इसे KEV सूची में डाल दिया। अगर आप खुद GitLab इंस्टेंस चलाते हैं, तो सबसे ज़रूरी काम तुरंत अपडेट करना है।
तथ्यों से पहले कुछ शब्द। CVE वह कोड है जो किसी सार्वजनिक कमजोरी की पहचान करता है। CVSS 0 से 10 तक का गंभीरता स्कोर है। CI/CD वे स्वचालित पाइपलाइन हैं जो कोड को बनाती, जांचती और प्रकाशित करती हैं। KEV CISA की उन खामियों की सूची है जिनका असली हमलों में पहले से इस्तेमाल हो रहा है। RCE का मतलब दूर से कोड चलाना है, यानी किसी और के सर्वर पर कमांड चलाना।
CVE-2026-97229 क्या है?
GitLab के आधिकारिक पेज के अनुसार, यह CI/CD कॉन्फ़िगरेशन में इस्तेमाल होने वाले regular expression कंपाइलर में integer overflow की समस्या है। कुछ परिस्थितियों में बिना प्रमाणीकरण वाला उपयोगकर्ता एक खास तरह से बनाए गए regular expression से सर्वर पर मनमाना कोड चला सकता था, क्योंकि इनपुट की जांच पर्याप्त नहीं थी।
CVSS वेक्टर नेटवर्क के रास्ते से, कम जटिलता वाला, बिना किसी विशेषाधिकार और बिना उपयोगकर्ता की भागीदारी के काम करता है। इसी वजह से स्कोर 10.0 तक पहुंचता है। इस खामी की सूचना joaxcar ने HackerOne के bug bounty कार्यक्रम के जरिए दी थी।
इसका शोषण कौन कर रहा है?
BleepingComputer की रिपोर्ट के अनुसार, CISA ने इस खामी को KEV में जोड़ा और संघीय एजेंसियों से रविवार तक सर्वर सुरक्षित करने को कहा। The Hacker News के अनुसार नागरिक एजेंसियों के लिए समय सीमा 1 नवंबर 2026 है।
यह कदम Alpine Linux की सार्वजनिक की गई एक घटना से जुड़ा है। किसी अज्ञात हमलावर ने 20 और 21 अक्टूबर 2026 को उनके इंस्टेंस पर इस खामी का फायदा उठाने की कोशिश की, जो नाकाम रही। उसने खास तरह से बनाए गए CI कॉन्फ़िगरेशन भेजे, जिनसे worker प्रोसेस आठ बार क्रैश हुए। इनमें से चार मामलों में exploit अगले चरण पर विफल हो गया। हमलावर ने Alpine की GitLab container इमेज भी डाउनलोड की। 25 और 26 अक्टूबर के नए प्रयास रोक दिए गए।
Alpine के मेंटेनर्स ने कहा, «The attack came close to working»। उन्हें सफलता का कोई सबूत नहीं मिला, पर वे इससे इनकार नहीं कर सकते, इसलिए उन्होंने इंस्टेंस को शुरू से दोबारा बनाया। उनके मुताबिक aports रिपॉज़िटरी, पैकेज और 21 अक्टूबर की रिलीज़ से छेड़छाड़ नहीं हुई।
कौन से संस्करण प्रभावित हैं?
CVE-2026-97229 के लिए GitLab ने 19.2 के 19.2.8 से पहले के सभी संस्करण, 19.3 के 19.3.5 से पहले के और 19.4 के 19.4.2 से पहले के संस्करण बताए हैं। GitLab.com पर सुधरा हुआ संस्करण पहले से चल रहा है। GitLab Dedicated के टेनेंट्स को सार्वजनिक रिलीज़ से पहले एक आंतरिक रिलीज़ से अपडेट किया गया था।
GitLab ने यह भी बताया कि 19.3.4 में merge request पेजों पर एक बग था जब Ona इंटीग्रेशन सक्रिय था। यह 19.3.5 में ठीक कर दिया गया है। कंपनी ने self-managed इंस्टेंस चलाने वालों को हमले के प्रयास पहचानने में मदद के लिए छह threat detection नियम भी जारी किए हैं।
इसी पैच की दूसरी खामियां
इस रिलीज़ में सिर्फ सबसे गंभीर मामला नहीं है। बाकी सुधार, GitLab द्वारा बताए गए स्कोर के साथ –
- CVE-2026-92883, syntax highlighting में cross-site scripting, CVSS 8.7।
- CVE-2026-16301, Developer भूमिका वाला उपयोगकर्ता संरक्षित branches पर pipeline शुरू कर सकता था, CVSS 8.5।
- CVE-2026-14814, raw फाइल कैश का पॉइज़निंग, जिससे संरक्षित variables उजागर हो सकते थे, CVSS 8.2।
- CVE-2026-81839, प्रोजेक्ट ट्रांसफर के बाद pipeline नए समूह के विशेषाधिकार के साथ चलती थीं (केवल EE), CVSS 7.7।
- CVE-2026-96893, GitLab Duo के AI एजेंट निर्देशों में injection (केवल EE), CVSS 7.3।
इसके अलावा पांच मध्यम गंभीरता की खामियां हैं, जिनमें GraphQL के जरिए निजी नोट पढ़ना और GitLab Pages के लॉग में token उजागर होना शामिल है। पूरी सूची आधिकारिक पेज पर है।
सीमाएं जो जानना ज़रूरी है
कितने इंस्टेंस से समझौता हुआ, यह पता नहीं है। BleepingComputer में उद्धृत Shadowserver इंटरनेट पर उजागर लगभग 2.800 Community Edition इंस्टेंस दिखाता है, पर यह नहीं बताता कि उनमें से कितने पहले ही अपडेट हैं। इस संख्या को असुरक्षित सिस्टम की संख्या न मानें।
स्रोतों में यह नहीं बताया गया कि हमलावर कौन है, या Alpine के अलावा और कोई मामला है या नहीं। exploit का तकनीकी ब्योरा भी प्रकाशित नहीं हुआ है। GitLab पैच जारी होने के 90 दिन बाद रिपोर्ट सार्वजनिक करता है, इसलिए और ब्योरे आ सकते हैं।
डिजिटल काम करने वालों के लिए इसका मतलब
अगर आपके स्टूडियो या कंपनी में self-managed GitLab है, तो प्राथमिकता संस्करण अपडेट करना है। ऐसे सर्वर पर बिना प्रमाणीकरण वाली खामी, जिसमें कोड, सीक्रेट्स और pipeline रखे हों, ग्राहकों के लिए भी वास्तविक जोखिम है। जो GitLab.com पर अपने रिपॉज़िटरी रखते हैं, वे प्लेटफ़ॉर्म स्तर पर पहले से सुरक्षित हैं।
Alpine का सबक व्यावहारिक है। अगर समझौते से इनकार नहीं कर सकते, तो इंस्टेंस दोबारा बनाएं और सीक्रेट्स बदलें। इंस्टॉलेशन को स्वचालित करना मदद करता है, जैसा हम Ansible से कॉन्फ़िगरेशन और deploy की गाइड में समझाते हैं। सर्वर के लिए अपडेट में अनुशासन भी ज़रूरी है, जिस विषय पर हमने Fragnesia और PHP2Shell के मामले में लिखा था। पैच के बाद स्कैनिंग का एक और हालिया उदाहरण Oracle E-Business Suite है। अगर सब कुछ खुद संभालने का समय नहीं है, तो सुरक्षा अपडेट वाले प्रबंधित hosting और सर्वर भी उपलब्ध हैं।
हमारी राय
यह मामला दिखाता है कि पैच और हमले के बीच का समय कितना छोटा है। सुधार 12 अक्टूबर को आया, Alpine पर प्रयास 20 अक्टूबर को हुए, यानी सिर्फ आठ दिन बाद। जो व्यक्ति अगले मासिक चक्र में अपडेट करता है, वह बहुत देर कर चुका होता है।
एक आलोचनात्मक बात भी है। GitLab को Fortune 100 की आधी से ज़्यादा कंपनियों में मौजूद बताया गया है, और BleepingComputer उसी दौर की अधिकतम गंभीरता वाली कई खामियों की सूची देता है, जिनमें दो और अधिकतम गंभीरता की हैं। जो सेवा किसी कंपनी का कोड और सीक्रेट्स संभालती है, उसके लिए यह आवृत्ति चिंता का विषय है। सिर्फ यह कहना काफी नहीं कि GitLab तेज़ी से सुधार करता है, भले ही वह करता हो। जो लोग सब कुछ अपने पास रखना चाहते हैं, उन्हें लगातार निगरानी का खर्च उठाना होगा, या यह काम उन्हें सौंपना होगा जो इसे पेशेवर तरीके से करते हैं।
अक्सर पूछे जाने वाले सवाल
क्या मुझे GitLab तुरंत अपडेट करना चाहिए?
हां, अगर आपका इंस्टेंस self-managed है और बताए गए संस्करणों में है। GitLab 19.4.2, 19.3.5 या 19.2.8 पर तुरंत अपडेट की सलाह देता है। सक्रिय शोषण की पुष्टि CISA ने की है।
क्या GitLab.com खतरे में है?
GitLab के अनुसार नहीं। GitLab.com पर सुधरा हुआ संस्करण पहले से चल रहा है और Dedicated टेनेंट्स को सार्वजनिक रिलीज़ से पहले अपडेट किया गया था।
क्या इस खामी का फायदा उठाने के लिए अकाउंट चाहिए?
नहीं। CVSS वेक्टर के अनुसार कोई विशेषाधिकार नहीं चाहिए और उपयोगकर्ता की कोई भागीदारी जरूरी नहीं। हमला एक खास तरह से बनाए गए CI/CD कॉन्फ़िगरेशन से होता है।
मुझ पर हमला हुआ है, यह कैसे पता करूं?
स्रोतों में इसका कोई पक्का तरीका नहीं बताया गया है। GitLab ने self-managed इंस्टेंस के लिए छह detection नियम जारी किए हैं। Alpine ने असामान्य CI कॉन्फ़िगरेशन के बाद worker के बार-बार क्रैश होने को देखा।
क्या सिर्फ अपडेट करना काफी है?
यह स्थिति पर निर्भर करता है। अगर इंस्टेंस उजागर था और पिछले दिनों बिना पैच के था, तो समझौते से इनकार नहीं किया जा सकता। Alpine ने इसे शुरू से दोबारा बनाने का फैसला किया।
आने वाले हफ्तों में क्या देखें, पैच और जांच के बीच
आने वाले दिनों में यह देखना अहम होगा कि Alpine के अलावा और मामले सामने आते हैं या नहीं, और तकनीकी ब्योरे प्रकाशित होते हैं या नहीं। तीन सुझाव –
- अपनी शाखा के लिए उपलब्ध नवीनतम संस्करण पर अपडेट करें और इंस्टॉलेशन के बाद संस्करण संख्या की जांच करें।
- worker लॉग में बार-बार क्रैश और असामान्य CI कॉन्फ़िगरेशन देखें, और GitLab के detection नियमों का उपयोग करें।
- अगर इंस्टेंस उजागर था और अपडेट नहीं था, तो token और संरक्षित variables बदलें और दोबारा बनाने पर विचार करें।
