GitLab की 10.0 खामी पर हमला—पैच के बाद भी निकली फ़ाइलें जाँचें
17 सितंबर 2026 को सिंगापुर की साइबर सुरक्षा एजेंसी ने GitLab की CVSS 10.0 खामी CVE-2026-85706 के सक्रिय दुरुपयोग की चेतावनी दी। एजेंसी की चेतावनी के अनुसार, सार्वजनिक प्रमाण-अवधारणा उपलब्ध है और बिना प्रमाणीकरण हमलावर रिपॉज़िटरी कमिट API के माध्यम से सर्वर की मनमानी फ़ाइल पढ़ सकता है।
उसी दिन प्रकाशित GitLab की तकनीकी जाँच प्रक्रिया एक महत्वपूर्ण अंतर बताती है: सर्वर से फ़ाइल पढ़वा लेना और उसकी सामग्री हमलावर तक पहुँचना अलग घटनाएँ हैं। इसलिए पैच लगाना आगे के हमले रोकने का उपाय है, लेकिन उससे पहले हुई निकासी जानने के लिए पुराने API और Workhorse अभिलेखों को आपस में मिलाना होगा।
कौन-से संस्करण प्रभावित हैं
जोखिम GitLab Community Edition और Enterprise Edition के स्व-प्रबंधित परिनियोजनों तक सीमित है। प्रभावित संस्करण-शृंखलाएँ 18.7 से 19.1.7, 19.2 से 19.2.5 और 19.3 से 19.3.1 तक हैं; सुधारे गए संस्करण 19.1.8, 19.2.6 और 19.3.2 हैं। GitLab.com पहले ही सुरक्षित किया जा चुका है और GitLab Dedicated ग्राहकों के लिए अलग कार्रवाई आवश्यक नहीं बताई गई है।
Rapid7 के स्वतंत्र आकलन में सक्रिय दुरुपयोग, प्रभावित शाखाओं और इन तीन सुधारे गए संस्करणों का वही दायरा दर्ज है। संचालकों को अपनी समर्थित शाखा के नवीनतम सुरक्षित संस्करण पर जाना चाहिए; केवल बाहरी पहुँच सीमित करना स्थायी सुधार नहीं है।
संदिग्ध अनुरोध की पहचान कैसे करें
हमला POST /api/v4/projects/:id/repository/commits अनुरोध में दिए पथ को अपेक्षित अपलोड क्षेत्र से बाहर मोड़ता है। जाँच का पहला लक्ष्य api_json.log और उसके घुमाए गए पुराने अभिलेखों में इस मार्ग से जुड़े अनुरोध खोजना है। बहुखंडी प्रपत्र के अलावा साधारण कूटित प्रपत्र अनुरोध भी प्रासंगिक हो सकते हैं।
पथ के लिए प्रयुक्त क्षेत्र file.path या metadata.path हो सकता है। हमलावर बिंदु और क्षेत्र-नाम का प्रतिशत-कूटित रूप भी भेज सकता है, इसलिए खोज में file%2Epath और metadata%2Epath को शामिल करें। मिले प्रत्येक मान को प्रतिशत-विकूटित करके दोहरे बिंदु वाले खंड सुलझाएँ और जाँचें कि अंतिम पथ /uploads/tmp/ की सीमा के भीतर रहता है या उससे बाहर जाता है।
किसी एक वैध पथ की मौजूदगी पूरे अनुरोध को सुरक्षित सिद्ध नहीं करती। उसी अनुरोध में दूसरा पथ बाहर की फ़ाइल की ओर जा सकता है, इसलिए सभी पथ-मूल्यों की अलग जाँच करें। संदिग्ध प्रविष्टि मिलने पर उसका समय, HTTP स्थिति, उपलब्ध दूरस्थ IP और correlation_id सुरक्षित रखें; यही सहसंबंध पहचान दूसरे अभिलेख से घटना जोड़ती है।
पैच से पहले कौन-से साक्ष्य बचाने हैं
सुरक्षित प्रति बनाने के तुरंत बाद पैच लगाएँ। उन्नयन या पुनरारंभ से पहले API अभिलेख, उनके घुमाए गए रूप, Workhorse पहुँच-अभिलेख और Nginx अभिलेख की प्रतिलिपि बना लें। पुनरारंभ से पुराने Workhorse अभिलेख घूम या हट सकते हैं; Helm पर Webservice और Workhorse पात्रों के अभिलेख अलग-अलग एकत्र करने पड़ सकते हैं।
इन प्रतियों को सामान्य निदान सामग्री की तरह खुला न रखें। त्रुटि-विवरण में लौटाया गया फ़ाइल-अंश सादे रूप में दर्ज हो सकता है और उसमें पासवर्ड, टोकन या अन्य गोपनीय मान शामिल हो सकते हैं। पहुँच सीमित करें, प्रतियों की अखंडता दर्ज करें और मूल अभिलेख पर सीधे छँटाई या संपादन न करें।
वास्तविक निकासी कैसे सिद्ध होगी
HTTP स्थिति अकेले सफलता या विफलता नहीं बताती। प्रत्येक संदिग्ध सहसंबंध पहचान को Workhorse की पहुँच प्रविष्टि से जोड़ें और वहाँ का written_bytes मान लें; फिर API प्रविष्टि के api_error क्षेत्र में देखें कि उत्तर में फ़ाइल का कोई अंश जुड़ा था या नहीं। पहला मान ग्राहक को भेजे गए पूरे उत्तर का आकार है, केवल फ़ाइल-अंश का नहीं।
पहले ऐसे अनुपलब्ध पथ पर नियंत्रित अनुरोध से अपने परिनियोजन का सामान्य त्रुटि-उत्तर मापें। रिवर्स प्रॉक्सी, संपीड़न और संस्करण के अनुसार आकार बदल सकता है, इसलिए किसी एक सार्वभौमिक बाइट-सीमा पर भरोसा नहीं किया जा सकता। संदिग्ध उत्तर का आकार स्थानीय आधार से अधिक हो और त्रुटि-विवरण में लक्ष्य फ़ाइल का अंश भी मिले, तो सामग्री बाहर जाने का मजबूत प्रमाण है।
- त्रुटि-विवरण में फ़ाइल-अंश नहीं है और उत्तर सामान्य आधार के आसपास है, तो उपलब्ध अभिलेख निकासी सिद्ध नहीं करते।
- फ़ाइल पढ़े जाने का संकेत है, लेकिन उत्तर में उसका अंश नहीं जुड़ा, तो सर्वर ने पथ खोला हो सकता है पर सामग्री ग्राहक तक नहीं पहुँची।
- फ़ाइल-अंश और उससे संगत बड़ा उत्तर दोनों मौजूद हैं, तो घटना को सफल निकासी मानकर प्रतिक्रिया शुरू करें।
त्रुटि क्षेत्र के भीतर दूसरा संरचित उत्तर समाहित हो सकता है, इसलिए उसे दो चरणों में खोलना पड़ सकता है। निकला अंश टर्मिनल पर दिखाने के बजाय नियंत्रित साक्ष्य-फ़ाइल में लिखें। इससे मूल बाइट सुरक्षित रहती हैं और यह तय करना आसान होता है कि वास्तव में कौन-सा रहस्य उत्तर में गया था।
HTTP 400, 401 या 500 स्थिति, लक्षित फ़ाइल का कुल आकार अथवा केवल लंबा उत्तर अपने आप निर्णायक नहीं है। इसी तरह कोई अभिलेख न मिलना सुरक्षित होने का प्रमाण नहीं माना जा सकता, यदि प्रतिधारण अवधि छोटी थी, पंक्तियाँ कट गई थीं या उन्नयन से पहले अभिलेख घूम चुके थे।
पुष्ट निकासी के बाद रहस्य बदलने का क्रम
प्रतिक्रिया का दायरा अनुमानित लक्ष्य के बजाय लौटे हुए पुष्ट अंश से तय करें। अंश में दिखे क्रेडेंशियल, टोकन या कुंजी को पहले रद्द अथवा बदलें; फिर उसके उपयोग-क्षेत्र—जैसे ऑब्जेक्ट भंडारण, SMTP, LDAP, SSO, डेटाबेस या बाहरी एकीकरण—में संदिग्ध अनुरोध के समय से आगे की प्रमाणीकरण गतिविधि जाँचें।
- संबंधित API, Workhorse और प्रॉक्सी अभिलेखों की सुरक्षित प्रतियाँ बनाएँ।
- प्रभावित इंस्टेंस को समर्थित सुधारे गए संस्करण पर ले जाएँ।
- सामान्य और प्रतिशत-कूटित पथ-क्षेत्र खोजकर संदिग्ध सहसंबंध पहचानों की सूची बनाएँ।
- हर पहचान को उत्तर के बाइट-मान और त्रुटि-विवरण से मिलाकर निकासी वर्गीकृत करें।
- पुष्ट लौटे अंश में मौजूद रहस्य बदलें और संबंधित प्रणालियों में उनके उपयोग की जाँच करें।
दूरस्थ IP केवल शुरुआती संकेत है, क्योंकि गलत प्रॉक्सी विन्यास में X-Forwarded-For शीर्षक जाली हो सकता है। उपलब्ध जानकारी से सक्रिय हमला, प्रभावित संस्करण और सुधार की उपलब्धता स्थापित है; यदि अभिलेखों में निकासी का प्रमाण नहीं मिलता, तो निष्कर्ष इतना ही होना चाहिए कि सामग्री लौटने की पुष्टि नहीं हुई—यह नहीं कि सर्वर ने फ़ाइल कभी पढ़ी ही नहीं।
यह भी पढ़ें:
हमारे न्यूज़लेटर की सदस्यता लें
Web3, AI और क्रिप्टो की नवीनतम खबरें सीधे अपने इनबॉक्स में पाएँ।