--- title: "NGINX कमजोरियाँ: कारण, समाधान और उत्पादन सत्यापन" description: "पांच अक्टूबर 2026 NGINX कमजोरियों, उनकी कॉन्फ़िगरेशन पूर्वापेक्षाएँ, शाखा-विशिष्ट सुधार, वितरण बैकपोर्ट और उत्पादन सत्यापन की समीक्षा करें।" language: "hi" url: "https://keendigit.com/hi/insights/nginx-remediation-guide" author: "KeenDigit" published: "2026-10-14" updated: "2026-10-27" --- # NGINX कमजोरियाँ: कारण, समाधान और उत्पादन सत्यापन पांच अक्टूबर 2026 NGINX कमजोरियों, उनकी कॉन्फ़िगरेशन पूर्वापेक्षाएँ, शाखा-विशिष्ट सुधार, वितरण बैकपोर्ट और उत्पादन सत्यापन की समीक्षा करें। ऐतिहासिक लेख दिनांक: 2026-10-14 (प्रकटीकरण और सुरक्षा रिलीज़ दिनांक)। स्रोतों की जाँच की गई और जानकारी 2026-10-27 के माध्यम से पूरक की गई। यह लेख घटना तिथि के अनुसार संग्रहीत है; 14 अक्टूबर के बाद जारी संस्करण और रिलीज़ अपडेट नीचे शामिल हैं। श्रोता: NGINX Open Source / NGINX Plus वेबसाइट और रिवर्स प्रॉक्सी संचालन और रखरखाव कर्मी, सुरक्षा प्रतिक्रिया कर्मी, वितरण अनुरक्षक, साथ ही इंजीनियर जो NGINX को स्वयं संकलित करते हैं और तृतीय-पक्ष मॉड्यूल बनाए रखते हैं। यह लेख पांच NGINX कोर कमजोरियों पर केंद्रित है, जिनका खुलासा 14 अक्टूबर, 2026 को किया गया था और गहनता से तय किया गया था, और मई से सितंबर 2026 तक प्रतिनिधि मेमोरी सुरक्षा और अनुरोध अखंडता कमजोरियों पर भी नज़र डालता है। सामग्री में ट्रिगर स्थितियां, कोड-स्तरीय कारण, प्रभाव का दायरा, उपचार कार्यप्रवाह, अल्पकालिक शमन उपाय, आधिकारिक पैच कार्यान्वयन, पुरानी शाखाओं के लिए बैकपोर्ट और उत्पादन सत्यापन शामिल हैं। [S1](https://keendigit.com/hi/insights/nginx-remediation-guide#source-1) जैसे संदर्भ स्रोत परिशिष्ट से लिंक करते हैं। उदाहरण कॉन्फ़िगरेशन का उपयोग केवल तैनाती और ऑडिटिंग विचारों को चित्रित करने के लिए किया जाता है, और कार्यान्वयन से पहले वास्तविक संस्करण, कॉन्फ़िगरेशन विरासत, निर्भरता और व्यावसायिक क्षमता के आधार पर सत्यापित किया जाना चाहिए। ## टीएल;डीआर: प्राथमिकता वाले कार्य 1. सुरक्षा उन्नयन को प्राथमिकता दें. nginx.org ओपन सोर्स पैकेज के लिए, Stable 1.30 शाखा को कम से कम 1.30.6 पर अपडेट करें और Mainline 1.31 शाखा को कम से कम 1.31.7. पर अपडेट करें। सत्यापन तिथि पर, 1.31.8 नवीनतम है Mainline रिलीज़। ये अलग-अलग शाखा आधार रेखाएँ हैं; शाखाओं में उनकी संख्या की तुलना न करें। [S1](https://keendigit.com/hi/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/hi/insights/nginx-remediation-guide#source-2) 2. पूर्ण पैकेज संस्करण द्वारा वितरण स्थापनाओं को सत्यापित करें। Ubuntu 22.04 / 24.04 / 26.04 / 26.10 में विक्रेता बैकपोर्ट हैं; Debian 13 (trixie) के लिए कम से कम `1.26.3-3+deb13u10` की आवश्यकता होती है। सत्यापन के समय, Debian 12 (bookworm) पैकेज `1.22.1-9+deb12u10` अभी भी प्रभावित चिह्नित है। प्रत्येक सीवीई की जाँच करें; Debian 13 सलाह यह स्थापित नहीं करती कि Debian 12 निश्चित है। [S13](https://keendigit.com/hi/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/hi/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/hi/insights/nginx-remediation-guide#source-15) 3. पांच कॉन्फ़िगरेशन संयोजनों का ऑडिट करें: `alias + rewrite + $request_filename`, `map` + regex + परिवर्तनीय मूल्यांकन, `aio + ssi + include virtual`, `proxy_request_buffering on` के साथ HTTP/3, और स्वचालित TLS सत्र टिकट कुंजी रोटेशन के साथ `ssl_session_cache shared:...`। केवल एक निर्देश की उपस्थिति शोषणशीलता स्थापित नहीं करती है; अनुरोध पथ और कॉन्फ़िगरेशन दायरे का आकलन करें। [S1](https://keendigit.com/hi/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/hi/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/hi/insights/nginx-remediation-guide#source-4) 4. सभी पुरानी प्रक्रियाओं और कंटेनरों को बदलें। `nginx -t` चलाएँ, फिर सेवा को पुनरारंभ करें या उच्च-उपलब्धता रोलिंग परिनियोजन करें। पुष्टि करें कि पुरानी master/worker प्रक्रियाएं समाप्त हो गई हैं; अकेले `nginx -s reload` यह साबित नहीं करता कि रनिंग बाइनरी बदल गई है। 5. वास्तविक समापन बिंदुओं को सत्यापित करें: सक्षम होने पर HTTP/1.1, HTTP/2, HTTP/3, प्रॉक्सी अपलोड और API अनुरोध निकाय, mTLS प्रमाणपत्र प्रमाणीकरण, SSI पृष्ठ और एक्सेस लॉग। प्रत्येक समापन बिंदु के लिए पैकेज उद्गम, संस्करण, छवि डाइजेस्ट, चल रही प्रक्रियाओं और परिणामों को रिकॉर्ड करें। 6. यदि तत्काल अपग्रेड असंभव है, तो लागू ट्रिगर शर्तों को हटा दें: अनावश्यक SSI/AIO या HTTP/3 को अक्षम करें, कमजोर `alias`/`rewrite`/`map` परिवर्तनीय संदर्भों की समीक्षा करें, और प्रभावितों के लिए अस्थायी `ssl_session_tickets off;` का आकलन करें mTLS सेवाएँ। WAF, ASLR, दर सीमा और कॉन्फ़िगरेशन परिवर्तन केवल कुछ शर्तों को कवर करते हैं और आधिकारिक पैच को प्रतिस्थापित नहीं कर सकते। [S3](https://keendigit.com/hi/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/hi/insights/nginx-remediation-guide#source-4)[S8](https://keendigit.com/hi/insights/nginx-remediation-guide#source-8)[S12](https://keendigit.com/hi/insights/nginx-remediation-guide#source-12) ## 1. भेद्यता अवलोकन और जोखिम निर्णय NGINX ने पांच सुरक्षा मुद्दों को ठीक करते हुए 14 अक्टूबर, 2026 को 1.30.6 (Stable) और 1.31.7 (Mainline) जारी किया। तीन में ढेर ओवरफ़्लो या उपयोग-बाद-मुक्त शामिल हैं और 9.2 / क्रिटिकल के F5 CVSS v4.0 स्कोर प्राप्त हुए। अन्य दो HTTP/3 अनुरोध अखंडता और TLS क्लाइंट प्रमाणपत्र प्रमाणीकरण को प्रभावित करते हैं। [S1](https://keendigit.com/hi/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/hi/insights/nginx-remediation-guide#source-2)[S3](https://keendigit.com/hi/insights/nginx-remediation-guide#source-3) रेटिंग सिस्टम में अंतर करें: nginx.org सभी पांच मुद्दों को `medium` के रूप में सूचीबद्ध करता है, जबकि F5 CVSS v4.0 और कुछ राष्ट्रीय सुरक्षा एजेंसियां तीन मेमोरी मुद्दों को गंभीर के रूप में वर्गीकृत करती हैं। इसका मतलब यह नहीं है कि सभी पांच बिना शर्त रिमोट कोड निष्पादन की अनुमति देते हैं। कॉन्फ़िगरेशन, ट्रैफ़िक पहुंच योग्यता और हमलावर के नियंत्रण से बाहर की स्थितियाँ मायने रखती हैं। मेमोरी भ्रष्टाचार और विश्वसनीय RCE साक्ष्य के विभिन्न स्तर हैं। [S1](https://keendigit.com/hi/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/hi/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/hi/insights/nginx-remediation-guide#source-4) | सीवीई | तकनीकी मुद्दे और विशिष्ट ट्रिगर स्थितियाँ | मूल प्रभाव | मूल्यांकन एवं निपटान | | -------------- | ---------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------ | | CVE-2026-15176 | `alias` पथ मानचित्रण + `rewrite` परिवर्तन URI + मूल्यांकन `$request_filename` | हीप बफ़र ओवरफ़्लो, Worker क्रैश; कुछ शर्तों के तहत संभावित RCE | F5 CVSS v4.0 9.2; समस्या निवारण को प्राथमिकता दें | | CVE-2026-93479 | HTTP/Stream स्क्रिप्ट मूल्यांकन, विशेष रूप से `map` रेगेक्स कैप्चर और root निर्देशिका, लॉग वेरिएबल क्रॉस-रेफरेंस | आरक्षित बफ़र अधिलेखित हो जाता है और ढेर ओवरफ़्लो हो जाता है; कुछ शर्तों के तहत संभावित RCE | F5 CVSS v4.0 9.2; पिछली मरम्मत के बाद प्रतिगमन जोखिम है | | CVE-2026-97205 | SSI वर्चुअल में AIO/एसिंक्रोनस ऑपरेशन शामिल है; बकाया ऑपरेशन गिनती अतिप्रवाह | उपयोग-आफ्टर-फ्री, Worker क्रैश, मेमोरी भ्रष्टाचार; संभावित RCE | F5 CVSS v4.0 9.2; गैर-डिफ़ॉल्ट कॉन्फ़िगरेशन की आवश्यकता है | | CVE-2026-95101 | HTTP/3 अज्ञात फ्रेम बफ़र्स में खंडित है, प्रॉक्सी अनुरोध बॉडी बफ़रिंग सक्षम है | अपस्ट्रीम अनुरोध बॉडी में गैर-DATA बाइट्स को गलत तरीके से इंजेक्ट करना, संभवतः अनुरोध बॉडी आकार सीमा को दरकिनार करना | यह भेद्यता अनुरोध अखंडता को प्रभावित करती है। यह स्वयं रिमोट कोड निष्पादन (आरसीई) प्रदान नहीं करता है। | | CVE-2026-97629 | साझा TLS सत्र कैश, स्वचालित कुंजी रोटेशन और Worker कुंजी मिररिंग | सत्र टिकट जालसाजी; प्रभावित mTLS सेवा के लिए क्लाइंट प्रमाणपत्र प्रमाणीकरण बायपास हो सकता है | प्रमाणपत्र प्रमाणीकरण प्रकार API के व्यावसायिक प्रभाव पर विशेष ध्यान देने की आवश्यकता है | उपरोक्त CVSS स्कोर F5 द्वारा v4.0 का उपयोग करके दिया गया है; एक ही भेद्यता CVSS 3.1, nginx.org के अपने ग्रेड और वितरण गंभीरता रेटिंग में अलग-अलग गंभीरता दिखा सकती है। [S1](https://keendigit.com/hi/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/hi/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/hi/insights/nginx-remediation-guide#source-4) ### 1.1 केवल CVE स्कोर के बजाय परिनियोजन एक्सपोज़र को प्राथमिकता दें | परिनियोजन प्रपत्र | जांच के प्रमुख बिंदु | निपटान प्राथमिकता अनुशंसाएँ | | ----------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- | | सार्वजनिक नेटवर्क रिवर्स प्रॉक्सी, जिसमें अनुकूलित `rewrite`, `alias` और कॉम्प्लेक्स `map` शामिल हैं | CVE-2026-15176, CVE-2026-93479 और मई से जुलाई तक कमजोरियों को फिर से लिखें/मैप करें | P0: ऑडिट करें और तुरंत अपडेट करें | | API / प्रबंधन विमान क्लाइंट प्रमाणपत्र को एकमात्र या मुख्य प्रवेश प्रमाणीकरण के रूप में उपयोग करता है | सत्र टिकट और CVE-2026-97629 का साझा कैश कॉन्फ़िगरेशन | P0: प्रमाणीकरण सीमा और अद्यतन की तुरंत पुष्टि करें | | बाहरी HTTP/3 अपलोड, स्थिति परिवर्तन इंटरफ़ेस, लेनदेन वर्ग API प्रदान करें | CVE-2026-95101, विशेष रूप से अनुरोध निकाय बैकएंड पर प्रॉक्सी किया गया है | पी0/पी1: व्यावसायिक महत्व के अनुसार व्यवस्था करें | | SSI डायनामिक पेज या एसिंक्रोनस फ़ाइल I/O | CVE-2026-97205 | पी1: संयोजन स्थितियों की पुष्टि करें और जितनी जल्दी हो सके मरम्मत करें | | केवल स्थिर पृष्ठ + सरल HTTP/1.1/2 रिवर्स प्रॉक्सी | कॉन्फ़िगरेशन और संस्करण को अभी भी ऑडिट करने की आवश्यकता है, लेकिन कुछ सीवीई शर्तें गायब हो सकती हैं | P1: आपातकालीन सुरक्षा अपग्रेड विंडो में शामिल है | | सेवानिवृत्त Kubernetes समुदाय ingress-nginx का उपयोग करें | परियोजना सुरक्षा रखरखाव बंद कर देती है, और जोखिम इन पांच सीवीई तक सीमित नहीं हैं | एक व्यक्तिगत नियंत्रक माइग्रेशन योजना बनाएं | P0/P1 सार्वजनिक नेटवर्क एक्सपोज़र और प्रमाणन संवेदनशीलता के लिए इस आलेख में दिए गए संचालन और रखरखाव निपटान सुझाव हैं। यह आधिकारिक CVSS वर्गीकरण नहीं है, न ही इसे उद्यम की आंतरिक संपत्ति को प्रतिस्थापित करना चाहिए और जोखिम मूल्यांकन को बदलना चाहिए। ### 1.2 प्रभाव सीमा और हमले की अनुमति इस बैच में मुख्य कमजोरियाँ मुख्य रूप से NGINX डेटा प्लेन में स्थित हैं: हमले का प्रवेश बिंदु क्लाइंट कनेक्शन और अनुरोध है, और वास्तविक प्रभाव आमतौर पर Worker प्रक्रिया में होता है। यदि मेमोरी भ्रष्टाचार के लिए शोषक शर्तें पूरी हो जाती हैं, तो कोड निष्पादन अनुमति आम तौर पर चल रहे उपयोगकर्ता, कंटेनर बाधाओं, लिनक्स क्षमता, माउंटिंग और Worker की नेटवर्क अनुमतियों द्वारा प्रतिबंधित होती है; संभावित RCE स्वचालित रूप से root विशेषाधिकार या होस्ट समझौता नहीं दर्शाता है। [S4](https://keendigit.com/hi/insights/nginx-remediation-guide#source-4) लेकिन भले ही प्रक्रिया गैर-विशेषाधिकार प्राप्त हो, फिर भी इसमें प्रॉक्सी क्रेडेंशियल, प्रमाणपत्र निजी कुंजी वाली पठनीय फ़ाइलें, अपस्ट्रीम सेवा टोकन, अस्थायी फ़ाइलें, आंतरिक API और पहुंच योग्य नेटवर्क तक पहुंच हो सकती है। mTLS के लिए, प्रमाणीकरण बायपास अपने आप में एक गंभीर व्यावसायिक परिणाम हो सकता है, और जरूरी नहीं कि इसके साथ कोड निष्पादन भी हो। ## 2. कारण विश्लेषण ### 2.1 NGINX में तीन त्रुटि-प्रवण सीमाओं को समझें एक NGINX worker एक लंबे समय तक चलने वाली, घटना-संचालित प्रक्रिया है जो अनुरोध स्थिति, अतुल्यकालिक संचालन और प्रोटोकॉल पार्सर को बनाए रखती है। यह भेद्यता तीन इंजीनियरिंग स्तरों पर बाधाओं का प्रतीक है: 1. परिवर्तनीय मूल्यांकन और मेमोरी आकार सुसंगत होना चाहिए: `rewrite` अनुरोध URI को बदलने के बाद, पथ मैपिंग वर्तमान में प्रभावी `location` के अनुरूप होनी चाहिए; जब स्क्रिप्ट दुभाषिया परिवर्तनीय लंबाई की गणना करता है, तो लेखन स्थान को वास्तविक आउटपुट और आरक्षित क्षेत्रों को कवर करना चाहिए। 2. एसिंक्रोनस ऑपरेशंस को अनुरोधित मेमोरी के जीवन चक्र का विस्तार करना चाहिए: जब फ़ाइल पढ़ना और लिखना, कैश प्रतीक्षा या थ्रेड कार्य अधूरे होते हैं, तो संबंधित अनुरोध मेमोरी पूल को पहले से जारी नहीं किया जा सकता है। 3. प्रोटोकॉल स्थिति और सुरक्षा स्थिति को मिश्रित या छोड़ा नहीं जा सकता: HTTP/3 अज्ञात फ़्रेम स्किपिंग की लंबाई को DATA अनुरोध बॉडी लंबाई के रूप में नहीं माना जा सकता है; TLS हस्ताक्षर सत्यापन में भाग लेने वाले सभी कुंजी स्लॉट को सत्र टिकट रोटेशन के दौरान सही ढंग से प्रारंभ और सिंक्रनाइज़ किया जाना चाहिए। निम्नलिखित सामग्री विफलता तंत्र को समझाने के लिए NGINX अपस्ट्रीम फिक्स कमिट और विक्रेता घोषणा पर आधारित है जिसे ट्रिगर किया जा सकता है; उदाहरण खंड विश्लेषण के लिए है, यह संपूर्ण कोड नहीं है जिसका उपयोग सीधे उत्पादन वातावरण को सुधारने के लिए किया जा सकता है। [S5](https://keendigit.com/hi/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/hi/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/hi/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/hi/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/hi/insights/nginx-remediation-guide#source-9) ### 2.2 CVE-2026-15176: `alias` और पुनः लिखे गए URI के बीच पथ मैपिंग अमान्य है। NGINX में, मिलान किए गए `location` और उसके `alias` फ़ाइल पथ निर्धारित करते हैं; `rewrite` वर्तमान अनुरोध URI को बदल सकता है। पुनर्लेखन के बाद, मूल `location` मैपिंग द्वारा उपयोग की गई धारणाएँ अब मान्य नहीं रह सकती हैं। `ngx_http_map_uri_to_path()` में `alias` स्थिति की जाँच करते समय प्रभावित प्रसंस्करण पथ ने पर्याप्त रूप से जाँच नहीं की कि अनुरोध फिर से लिखा गया था या नहीं। जब कॉन्फ़िगरेशन पुनर्लेखन के बाद `$request_filename` का मूल्यांकन करना जारी रखता है, तो पथ का निर्माण उन मान्यताओं के साथ किया जा सकता है जो वर्तमान URI स्थिति के अनुरूप नहीं हैं, अंततः हीप मेमोरी में आउट-ऑफ-बाउंड लिखने को ट्रिगर करता है। [S5](https://keendigit.com/hi/insights/nginx-remediation-guide#source-5) विशिष्ट संयोजन (केवल कॉन्फ़िगरेशन ऑडिट के लिए प्रति उदाहरण के रूप में उपयोग किया जाता है, परिनियोजन की अनुशंसा नहीं की जाती है): ```nginx # 仅用于识别风险模式：不是修复配置 location /foo/ { alias /srv/alias-root/; rewrite ^/foo/.*$ /new-path; return 200 $request_filename; } ``` खतरा `return` तक सीमित नहीं है: `set`, `if`, `add_header`, `log_format`, आदि को भी ऑडिट करने की आवश्यकता है यदि `$request_filename` मूल्यांकन उसी अनुरोध प्रक्रिया में शुरू हो जाता है। उदाहरण में `return` केवल इस राज्य पथ को देखना आसान बनाता है, इसका उपयोग यह अनुमान लगाने के लिए नहीं किया जा सकता है कि सभी उत्पादन कॉन्फ़िगरेशन ओवरफ़्लो उत्पन्न करेंगे। [S5](https://keendigit.com/hi/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/hi/insights/nginx-remediation-guide#source-10) हमले के परिणाम: अनुरोध बनाने से Worker पुनः आरंभ हो सकता है या सेवा बाधित हो सकती है; ASLR के बंद होने या बायपास होने जैसी स्थितियों में, संभावित RCE है। अपस्ट्रीम पैच का मूल `alias` संदर्भ में फिर से लिखे गए URI पथ मैपिंग को पूरा करने से इनकार करना है जो अब मान्य नहीं है, न कि केवल एक निश्चित बफर का विस्तार करना। [S5](https://keendigit.com/hi/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/hi/insights/nginx-remediation-guide#source-10) ### 2.3 CVE-2026-93479: स्क्रिप्ट मूल्यांकन में "आरक्षित स्थान" और वास्तविक चर लंबाई के बीच बेमेल NGINX के HTTP और Stream मॉड्यूल में स्क्रिप्ट मूल्यांकनकर्ता होते हैं जो शाब्दिक स्ट्रिंग और परिवर्तनीय मानों को परिणाम स्ट्रिंग में जोड़ते हैं। एप्लिकेशन उदाहरणों में HTTP दस्तावेज़ root पथ, एक्सेस लॉग पथ और Stream में परिवर्तनीय अभिव्यक्ति शामिल हैं। `map` + रेगुलर एक्सप्रेशन के कुछ कॉन्फ़िगरेशन `map` परिणाम चर के मूल्यांकन से पहले कैप्चर किए गए मानों को अन्य एक्सप्रेशन द्वारा पढ़ने की अनुमति देते हैं। आरक्षित लंबाई के साथ स्क्रिप्ट निष्पादन विधि के साथ संयुक्त, पुराना कार्यान्वयन `len` आरक्षित स्थान को पहले से मूल्यांकित लंबाई संचायक में गिना जाएगा, ताकि बाद में लिखने वाले सूचक गणना बफर सीमा के अनुरूप न हो। एक विशिष्ट चर मूल्यांकन अनुक्रम में, बाद में स्ट्रिंग लेखन आरक्षित क्षेत्र को अधिलेखित कर सकता है, जिससे ढेर अतिप्रवाह हो सकता है। [S6](https://keendigit.com/hi/insights/nginx-remediation-guide#source-6) | सहभागी तत्व | यह ध्यान देने योग्य क्यों है? | | ------------------------------------ | ----------------------------------------------------------------------------------------------------------------------------- | | `map` में रेगेक्स | कैप्चर वैरिएबल मूल्यांकन में स्वतंत्र जीवन चक्र और कैशिंग व्यवहार हो सकता है | | अनाम कैप्चर जैसे `$1`, `$2`, आदि। | आसानी से अन्य नियमित अभिव्यक्तियों या भावों द्वारा अधिलेखित कर दिया जाता है, जिससे स्वामित्व को ट्रैक करना मुश्किल हो जाता है | | `root` में चर | पथ निर्माण को ट्रिगर करते समय स्क्रिप्ट निष्पादन और बफर आरक्षण | | `log_format`/डायनामिक लॉग पथ | अनुरोध में बाद में उसी प्रकार का मूल्यांकन शुरू किया जा सकता है | | `stream` में स्क्रिप्ट अभिव्यक्तियाँ | अपस्ट्रीम फिक्स `ngx_stream_script_run()` को भी संशोधित करता है। आप केवल HTTP मॉड्यूल की समीक्षा नहीं कर सकते. | महत्वपूर्ण प्रतिगमन संबंध: इस भेद्यता से संबंधित कोड पिछले परिवर्तनों से संबंधित है जो CVE-2026-42533 को ठीक करता है। Debian 13 के लिए आधिकारिक DSA स्पष्ट रूप से बताता है कि प्रभावित कोड को पुराने सुरक्षा बैकपोर्ट के माध्यम से trixie पैकेज में पेश किया गया था। इसलिए, "जुलाई `map` भेद्यता पैच स्थापित किया गया है" का मतलब यह नहीं है कि अक्टूबर के CVE-2026-93479 को कवर कर दिया गया है; पूर्ण सुरक्षा सुधार श्रृंखला की जाँच की जानी चाहिए। [S6](https://keendigit.com/hi/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/hi/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/hi/insights/nginx-remediation-guide#source-17) यहां संभावित RCE जोखिम मेमोरी सुरक्षा वातावरण से संबंधित है, और यह दावा नहीं किया जाना चाहिए कि अकेले `map` रेगेक्स का अज्ञात हमलावरों द्वारा शोषण किया जा सकेगा। [S11](https://keendigit.com/hi/insights/nginx-remediation-guide#source-11) ### 2.4 CVE-2026-97205: AIO अधूरा ऑपरेशन काउंट रैपअराउंड कारण उपयोग-आफ्टर-फ्री यह भेद्यता केवल "SSI चालू करें और आपको UAF मिलेगा" नहीं है। कुंजी मुख्य अनुरोध द्वारा रखे गए एसिंक्रोनस ऑपरेशन संदर्भ गणना में निहित है। NGINX अतुल्यकालिक प्रसंस्करण को ट्रैक करने के लिए `r->main->blocked` का उपयोग करें जो अभी तक पूरा नहीं हुआ है, पुराने कार्यान्वयन में यह 8-बिट गिनती थी; कुछ पथों ने गिनती बढ़ाने से पहले ऊपरी सीमा की जाँच नहीं की। जब वही मुख्य अनुरोध 256 बकाया परिचालनों को जमा करता है, तो गिनती 255 से 0 तक हो सकती है। बाद की प्रक्रियाएं गलती से मान लेंगी कि अनुरोध को जारी होने से रोकने वाला कोई अतुल्यकालिक ऑपरेशन नहीं है, जिससे अनुरोध मेमोरी पूल जारी हो जाता है जो अभी भी कार्य द्वारा संदर्भित है। [S7](https://keendigit.com/hi/insights/nginx-remediation-guide#source-7) विफलता प्रक्रिया को इसमें विभाजित किया जा सकता है: 1. संबंधित एसिंक्रोनस I/O/थ्रेड पथ सक्षम होने के साथ, SSI पृष्ठ `include virtual` के माध्यम से एकाधिक उपअनुरोध या रीड ऑपरेशंस प्रस्तुत करता है। 2. एक निश्चित मुख्य अनुरोध के बकाया संचालन गिनती फ़ील्ड द्वारा दर्शाई गई ऊपरी सीमा तक जमा होते हैं। 3. 8-बिट गिनती चारों ओर घूमती है, जिसे गलत तरीके से "कोई लंबित संचालन नहीं" के रूप में व्यक्त किया जाता है। 4. अनुरोध मेमोरी पूल जारी किया गया है, जबकि फ़ाइल पढ़ी जाती है, कैश प्रतीक्षा करता है, या थ्रेड कार्यों के कॉलबैक अभी भी इसके संदर्भ बनाए रखते हैं। 5. बाद के एसिंक्रोनस पूर्ण कॉलबैक जारी मेमोरी तक पहुंचते हैं, जिसके परिणामस्वरूप UAF, Worker क्रैश या संभावित मेमोरी भ्रष्टाचार होता है। आधिकारिक फिक्स अनुरोध हेडर फ़ाइल में `NGX_HTTP_MAX_BLOCKED 250` जोड़ता है, और आउटपुट फ़िल्टर, कैश रीड और अपस्ट्रीम थ्रेड पथ पर प्रतिबंध जोड़ता है; जब सीमा पूरी हो जाती है, तो समकालिक पथों के साथ संचालन समकालिक रूप से पूरा हो जाता है, और यदि उन्हें सुरक्षित रूप से संसाधित नहीं किया जा सकता है, तो लंबित कार्यों को आगे जोड़ने से इनकार कर दिया जाएगा। [S7](https://keendigit.com/hi/insights/nginx-remediation-guide#source-7) प्रयोज्यता निर्णय: इसका मूल्यांकन किया जाना चाहिए कि क्या SSI, AIO, आभासी समावेशन, उपअनुरोध और संबंधित अतुल्यकालिक संचालन एक ही अनुरोध श्रृंखला में संयोजन में हो सकते हैं। ये आमतौर पर डिफ़ॉल्ट सादा स्थैतिक प्रॉक्सी कॉन्फ़िगरेशन नहीं होते हैं। `aio off;` या `ssi off;` विशिष्ट ट्रिगर तत्वों को हटा सकते हैं, लेकिन व्यावसायिक फ़ंक्शन निर्भरता की पहले पुष्टि की जानी चाहिए। [S4](https://keendigit.com/hi/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/hi/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/hi/insights/nginx-remediation-guide#source-25) ### 2.5 CVE-2026-95101: HTTP/3 अज्ञात फ़्रेम DATA अनुरोध निकाय की स्थिति के साथ भ्रमित है HTTP/3 फ़्रेम पार्सर को `DATA` फ़्रेम (जिसे HTTP अनुरोध बॉडी प्रोसेसिंग में पारित करने की आवश्यकता है) और अज्ञात फ़्रेम जिन्हें छोड़ दिया जाना चाहिए, के बीच अंतर करना होगा। नेटवर्क बफ़र्स में विखंडन करते समय अज्ञात फ़्रेमों की लंबाई भी सटीक रूप से संरक्षित की जानी चाहिए। `ngx_http_v3_parse_data()` के पुराने कार्यान्वयन ने अज्ञात फ्रेम को छोड़ते समय "छोड़े जाने वाले बाइट्स की शेष संख्या" को बचाने के लिए `st->length` फ़ील्ड का उपयोग किया था, जबकि अनुरोध बॉडी फ़िल्टर ने उसी फ़ील्ड को "शेष DATA पेलोड लंबाई" के रूप में व्याख्या किया था। यदि अज्ञात फ्रेम एकाधिक पार्स कॉल को फैलाता है, तो पार्सिंग बाधित होने के बाद बाइट्स के अगले बैच को अनुरोध निकाय के हिस्से के रूप में गलती से देखा जा सकता है। [S8](https://keendigit.com/hi/insights/nginx-remediation-guide#source-8) दो प्रकार के जोखिम उत्पन्न होते हैं: - अनुरोध बॉडी इंजेक्शन: क्लाइंट द्वारा सबमिट किया गया गैर-DATA फ़्रेम पेलोड अपस्ट्रीम एप्लिकेशन में प्रेषित किया जा सकता है, जिससे बैकएंड द्वारा वास्तव में प्राप्त डेटा बदल जाता है। - आकार सीमा बाईपास: `client_max_body_size` और अन्य प्रतिबंध। अपेक्षित जाँचें DATA पथ पर केंद्रित हैं, और गलत तरीके से परिवर्तित सामग्री संबंधित सत्यापन को बायपास कर सकती है। अधिकारी द्वारा वर्णित विशिष्ट ट्रिगर परिदृश्य तब होता है जब `ngx_http_v3_module` HTTP/3 अनुरोध प्राप्त करता है और `proxy_request_buffering on` को अग्रेषित करता है। `ngx_http_proxy_module` में प्रॉक्सी अनुरोध बॉडी बफ़रिंग डिफ़ॉल्ट रूप से सक्षम है। इसलिए, HTTP/3 को चालू करने वाली रिवर्स प्रॉक्सी को पहले जांचना चाहिए। यह मान लेना उचित नहीं है कि कोई ट्रिगर स्थिति नहीं है क्योंकि `proxy_request_buffering on;` स्पष्ट रूप से नहीं लिखा गया है। [S8](https://keendigit.com/hi/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/hi/insights/nginx-remediation-guide#source-18) इस भेद्यता का सीधा परिणाम बैकएंड अनुरोध अखंडता और सुरक्षा सीमा परिवर्तन से संबंधित है, जो सीधे NGINX कोर में पूर्ण RCE के समकक्ष अभिव्यक्ति नहीं है। अंतिम व्यावसायिक प्रभाव इस बात पर निर्भर करता है कि इन बाइट्स को कैसे पार्स किया जाता है और अपस्ट्रीम पर भरोसा किया जाता है। [S24](https://keendigit.com/hi/insights/nginx-remediation-guide#source-24) ### 2.6 CVE-2026-97629: TLS टिकट रोटेशन से तीसरा कुंजी स्लॉट छूट जाता है प्रभावित कॉन्फ़िगरेशन में, NGINX स्वचालित रूप से साझा मेमोरी कैश के माध्यम से TLS सत्र टिकट कुंजी उत्पन्न और घुमा सकता है, जिससे कई Worker को टिकटों के एक ही बैच को संसाधित करने की अनुमति मिलती है। प्रासंगिक सिंक्रनाइज़ेशन तर्क प्रत्येक Worker के लिए 3 कुंजी स्लॉट आवंटित करता है, और डिक्रिप्शन कॉलबैक भी इन स्लॉट्स को पार करेगा; लेकिन पुराना कार्यान्वयन हर बार साझा मेमोरी से केवल 2 कुंजी स्लॉट की प्रतिलिपि बनाता है, जिसके परिणामस्वरूप कुंजी का नाम, एचएमएसी कुंजी और तीसरे स्लॉट का एईएस होता है। कुंजी अप्रारंभीकृत रह सकती है. यदि किसी टिकट का मुख्य पहचानकर्ता इस स्थिति से मेल खाता है, तो हस्ताक्षर सत्यापन और डिक्रिप्शन के लिए अप्रारंभीकृत कुंजी सामग्री का उपयोग किया जा सकता है, इस प्रकार TLS सत्र बनाने के लिए एक पथ बनाया जा सकता है। [S9](https://keendigit.com/hi/insights/nginx-remediation-guide#source-9) उच्च जोखिम वाले परिनियोजन संयोजन आमतौर पर होते हैं: ```nginx # 仅为排查触发条件所示：共享缓存本身不是恶意配置 ssl_session_cache shared:SSL:10m; # 未显式配置 ssl_session_ticket_key 文件，使用自动轮换机制 ``` इस भेद्यता का सबसे गंभीर व्यावसायिक परिणाम यह है कि `ssl_verify_client on;` और अन्य तरीकों से क्लाइंट प्रमाणपत्र प्रमाणीकरण (mTLS) का उपयोग करने वाली सेवाओं पर, जाली पुनर्प्राप्ति सत्र क्लाइंट प्रमाणपत्र सत्यापन को बायपास कर सकते हैं। हमले की सफलता अनियंत्रित परिस्थितियों पर भी निर्भर करती है; ऐसी साइट जो केवल सामान्य सर्वर-साइड HTTPS प्रमाणपत्र का उपयोग करती है और क्लाइंट प्रमाणपत्र प्रमाणीकरण नहीं करती है, उसे गलत तरीके से पेश नहीं किया जाना चाहिए क्योंकि "हमलावर संपूर्ण वेबसाइट लॉगिन को बायपास कर सकता है।" [S9](https://keendigit.com/hi/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/hi/insights/nginx-remediation-guide#source-12) यह एक TLS सत्र प्रमाणीकरण स्थिति समस्या है और इसका इससे कोई लेना-देना नहीं है कि सर्वर की TLS निजी कुंजी क्रैक हो गई है या सार्वजनिक CA root प्रमाणपत्र प्रभावित है या नहीं। [S24](https://keendigit.com/hi/insights/nginx-remediation-guide#source-24) ### 2.7 DoS, RCE, प्रमाणीकरण बाईपास और ज्ञात कारनामों को कैसे समझें - DoS: मेमोरी त्रुटि के कारण Worker क्रैश हो जाता है या बड़े पैमाने पर रीबूट हो जाता है। चाहे यह समग्र अनुपलब्धता का कारण हो, यातायात दबाव, प्रक्रिया पुनरारंभ क्षमता, कनेक्शन रखरखाव समय और उच्च-उपलब्धता वास्तुकला से संबंधित है। - संभावित RCE: कुछ घोषणाओं से संकेत मिलता है कि ASLR बंद होने या बायपास होने पर कोड निष्पादन की संभावना है। इसका मतलब यह नहीं है कि एक सार्वजनिक आक्रमण श्रृंखला जो आदेशों को स्थिर और सार्वभौमिक रूप से निष्पादित कर सकती है, का खुलासा किया गया है। [S4](https://keendigit.com/hi/insights/nginx-remediation-guide#source-4) - इंजेक्शन/प्रमाणीकरण बाईपास का अनुरोध करें: यह सीधे संरक्षित व्यवसाय स्थिति को बदल सकता है या सामग्री का अनुरोध कर सकता है, और इसे केवल इसलिए नजरअंदाज नहीं किया जा सकता क्योंकि यह सीधे शेल प्राप्त नहीं करता है। - हमले के प्रयासों का पता चला है: मई 2026 में CVE-2026-42945 में जंगली शोषण गतिविधियों की रिपोर्ट है; इस ऐतिहासिक तथ्य का सीधे तौर पर यह अर्थ नहीं निकाला जाना चाहिए कि अक्टूबर में सभी पांच सीवीई का बड़े पैमाने पर सफलतापूर्वक दोहन किया गया है। [S23](https://keendigit.com/hi/insights/nginx-remediation-guide#source-23) ## 3. मरम्मत संस्करण और पैच चयन ### 3.1 NGINX Open Source आधिकारिक पैच बेसलाइन | अपस्ट्रीम शाखा | अक्टूबर में पांच कमजोरियों को कवर करने वाला पहला आधिकारिक संस्करण | 2026-10-27 के अनुसार अनुशंसाएँ | | -------------------------------- | ------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------------------- | | Stable 1.30.x | 1.30.6（2026-10-14） | कम से कम 1.30.6 स्थापित करें, और बाद के सुरक्षा संस्करणों का पालन करें। | | Mainline 1.31.x | 1.31.7（2026-10-14） | 1.31.8（2026-10-21） | | पहले वाली NGINX Open Source शाखा | इसका निर्णय केवल "पुराने भेद्यता पैच लागू किए गए हैं" के आधार पर नहीं किया जा सकता है | पहले अनुरक्षित शाखा में स्थानांतरित करें; अन्यथा, विक्रेता को CVE-by-CVE आधार पर समर्थन का औपचारिक साक्ष्य प्रदान करना आवश्यक है। | ये nginx.org अपस्ट्रीम स्रोत कोड/आधिकारिक शाखा के संस्करण निष्कर्ष हैं, और वितरण विक्रेता द्वारा प्रदान किए गए बैकपोर्टेड फिक्स के साथ सुरक्षा पैकेज को सीधे अस्वीकार करने के लिए इसका उपयोग नहीं किया जाना चाहिए। भले ही `1.31.6` का मान `1.30.6` से अधिक हो, फिर भी यह मेनलाइन शाखा की पैच बेसलाइन से कम है। [S1](https://keendigit.com/hi/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/hi/insights/nginx-remediation-guide#source-2) ### 3.2 पांच सीवीई का अपस्ट्रीम प्रभाव दायरा निम्नलिखित श्रेणियाँ nginx.org सुरक्षा बुलेटिन के मूल पाठ के अनुसार सूचीबद्ध हैं और इन्हें "वर्तमान चल रही शाखा" और "वास्तविक कॉन्फ़िगरेशन पथ" के साथ संयोजन में समझने की आवश्यकता है: | सीवीई | अपस्ट्रीम टैग ने संस्करणों को प्रभावित किया | आधिकारिक तौर पर निश्चित संस्करण लेबल किया गया | | -------------- | ------------------------------------------- | --------------------------------------------------- | | CVE-2026-15176 | `0.1.29–1.31.6` | `1.30.6+` या `1.31.7+`, उनकी संबंधित शाखाओं के भीतर | | CVE-2026-93479 | `1.30.0–1.30.5`，`1.31.2–1.31.6` | ऊपर जैसा ही | | CVE-2026-97205 | `0.8.11–1.31.6` | ऊपर जैसा ही | | CVE-2026-95101 | `1.25.0–1.31.6` | ऊपर जैसा ही | | CVE-2026-97629 | `1.23.2–1.31.6` | ऊपर जैसा ही | CVE-2026-93479 की विशिष्ट परिचय-संस्करण सीमाएँ हैं; प्रत्येक पुराना NGINX संस्करण इस प्रतिगमन से प्रभावित नहीं है। उन श्रेणियों के बाहर के पुराने संस्करण अभी भी पहले के `map` रेगेक्स भेद्यता CVE-2026-42533 से प्रभावित हो सकते हैं। [S1](https://keendigit.com/hi/insights/nginx-remediation-guide#source-1) ### 3.3 Ubuntu: वितरण बैकपोर्ट (USN-8955-1) Canonical USN-8955-1 अक्टूबर 26, 2026 चार Ubuntu बिल्ड के लिए सुरक्षा अद्यतन प्रदान करता है: [S13](https://keendigit.com/hi/insights/nginx-remediation-guide#source-13) | Ubuntu संस्करण | `nginx` और वही स्रोत पैकेज निश्चित संस्करण | विवरण | | -------------- | ------------------------------------------ | ---------------------------------------------------------------------------- | | 22.04 LTS | `1.18.0-6ubuntu14.22` | यह एक विक्रेता बैकपोर्ट है; अपस्ट्रीम संस्करण संख्या अभी भी 1.18.0 दिखाती है | | 24.04 LTS | `1.24.0-2ubuntu7.19` | ऊपर जैसा ही | | 26.04 LTS | `1.28.3-2ubuntu1.12` | ऊपर जैसा ही | | 26.10 | `1.30.4-7ubuntu1.1` | ऊपर जैसा ही | घोषणा में `nginx-core`, `nginx-extras`, `nginx-full`, और `nginx-light` जैसे सजातीय पैकेजों के संबंधित निश्चित संस्करण शामिल हैं। केवल `nginx -v` द्वारा दिखाए गए अपस्ट्रीम भाग से इसे ठीक करना है या नहीं, इसके बारे में निष्कर्ष न निकालें। जैसे कि Ubuntu 24.04 और `1.24.0-2ubuntu7.19` को इस विक्रेता द्वारा पैच किया गया है, लेकिन किसी भी स्रोत से `1.24.0` स्वाभाविक रूप से सुरक्षित नहीं है। Ubuntu ने आधिकारिक तौर पर यह भी स्पष्ट रूप से चिह्नित किया है कि CVE-2026-95101 केवल Ubuntu 26.04 / 26.10 को प्रभावित करता है, और CVE-2026-97629 केवल Ubuntu 24.04 / 26.04 को प्रभावित करता है /26.10. यहां Ubuntu की अपनी पैकेजिंग और कार्यात्मक दायरा है, जिसे सीधे अन्य वितरणों में प्रचारित नहीं किया जा सकता है। [S13](https://keendigit.com/hi/insights/nginx-remediation-guide#source-13) ### 3.4 Debian: संस्करणों के बीच अंतर को अलग से जांचा जाना चाहिए Debian सलाहकार DSA-6575-1 (2026-10-21) इन पांच CVE को कवर करता है और Debian 13 / trixie के लिए निश्चित `nginx` पैकेज की पहचान करता है: ```text 1.26.3-3+deb13u10 ``` हालाँकि, इस रिपोर्ट के सत्यापन के समय तक, Debian 12 / bookworm के लिए `1.22.1-9+deb12u10` को अभी भी Debian सुरक्षा ट्रैकर द्वारा असुरक्षित के रूप में चिह्नित किया गया है। इसलिए: - Debian 13 बस DSA-6575-1 के अनुसार अद्यतन करें और स्वीकार करें। - Debian 12 को वर्तमान सुरक्षा ट्रैकर या ELTS विक्रेता द्वारा प्रदान किए गए सुरक्षा सुधारों की एक-एक करके जांच करनी चाहिए; घोषणा में सुधार की पुष्टि होने से पहले, यह घोषणा न करें कि `apt upgrade` की सफलता के आधार पर सभी पांच आइटम ठीक कर दिए गए हैं। - Debian स्रोत पैकेज में nginx.org संस्करण संख्या से स्वतंत्र एक पैच सेट हो सकता है। कस्टम बिल्ड के लिए, आपको संपूर्ण स्रोत कोड पैकेज फिक्स सेट की जांच करने की आवश्यकता है, और आप केवल एक अपस्ट्रीम कमिट की प्रतिलिपि नहीं बना सकते हैं और इसे पूर्ण नहीं मान सकते हैं। उपरोक्त अंतर डीएसए और सीवीई ट्रैकिंग रिकॉर्ड पर आधारित है। [S14](https://keendigit.com/hi/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/hi/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/hi/insights/nginx-remediation-guide#source-16) ### 3.5 NGINX Plus, njs और इनग्रेस कंट्रोलर | उत्पाद/घटक | सुरक्षा चयन और सत्यापन मुख्य बिंदु | | -------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- | | NGINX Plus (व्यावसायिक संस्करण) | कृपया F5 के अनुरूप प्लस शाखा की घोषणा और अपग्रेड निर्देश देखें। सत्यापन के समय नवीनतम सीआर `PLS.37.2.0.1` है, और LTS का सुरक्षा निर्माण `PLS.37.0.7.1` है; प्लस संस्करण और शामिल बैकपोर्ट को सीधे ओपन सोर्स के 1.30/1.31 थ्रेशोल्ड द्वारा प्रतिस्थापित नहीं किया जा सकता है। [S19](https://keendigit.com/hi/insights/nginx-remediation-guide#source-19) | | njs / ngx\_http\_js\_module | 2026-10-14 `njs 1.0.2` को रिलीज़ करता है और CVE-2026-101019 और CVE-2026-101025 को ठीक करता है; यदि आप njs का उपयोग कर रहे हैं, तो आपको NGINX के साथ मॉड्यूल की संगतता भी जांचनी होगी। [S20](https://keendigit.com/hi/insights/nginx-remediation-guide#source-20) | | F5 NGINX इनग्रेस कंट्रोलर / गेटवे फैब्रिक | NGINX कोर एक संबंधित लेकिन स्वतंत्र सॉफ्टवेयर वितरण श्रृंखला है। प्रासंगिक कमजोरियों को उनके संबंधित नियंत्रकों, छवियों और रिलीज़ नोट्स के साथ ठीक करें। आप पॉड में केवल NGINX बाइनरी को प्रतिस्थापित नहीं कर सकते। | | Kubernetes समुदाय `kubernetes/ingress-nginx` | यह परियोजना मार्च 2026 में बंद हो गई है और अब कोई नया सुरक्षा रखरखाव प्रदान नहीं करेगी। आपको इसके रिलीज़ नंबर को F5 NGINX इनग्रेस कंट्रोलर समझने के बजाय एक अनुरक्षित नियंत्रक या Gateway API पर माइग्रेट करने की योजना बनानी चाहिए। [S21](https://keendigit.com/hi/insights/nginx-remediation-guide#source-21) | ### 3.6 आपको वास्तव में कौन सा पैच चुनना चाहिए? | परिनियोजन प्रपत्र | अनुशंसित प्रथाएँ | मरम्मत का प्रमाण | | ------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------- | | nginx.org आधिकारिक DEB/RPM पैकेज | अपस्ट्रीम शाखा के निश्चित संस्करण में अपग्रेड करें | `nginx -v/-V`, पैकेज स्रोत, आधिकारिक सुरक्षा घोषणा | | Ubuntu/Debian आधिकारिक भंडार | विक्रेता सुरक्षा पैकेज स्थापित करें | पूर्ण पैकेज संस्करण + विक्रेता यूएसएन/डीएसए + सीवीई स्थिति | | आरएचईएल/अल्मा/रॉकी/एसयूएसई/अन्य वितरण | विशिष्ट वितरण सुरक्षा बुलेटिन और पैकेज संस्करणों के अनुसार अपग्रेड करें | संबंधित विक्रेता CSAF/घोषणा, Ubuntu/Debian संस्करण लागू नहीं किया जा सकता | | आधिकारिक या कस्टम कंटेनर छवियाँ | सत्यापित मरम्मत छवि को फिर से बनाएं या खींचें और इसे रोलिंग आधार पर बदलें | इमेज डाइजेस्ट, एसबीओएम का निर्माण, पॉड/कंटेनर इमेज आईडी चलाना | | स्व-संकलित NGINX, OpenResty, Tengine या तृतीय-पक्ष मॉड्यूल के साथ पैच किए गए संस्करण | अनुरक्षक के पूर्ण सुरक्षा संस्करण के उपयोग को प्राथमिकता दें; आवश्यक होने पर लक्ष्य स्रोत ट्री के लिए समीक्षा किए गए पैच बैकपोर्ट निष्पादित करें | पांच भेद्यता समाधान, एबीआई/मॉड्यूल अनुकूलता, इकाई और व्यवसाय प्रतिगमन | OpenResty और Tengine अलग-अलग रिलीज़ सिस्टम हैं; यह तालिका केवल सत्यापन विधि का वर्णन करती है। इसका मतलब यह नहीं है कि इसके सभी संस्करण मानक NGINX के समान ही प्रभावित होंगे, न ही अपस्ट्रीम कोड पैच को बिना शर्त लागू किया जा सकता है। ## 4. औपचारिक मरम्मत प्रक्रिया ### 4.1 बाहरी ट्रैफ़िक प्राप्त करने के वास्तविक उदाहरणों की सूची प्रत्येक प्रविष्टि के लिए कम से कम मिलान करें: - डोमेन नाम, लोड बैलेंसिंग/CDN/एज प्रॉक्सी लिंक, मूल साइट एक्सपोज़र विधि और नेटवर्क प्रोटोकॉल का उपयोग किया गया। - NGINX उत्पाद (ओपन सोर्स, प्लस, इनग्रेस, आदि), पूर्ण संस्करण, पैकेज रिपॉजिटरी स्रोत, इमेज डाइजेस्ट। - `nginx -V` बिल्डिंग मॉड्यूल और संकलन पैरामीटर प्रदर्शित करता है; क्या njs, Lua, OpenResty और तृतीय-पक्ष डायनामिक मॉड्यूल हैं। - रियल रनिंग master/worker PID, सर्विस यूनिट/कंटेनर/पॉड, रेप्लिका और Worker नोड। - वास्तविक प्रभावी `http`/`stream`, `server`, `location`, `include` कॉन्फ़िगरेशन। - क्या HTTP/3, mTLS, SSI/AIO, डायनेमिक लॉग पथ, कॉम्प्लेक्स `map` और रेगेक्स कैप्चर को सक्षम करना है। केवल डिफ़ॉल्ट `/etc/nginx/nginx.conf` की जाँच न करें। उत्पादन वातावरण अक्सर `include` के माध्यम से कई साइटों, TLS और मॉड्यूल कॉन्फ़िगरेशन को लोड करता है। कई NGINX इंस्टॉलेशन पथ या कई प्रॉक्सी परतें भी हो सकती हैं। ### 4.2 संस्करण और संकलन जानकारी की जाँच करें ```bash # NGINX 版本及构建选项 nginx -v nginx -V 2>&1 # Linux：查看实际运行的 NGINX 进程 ps -eo pid,ppid,user,comm,args | grep '[n]ginx' # Debian / Ubuntu：查看完整已安装包版本、来源 apt-cache policy nginx # 兼顾 nginx-core / nginx-full / nginx-extras 等实际已安装包 dpkg-query -W 'nginx*' 2>/dev/null # RPM 系：以实际安装包及仓库公告为准 rpm -qa | grep '^nginx' ``` `nginx -V` कमांड-लाइन पथ पर पाए गए बाइनरी के निर्माण की रिपोर्ट करता है; यह साबित नहीं करता कि चल रहे worker ने इसे लोड किया है। `nginx -v` वितरण के पूर्ण पैकेज प्रत्यय को छोड़ सकता है, इसलिए पैकेज प्रबंधक या आपूर्ति-श्रृंखला रिकॉर्ड की भी जांच करें। ### 4.3 प्रभावी कॉन्फ़िगरेशन निर्यात करें और स्थैतिक स्क्रीनिंग का पहला दौर निष्पादित करें `nginx -T` कॉन्फ़िगरेशन का परीक्षण करेगा और मर्ज किए गए कॉन्फ़िगरेशन को डंप करेगा। आउटपुट में संवेदनशील जानकारी जैसे प्रमाणीकरण क्रेडेंशियल, कुंजी पथ, आंतरिक होस्ट नाम इत्यादि शामिल हो सकते हैं। नियंत्रित टर्मिनल को root अनुमतियों और निजी फ़ाइल अनुमतियों के साथ सहेजने की अनुशंसा की जाती है, और मूल फ़ाइलों को सार्वजनिक कार्य आदेशों पर पोस्ट नहीं किया जाता है: ```bash sudo sh -c 'umask 077; nginx -T > /root/nginx-effective.conf 2> /root/nginx-config-check.log' sudo grep -nE \ 'alias|rewrite|map[[:space:]]|request_filename|aio[[:space:]]|ssi[[:space:]]|quic|http3|proxy_request_buffering|ssl_session_cache|ssl_session_ticket_key|ssl_session_tickets|ssl_verify_client|log_format|root[[:space:]]' \ /root/nginx-effective.conf ``` यह केवल उम्मीदवार पथ लोकेटर है, विश्वसनीय सीवीई स्वचालित निर्धारण उपकरण नहीं: 1. `grep` यह निर्धारित नहीं कर सकता है कि चर समान `location` या समान अनुरोध मूल्यांकन श्रृंखला में स्थित हैं या नहीं, न ही यह कॉन्फ़िगरेशन इनहेरिटेंस संबंध का अनुमान लगा सकता है। 2. `proxy_request_buffering on`, कुछ कैश और टिकट कॉन्फ़िगरेशन में डिफ़ॉल्ट मान होते हैं, और संबंधित निर्देश नहीं लिखने का मतलब यह नहीं है कि जोखिम गायब हो जाता है। 3. रिवर्स प्रॉक्सी, CDN, कंटेनर साइडकार, या नियंत्रक द्वारा उत्पन्न कॉन्फ़िगरेशन मैन्युअल रूप से निरीक्षण की गई फ़ाइलों से भिन्न हो सकते हैं। 4. `NGINX Plus` और गतिशील मॉड्यूल की विशेषताओं को उनके संबंधित आधिकारिक प्रबंधन टूल का उपयोग करके पुष्टि करने की आवश्यकता हो सकती है। ### 4.4 विश्वसनीय चैनलों के माध्यम से फिक्स तैनात करें Debian/Ubuntu (आधिकारिक वितरण भंडार): ```bash sudo apt-get update apt-cache policy nginx # 升级发行版仓库中已经安装的 NGINX 及相关包； # 先确认 Candidate 属于修复版本，再执行升级。 sudo apt-get install --only-upgrade nginx # 对实际安装的 nginx-core / nginx-full / nginx-extras 等包 # 确认它们的版本和依赖一同达到厂商修复要求。 dpkg-query -W 'nginx*' 2>/dev/null ``` आदेशों का यह सेट हवा में सुरक्षा समाधान उत्पन्न नहीं कर सकता जो अभी तक उपलब्ध नहीं हैं। विशेष रूप से Debian 12 के लिए, यदि उन्नत पैकेज को अभी भी सुरक्षा ट्रैकिंग सिस्टम द्वारा असुरक्षित माना जाता है, तो अतिरिक्त विक्रेता मरम्मत, अलगाव या माइग्रेशन उपायों की आवश्यकता होती है। [S13](https://keendigit.com/hi/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/hi/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/hi/insights/nginx-remediation-guide#source-15) nginx.org आधिकारिक पैकेज: ```bash # 先确认仓库来自 nginx.org、目标分支和候选版本 apt-cache policy nginx # 经变更审批后再执行对应仓库的升级命令 sudo apt-get install --only-upgrade nginx ``` यदि स्व-संकलित, OpenResty, Tengine या NGINX Plus का उपयोग कर रहे हैं, तो संबंधित अनुरक्षक द्वारा समर्थित फिक्स संस्करण का उपयोग करें और nginx.org, वितरण और तृतीय-पक्ष रिपॉजिटरी पैकेजों को मिश्रित न करें। मूल बायनेरिज़/छवियां, कॉन्फ़िगरेशन, हस्ताक्षर और रोलबैक परिनियोजन मैनिफ़ेस्ट को संरक्षित किया जाना चाहिए। कंटेनर/Kubernetes: अपरिवर्तनीय छवि को अपडेट करें, इसके डाइजेस्ट को रिकॉर्ड करें और सभी पुरानी प्रतिकृतियों को एक चरणबद्ध रोलआउट के साथ बदलें। `kubectl rollout status` केवल पुष्टि करता है कि परिनियोजन नियंत्रक समाप्त हो गया है; इमेज डाइजेस्ट, इनग्रेस रूटिंग और अस्वस्थ प्रतिकृतियों को भी सत्यापित करें। ### 4.5 कॉन्फ़िगरेशन सत्यापित करें और पुराने Worker को बदलें ```bash sudo nginx -t # 按服务实际名称、主机高可用和变更窗口执行重启 sudo systemctl restart nginx sudo systemctl status nginx --no-pager # 核查真正存在的 master / worker ps -eo pid,ppid,user,comm,args | grep '[n]ginx' ``` `nginx -s reload` को इस बात का प्रमाण न मानें कि एक नया बाइनरी चल रहा है: सामान्य कॉन्फ़िगरेशन पुनः लोड पुराने master को उसके निष्पादन योग्य को प्रतिस्थापित किए बिना नए श्रमिकों को शुरू करने देता है। NGINX एक समर्पित ऑनलाइन बाइनरी अपग्रेड प्रक्रिया का समर्थन करता है, लेकिन इसके लिए अतिरिक्त चरणों और सत्यापन की आवश्यकता होती है। किसी स्थापित प्रक्रिया के बिना, उच्च-उपलब्धता वाले ट्रैफ़िक स्विच का उपयोग करें और उसके बाद सेवा पुनरारंभ करें, या प्रतिस्थापन कंटेनरों को रोल आउट करें। [S22](https://keendigit.com/hi/insights/nginx-remediation-guide#source-22) यदि आप `systemd` सॉकेट, कंटेनर एंट्री स्क्रिप्ट, या एकाधिक इंस्टॉलेशन के माध्यम से NGINX का प्रबंधन करते हैं, तो आपको सीधे यह मानने के बजाय कि `systemctl restart nginx` सभी उदाहरणों को कवर करता है, वास्तविक लॉन्च लक्ष्य और प्रक्रिया पथ की जांच करनी चाहिए। ### 4.6 स्वीकार करें और वास्तविक बाहरी प्रवेश द्वार से व्यवसाय प्रतिगमन करें इसे कम से कम निष्पादित करने की अनुशंसा की जाती है: - क्या सामान्य HTTPS, पुनः लिखित मार्ग, स्थैतिक संसाधन और `alias` मैपिंग पृष्ठ सही हैं। - क्या नियमित `map` वितरण, वेरिएबल root पथ, एक्सेस लॉग पथ, SNI/सर्टिफिकेट रूटिंग और Stream प्रॉक्सी सही हैं। - क्या सामान्य अपलोड, खंडित अपलोड, API अनुरोध और HTTP/3 (सक्षम होने पर) के लिए अपस्ट्रीम वॉल्यूम सीमाएं अभी भी अपेक्षा के अनुरूप हैं। - mTLS: वैध प्रमाणपत्र अनुरोध सफल होने चाहिए; गुम, समाप्त हो चुके, या अनधिकृत प्रमाणपत्रों को अभी भी अस्वीकार कर दिया जाना चाहिए, और TLS पुनः आरंभ/पुनः कनेक्शन करने से गलती से अनुमतियाँ नहीं बदलनी चाहिए। - क्या SSI पेज और एसिंक्रोनस फ़ाइल एक्सेस सामान्य है; त्रुटि लॉग मेमोरी संदर्भों या बार-बार Worker क्रैश के लिए कोई असामान्य अनुरोध नहीं दिखाता है। - ट्रैफ़िक स्विच के बाद, पुराने संस्करण की प्रक्रिया और पुरानी छवि प्रतिकृति को बाहर निकल जाना चाहिए। परीक्षण स्वयं या अधिकृत वातावरण में आयोजित किया जाना चाहिए। सामान्य अनुरोध धुआं परीक्षण अकेले यह साबित नहीं कर सकता कि मेमोरी भेद्यता को ठीक कर दिया गया है; अंततः, आपूर्तिकर्ता के निश्चित संस्करण, स्रोत कोड पैच और रनटाइम परीक्षण को संयुक्त रूप से स्वीकृति के लिए स्वीकार किया जाना चाहिए। ## 5. जब तत्काल उन्नयन संभव न हो तो शमन उपाय यह अनुभाग जोखिम कम करने का विकल्प है, पैच प्रतिस्थापन नहीं। सभी अस्थायी कॉन्फ़िगरेशन परिवर्तनों का बैकअप लिया जाना चाहिए, `nginx -t` निष्पादित किया जाना चाहिए, बैचों में जारी किया जाना चाहिए, और यदि आवश्यक हो तो तुरंत वापस लाया जाना चाहिए। [S3](https://keendigit.com/hi/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/hi/insights/nginx-remediation-guide#source-4) ### 5.1 बाहरी एक्सपोज़र के आधार पर ट्रैफ़िक प्राथमिकता को नियंत्रित करें उन सेवाओं की आक्रमण सतह को कम करने को प्राथमिकता दें जिन्हें समय पर अपग्रेड नहीं किया जा सकता है: प्रबंधन सतह और आंतरिक API पर विश्वसनीय स्रोत पहुंच नियंत्रण, अपस्ट्रीम नेटवर्क अलगाव या अल्पकालिक ऑफ़लाइन जोड़ें; उच्च जोखिम वाले प्रवेश द्वारों में कनेक्शन जोड़ें, निकाय और दर सीमा का अनुरोध करें; सुनिश्चित करें कि स्रोत प्रमाणीकरण अनुरोध प्रसंस्करण श्रृंखला से पहले प्रविष्टि-संबंधित NGINX पर होता है। यह ध्यान दिया जाना चाहिए कि अधिकांश कमजोरियाँ स्वयं डेटा प्लेन के अंदर NGINX में स्थित हैं, पारंपरिक WAF नियम कस्टम कॉन्फ़िगरेशन ट्रिगर स्थितियों को सटीक रूप से निर्धारित नहीं कर सकते हैं। ### 5.2 `alias` / `rewrite`: पुनर्लेखन के बाद `$request_filename` का मूल्यांकन करने से बचें इसे जाँचने और समायोजित करने की अनुशंसा की जाती है: - `rewrite` को निष्पादित न करने का प्रयास करें जो `alias` का उपयोग करके `location` के साथ ही URI को बदल देगा। - जब URI को दोबारा लिखा गया हो लेकिन सही स्थिति का मिलान अभी तक पूरा नहीं हुआ हो तो `$request_filename` का उपयोग करने से बचें। - `return`, `set`, `if`, `add_header`, एक्सेस लॉग प्रारूप में अप्रत्यक्ष चर संदर्भों की जांच करें और फ़ाइलें शामिल करें। - जब व्यवसाय अनुमति देता है तो स्पष्ट `root`/`try_files`/स्वतंत्र `location` का उपयोग करें, लेकिन केवल `alias` को `root` में बदलें। यह फ़ाइल पथ शब्दार्थ को भी बदल सकता है, जिसे एक-एक करके सत्यापित किया जाना चाहिए। मौजूदा कॉन्फ़िगरेशन को अधिलेखित करने के लिए इंटरनेट पर सामान्य "सुरक्षित पुनर्लेखन टेम्पलेट" को सीधे कॉपी न करें। अलग-अलग `location` उपसर्गों और पुनर्लेखन लक्ष्यों के परिणामस्वरूप पूरी तरह से अलग-अलग अर्थों के साथ पथ स्प्लिसिंग होता है। [S5](https://keendigit.com/hi/insights/nginx-remediation-guide#source-5) ### 5.3 `map`/Regex: कैप्चर वेरिएबल स्टेट मिक्सिंग को कम करें समय के साथ अलग-अलग रेगेक्स मूल्यांकन पथों में `$1` जैसे अनाम कैप्चर को पुन: उपयोग करने की अनुमति देने के बजाय, नामित कैप्चर को प्राथमिकता देने और उनके प्रसार के दायरे को सीमित करने की अनुशंसा की जाती है। उदाहरण के लिए: ```nginx # 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整 map $host $tenant_root { default /srv/www/default; ~^(?[a-z0-9-]+)\.example\.net$ /srv/www/$tenant; } ``` यह स्निपेट केवल परिवर्तनीय स्वामित्व की आसान-से-ऑडिट संरचना को प्रदर्शित करता है; इसका मतलब यह नहीं है कि यह सभी CVE-2026-93479 ट्रिगर पथों को स्वतंत्र रूप से समाप्त करने में सिद्ध हुआ है। विशेष रूप से, समीक्षा करें कि क्या कैप्चर वेरिएबल्स को अन्य `root` या `log_format` द्वारा समय से पहले संदर्भित किया गया है, और क्या `volatile`, गतिशील पथ और अन्योन्याश्रित मूल्यांकन श्रृंखलाएं हैं। F5/CERT अल्पकालिक राहत के रूप में नामित कैप्चर का उपयोग करने और संबंधित नियमित मिलान कॉन्फ़िगरेशन तक उपयोग के दायरे को सीमित करने की अनुशंसा करता है। [S3](https://keendigit.com/hi/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/hi/insights/nginx-remediation-guide#source-6) ### 5.4 AIO + SSI: अनावश्यक फ़ंक्शन संयोजन बंद करें उन सर्वर/पथों के लिए जिन्हें SSI या एसिंक्रोनस फ़ाइल I/O की आवश्यकता नहीं है, उपयोग करें: ```nginx # 在适当的 http/server/location 上下文中配置 ssi off; aio off; ``` भेद्यता ट्रिगर करने वाली स्थितियों के परिप्रेक्ष्य से, दोनों में से एक को बंद करना आमतौर पर वर्णित विशिष्ट श्रृंखला को हटाने के लिए पर्याप्त है; एक ही समय में बंद करना केवल उन परिदृश्यों पर लागू होता है जहां व्यवसाय इस क्षमता पर निर्भर नहीं होता है। `include virtual`, उपअनुरोध, कैश और थ्रेड पूल व्यवहार की जाँच करें; जब रिवर्स प्रॉक्सी लोड अधिक हो, तो AIO को बंद करने से विलंबता और I/O प्रदर्शन बदल सकता है। [S7](https://keendigit.com/hi/insights/nginx-remediation-guide#source-7) ### 5.5 HTTP/3 बॉडी इंजेक्शन का अनुरोध करें: यदि आवश्यक हो तो प्रवेश द्वार को अस्थायी रूप से बंद करें HTTP/3 से जुड़े `quic` श्रोता को अक्षम करें, `Alt-Svc` प्रतिक्रिया हेडर को रद्द करें जो HTTP/3 की घोषणा करता है, और जांचें कि क्या एज लेयर/लोड बैलेंसर अभी भी QUIC अनुरोधों को सीधे बिना मरम्मत वाले NGINX पर भेजता है: ```nginx # 示意：保留 HTTPS/TCP；暂时移除此前的 QUIC/UDP listen server { listen 443 ssl; # 保留 HTTPS/TCP 入口 # 对支持新版语法的构建，可在此使用 http2 on; # 删除原有的 listen 443 quic reuseport; # 删除原有的 add_header Alt-Svc ...;（仅限宣传 h3 的那项） # 其余证书、server_name、location 等配置保持不变 } ``` उपरोक्त केवल परिवर्तन अंतर का विवरण है, संपूर्ण सर्वर कॉन्फ़िगरेशन नहीं जिसे व्यक्तिगत रूप से सक्षम किया जा सकता है। HTTP/2 का सेटिंग सिंटैक्स NGINX संस्करण से संबंधित है; यदि आपको HTTP/2 को बनाए रखने की आवश्यकता है, तो आपको `http2 on;` या संबंधित संस्करण के अनुसार मौजूदा वैध सिंटैक्स का उपयोग करना चाहिए, और `nginx -t` से जांचना चाहिए। संपूर्ण अनुभाग को इस अनुभाग से बदलने के बजाय, परिनियोजन से पहले मौजूदा सर्वर कॉन्फ़िगरेशन के साथ विलय किया जाना चाहिए। UDP 443 फ़ायरवॉल, HTTP/3 समाप्ति स्थान और CDN/फ्रंट प्रॉक्सी के क्लाइंट फ़ॉलबैक पथ की भी जाँच करता है। एक अन्य प्रकार का अल्पकालिक शमन प्रभावित प्रॉक्सी पथ पर `proxy_request_buffering off;` का उपयोग करना है, लेकिन इससे अपस्ट्रीम अनुरोध बॉडी स्ट्रीमिंग, विफलता पुनः प्रयास और कुछ अपलोड वर्कफ़्लो का व्यवहार बदल जाएगा; केवल पर्याप्त परीक्षण और पुष्टि के बाद ही उपयोग किया जाना चाहिए कि निर्देश प्रभावित HTTP/3 प्रॉक्सी पथ पर हिट करता है। [S8](https://keendigit.com/hi/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/hi/insights/nginx-remediation-guide#source-18) ### 5.6 TLS सत्र टिकट: प्राथमिकता सुरक्षा mTLS प्रमाणीकरण सीमा यदि अपग्रेड करना संभव नहीं है और उदाहरण साझा सत्र कैश + स्वचालित टिकट कुंजी रोटेशन पर निर्भर करता है, तो मूल्यांकन करें: ```nginx # 在 nginx http/server 适当作用域进行配置 ssl_session_tickets off; ``` यह TLS सत्र टिकट तंत्र को बंद कर सकता है, जिससे इस भेद्यता में वर्णित टिकट जालसाजी पथ को हटाया जा सकता है; हालाँकि, यह सत्र पुनः आरंभ करने के प्रदर्शन को प्रभावित कर सकता है। आप "कमजोरियों से बचने" के लिए mTLS क्लाइंट प्रमाणपत्र सत्यापन को बंद नहीं कर सकते, क्योंकि यह सीधे मूल प्रमाणीकरण सीमा को हटा देगा। [S9](https://keendigit.com/hi/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/hi/insights/nginx-remediation-guide#source-12) स्पष्ट `ssl_session_ticket_key` फ़ाइलें और सुरक्षित रोटेशन का उपयोग पेशेवर TLS प्रबंधन प्रक्रियाओं द्वारा स्वचालित रूप से उत्पन्न स्थितियों से बचने के लिए भी किया जा सकता है, लेकिन कुंजी हिरासत, पूर्ण नोड वितरण, रोटेशन और पुराने टिकट जीवनचक्र सभी को सावधानीपूर्वक ऑडिट करने की आवश्यकता है। अस्थायी आपात स्थितियों के लिए सामान्य वेब कॉन्फ़िगरेशन या स्क्रिप्ट में दीर्घकालिक पुन: प्रयोज्य कुंजी को हार्डकोड करने की अनुशंसा नहीं की जाती है। mTLS का उपयोग करने वाली महत्वपूर्ण सेवाओं को TLS सत्र फिर से शुरू करने के व्यवहार और वैध ग्राहक प्रमाणपत्र के बिना अनुरोधों की अस्वीकृति के लिए अतिरिक्त रूप से निगरानी की जानी चाहिए। [S12](https://keendigit.com/hi/insights/nginx-remediation-guide#source-12) ### 5.7 ऑपरेटिंग सिस्टम और सीमा सुरक्षा की भूमिका ```bash # Linux：常见值 2 表示进程地址空间随机化处于完整启用状态 sysctl kernel.randomize_va_space ``` ASLR, गैर-root कार्यकर्ता, केवल पढ़ने योग्य कंटेनर फ़ाइल सिस्टम, न्यूनतम फ़ाइल अनुमतियाँ और नेटवर्क अलगाव संभावित RCE के प्रभाव को कम कर सकते हैं। ASLR हीप ओवरफ्लो या UAF को ठीक नहीं करता है और यह गारंटी नहीं दे सकता है कि श्रमिक दुर्घटनाग्रस्त नहीं होंगे। WAF, दर सीमाएं और अनुरोध बॉडी आकार सीमाएं TLS टिकट कुंजी सिंक्रनाइज़ेशन को ठीक नहीं करती हैं। [S4](https://keendigit.com/hi/insights/nginx-remediation-guide#source-4) ### 5.8 आम गलतफहमी: ये ऑपरेशन मरम्मत को पूरा करने के लिए पर्याप्त नहीं हैं | सामान्य परिचालन | यह अपर्याप्त क्यों है? | | -------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ | | "nginx -v अपेक्षाकृत नया दिखता है" | यह जिस शाखा से संबंधित है, रिलीज़ संस्करण के पूर्ण बैकपोर्टेड पैकेज संस्करण और ऑनलाइन प्रक्रिया की जाँच नहीं की जाती है। | | "केवल एक इंट्रानेट को अपग्रेड किया गया था" | पुराने Worker/पुराने कंटेनर/पुराने CDN मूल उदाहरण को अभी भी अनुरोध प्राप्त होते हैं | | "साइट PHP/डायनामिक टैग का उपयोग नहीं करती" | दोष NGINX कोर पथ या प्रोटोकॉल पार्सिंग में होता है और PHP निष्पादन पर निर्भर नहीं होता है। | | "WAF/क्लाउडफ्लेयर खोलना पर्याप्त है" | WAF को सभी NGINX कॉन्फ़िगरेशन-निर्भर मेमोरी दोषों या TLS पुनरारंभ दोषों को ब्लॉक करने के लिए सिद्ध नहीं किया जा सकता है | | "ASLR पहले ही खोला जा चुका है" | बस कठिनाई शमन का लाभ उठा रहे हैं; अनुरोध इंजेक्शन के साथ DoS अभी भी संभव है | | "HTTP/3 सार्वजनिक नेटवर्क के संपर्क में नहीं है, इसलिए अपग्रेड करने की कोई आवश्यकता नहीं है" | अन्य चार सीवीई को अभी भी स्वतंत्र मूल्यांकन की आवश्यकता है; और छिपे हुए मूल से सीधा संबंध हो सकता है | | "जुलाई की `map` भेद्यता ठीक कर दी गई है" | अक्टूबर CVE-2026-93479 में बाद के स्क्रिप्ट मूल्यांकन प्रतिगमन मुद्दे शामिल हैं | | "कैशिंग अक्षम करने से सभी समस्याएं हल हो जाती हैं" | केवल कुछ TLS कैश या AIO परिदृश्यों को प्रभावित करता है, और उपनाम, स्क्रिप्ट, HTTP/3 को कवर नहीं करता है | ## 6. आधिकारिक पैच कार्यान्वयन विचार और समीक्षा बिंदु यह अनुभाग अक्टूबर 2026 अपस्ट्रीम NGINX फ़िक्सेस का अनुसरण करता है। स्निपेट्स पैच समीक्षा के लिए प्रतिनिधि परिवर्तनों को दर्शाते हैं; वे पूर्ण नहीं हैं, स्वतंत्र रूप से संकलित करने योग्य सुधार हैं। कस्टम बिल्ड के लिए, पूर्ण प्रतिबद्धताओं, आसपास के कोड और परीक्षणों की समीक्षा करें और पूर्ण समर्थित रिलीज़ को प्राथमिकता दें। [S5](https://keendigit.com/hi/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/hi/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/hi/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/hi/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/hi/insights/nginx-remediation-guide#source-9) ### 6.1 CVE-2026-15176: URI को `alias` पथ मैपिंग अस्वीकृति शर्तों को शामिल करने के लिए फिर से लिखा गया है अपस्ट्रीम प्रतिबद्धता ने `ngx_http_map_uri_to_path()` को `src/http/ngx_http_core_module.c` में संशोधित किया: ```diff - if (alias && !r->valid_location) { + if (alias && (!r->valid_location || r->uri_changed)) { ``` समीक्षा फोकस: जब URI बदल गया है तो फ़ाइल सिस्टम पथ की गणना जारी नहीं रखी जा सकती है, लेकिन `alias` के संबंधित स्थान शब्दार्थ अब विश्वसनीय नहीं हैं। यह पूर्व-राज्य बाधा में वृद्धि है। यह जांचना आसान नहीं है कि अनुरोध URI में अवैध अक्षर हैं या नहीं। [S5](https://keendigit.com/hi/insights/nginx-remediation-guide#source-5) ### 6.2 CVE-2026-93479: आउटपुट डेटा लंबाई और आरक्षित लंबाई के बीच सही अंतर करें अपस्ट्रीम कमिट एक ही समय में `src/http/ngx_http_script.c` और `src/stream/ngx_stream_script.c` को अपडेट करता है। मूल इरादे को संक्षेप में इस प्रकार प्रस्तुत किया जा सकता है: ```diff - n = len; + n = 0; /* ...计算实际脚本输出长度... */ - value->len = n; - value->data = ngx_pnalloc(pool, n); + value->len = n + len; + value->data = ngx_pnalloc(pool, n + len); ``` यहां, `pool` एक उदाहरणात्मक पैरामीटर नाम है: वास्तविक HTTP और Stream आवंटन अभिव्यक्ति भिन्न हैं। परिवर्तन पहले स्क्रिप्ट आउटपुट लंबाई की गणना करता है, फिर अंतिम आवंटन में आरक्षित लंबाई जोड़ता है ताकि आउटपुट आरक्षित स्थान को अधिलेखित न करे। [S6](https://keendigit.com/hi/insights/nginx-remediation-guide#source-6) ऑडिटिंग और बैकपोर्टिंग करते समय, HTTP/Stream के संबंधित मूल्यांकनकर्ता को भी कवर किया जाना चाहिए; केवल `map` की कॉन्फ़िगरेशन सिंटैक्स फ़ाइल की जाँच करने से यह साबित नहीं हो सकता कि दोष ठीक कर दिया गया है। ### 6.3 CVE-2026-97205: 8-बिट एसिंक्रोनस ऑपरेशन गिनती के लिए सुरक्षा सीमा निर्धारित करें अपस्ट्रीम को `src/http/ngx_http_request.h` पर जोड़ा गया: ```c #define NGX_HTTP_MAX_BLOCKED 250 ``` और एसिंक्रोनस फ़ाइल रीडिंग, कैश वेटिंग, आउटपुट फ़िल्टरिंग और थ्रेड ऑपरेशन में समान प्रविष्टियाँ जोड़ें: ```c if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) { /* 使用同步路径，或者拒绝新的异步操作 */ } ``` समीक्षा फोकस: `r->main->blocked` को जोड़ने वाले सभी वास्तविक कोड पथों को कवर किया जाना चाहिए। आप केवल हेडर फ़ाइल में थ्रेशोल्ड स्थिरांक नहीं लिख सकते। बैकपोर्ट को सिंक्रोनस फ़ॉलबैक, एसिंक्रोनस कॉलबैक और त्रुटि रिटर्न के पूर्ण समन्वय की जांच करने की भी आवश्यकता है ताकि यह सुनिश्चित किया जा सके कि कार्यों की प्रत्यक्ष अस्वीकृति के कारण गतिरोध या संदर्भ रिसाव नहीं होगा। [S7](https://keendigit.com/hi/insights/nginx-remediation-guide#source-7) ### 6.4 CVE-2026-95101: अज्ञात फ़्रेमों के लिए `skip` स्थिति को अलग से बनाए रखें अपस्ट्रीम HTTP/3 पार्सर स्थिति संरचना में `skip` फ़ील्ड जोड़ता है और स्थिति पृथक्करण करता है: ```c if (st->type != NGX_HTTP_V3_FRAME_DATA && st->length > 0) { st->skip = st->length; st->length = 0; st->state = sw_skip; } /* ... */ rc = ngx_http_v3_parse_skip(b, &st->skip); ``` कुंजी "अज्ञात HTTP/3 फ़्रेम को अक्षम करना" नहीं है, बल्कि यह सुनिश्चित करना है कि एकाधिक रीड्स में, छोड़ी गई बाइट गिनती और DATA पेलोड लंबाई हमेशा स्वतंत्र राज्यों द्वारा प्रबंधित की जाती है। समीक्षाओं को अज्ञात फ़्रेम क्रॉस-बफ़र शार्डिंग और `client_max_body_size` की अंतिम स्थिरता पर ध्यान केंद्रित करना चाहिए। [S8](https://keendigit.com/hi/insights/nginx-remediation-guide#source-8) ### 6.5 CVE-2026-97629: संपूर्ण TLS कुंजी स्लॉट सरणी को सिंक्रनाइज़ करें अपस्ट्रीम परिवर्तन `src/event/ngx_event_openssl.c` पर स्थित हैं: ```diff ngx_memcpy(keys->elts, cache->ticket_keys, - 2 * sizeof(ngx_ssl_ticket_key_t)); + keys->nelts * sizeof(ngx_ssl_ticket_key_t)); ``` मूल छवि में तीन कुंजी स्लॉट थे, लेकिन केवल पहले दो की प्रतिलिपि बनाई गई थी। इसके बजाय, यह सुनिश्चित करने के लिए कि Worker का वोटिंग कुंजी सेट साझा मेमोरी के अनुरूप है, सरणी तत्वों की वास्तविक संख्या के आधार पर सिंक्रनाइज़ करें। समीक्षा करते समय, केवल एक बार `memcpy` लंबाई संशोधन की जाँच करने के बजाय, यह भी पुष्टि करें कि सरणी आवंटन, आरंभीकरण, साझा लॉक और रोटेशन तर्क सुसंगत हैं। [S9](https://keendigit.com/hi/insights/nginx-remediation-guide#source-9) ### 6.6 केवल बिखरे हुए पैच टुकड़े लगाने की अनुशंसा क्यों नहीं की जाती है? ये पांच संशोधन क्रमशः `src/http`, `src/stream`, `src/http/v3`, और `src/event` तक फैले हुए हैं, और पुराने संस्करणों में सुरक्षा बैकपोर्ट और अनौपचारिक एक्सटेंशन हो सकते हैं। बैकपोर्टिंग को निम्नलिखित चेक मैट्रिक्स बनाना चाहिए: | वस्तु की जाँच करें | क्या पुष्टि होनी चाहिए | | ------------------- | ---------------------------------------------------------------------------------------- | | पैच स्रोत | आधिकारिक प्रस्तुतिकरण, मिलान लक्ष्य संस्करण, पूर्ण पैच और हस्ताक्षर सत्यापन | | मूल पैच सेट | CVE-2026-42533, वितरण बैकपोर्ट इत्यादि जैसे ऐतिहासिक संशोधनों के साथ विरोध नहीं करता है। | | कोड पथ | HTTP + Stream स्क्रिप्ट, AIO/थ्रेड, HTTP/3, OpenSSL टिकट सभी शामिल हैं | | संगत संकलित | OpenSSL, PCRE, मॉड्यूल ABI, डायनेमिक मॉड्यूल और लिंक निर्भरताएँ सुसंगत हैं | | कार्यात्मक प्रतिगमन | `alias` पुनर्लेखन, गतिशील लॉग, SSI/AIO, HTTP/3 अपलोड, mTLS सत्र पुनः प्रारंभ | | रनटाइम | सभी Worker/Pods नए सत्यापित बिल्ड चलाते हैं, कोई पुरानी छवि नहीं रहती है | अपनी स्वयं की रिलीज़ बनाए रखने वाली टीमों के लिए, प्रत्येक सीवीई के लिए ऑडिटेबल पैच आईडी, पैकेज संस्करण, बिल्ड लॉग और रिग्रेशन रिपोर्ट रखने की अनुशंसा की जाती है; सामान्य संचालन और रखरखाव के लिए, सबसे सुरक्षित समाधान विक्रेता के संपूर्ण सुरक्षा अद्यतन स्थापित करना है। ## 7. ऐतिहासिक भेद्यता बैकट्रैकिंग, पुरानी शाखाएँ और अन्य उत्पाद ### 7.1 NGINX कोर भेद्यता मई से सितंबर 2026 तक एक साथ पुष्टि के योग्य है कई NGINX उदाहरण जो लंबे समय से अपडेट नहीं किए गए हैं वे न केवल अक्टूबर में नए मुद्दे से प्रभावित हैं। निकट भविष्य में प्रतिनिधि मरम्मत नोड निम्नलिखित हैं: [S1](https://keendigit.com/hi/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/hi/insights/nginx-remediation-guide#source-2) | सीवीई | पहला फिक्स रिलीज | ऑडिट की आवश्यकता वाले प्रमुख जोखिम और शर्तें | | -------------- | ------------------------------------------ | --------------------------------------------------------------------------------------------------------------------------------------------------- | | CVE-2026-42945 | Stable 1.30.1 / Mainline 1.31.0, 13 मई | `rewrite` अनाम रेगेक्स कैप्चर और रिप्लेसमेंट लॉजिक हीप ओवरफ्लो को ट्रिगर करता है, संभावित RCE; जंगली हमले के प्रयासों की सार्वजनिक रिपोर्टें हैं | | CVE-2026-9256 | Stable 1.30.2 / Mainline 1.31.1, 22 मई | `rewrite` में रेगेक्स कैप्चर और लंबाई अनुमान को ओवरलैप करने से अतिप्रवाह होता है | | CVE-2026-42055 | Stable 1.30.3 / Mainline 1.31.2, 17 जून | HTTP/2 अपस्ट्रीम या gRPC के लिए विशिष्ट कॉन्फ़िगरेशन, बड़े अनुरोध हेडर स्थिति बफर ओवरफ्लो को ट्रिगर करती है | | CVE-2026-42530 | Mainline 1.31.2, 17 जून | HTTP/3 उपयोग-पश्चात-मुक्त; आधिकारिक चिह्न प्रभावित रेंज `1.31.0–1.31.1` | | CVE-2026-42533 | Stable 1.30.4 / Mainline 1.31.3, 15 जुलाई | `map` + रेगेक्स कैप्चर वैरिएबल मूल्यांकन के कारण ढेर ओवरफ़्लो होता है, और बाद के पैच में अक्टूबर में CVE-2026-93479 के साथ प्रतिगमन सहसंबंध होता है | | CVE-2026-60005 | Stable 1.30.4 / Mainline 1.31.3, 15 जुलाई | `ngx_http_slice_module` मेमोरी सामग्री विशिष्ट चर और कैश अद्यतन स्थितियों के तहत लीक हो गई | | CVE-2026-56434 | Stable 1.30.4 / Mainline 1.31.3, 15 जुलाई | SSI UAF से संबंधित है; अक्टूबर की AIO गणना भेद्यता के समान root कारण नहीं है | | CVE-2026-90439 | Stable 1.30.5 / Mainline 1.31.6, 15 सितंबर | HTTP/3 + विशिष्ट OpenSSL संस्करण संयोजन का सीमित ढेर अतिप्रवाह, मुख्य रूप से क्रैश/सीमित मेमोरी भ्रष्टाचार के रूप में प्रकट होता है | 2026 में घोषित NGINX Core, HTTP/2, चारसेट और SMTP जैसी अन्य कमजोरियों की भी आधिकारिक सुरक्षा बुलेटिन के अनुसार जांच की जानी चाहिए; यह तालिका जानबूझकर उन विशिष्ट घटनाओं पर ध्यान केंद्रित करती है जो वर्तमान NGINX सार्वजनिक-सामना वाले रिवर्स प्रॉक्सी परिनियोजन के लिए सबसे अधिक प्रासंगिक हैं और जिनमें मेमोरी सुरक्षा या अनुरोध अखंडता निहितार्थ हैं। 2026 में सभी सीवीई नहीं हैं। सूची। [S1](https://keendigit.com/hi/insights/nginx-remediation-guide#source-1) #### CVE-2026-42945 पर विशेष ध्यान क्यों दें? सरकारी एजेंसियों के सुरक्षा बुलेटिन हैं जो मई में इस `rewrite` भेद्यता के लिए जंगली शोषण गतिविधियों और सार्वजनिक शोषण कोड की जानकारी रिकॉर्ड करते हैं। इसलिए, ऐसे उदाहरणों के लिए जिन्हें मई से वर्तमान तक लंबे समय तक पैच नहीं किया गया है और सार्वजनिक नेटवर्क पर खुले जटिल नियमित अभिव्यक्ति पुनर्लेखन हैं, मरम्मत को पूरा करने के अलावा, उस समय असामान्य Worker क्रैश, एक्सेस लॉग और संदिग्ध परिवर्तनों की अतिरिक्त समीक्षा की जानी चाहिए। [S23](https://keendigit.com/hi/insights/nginx-remediation-guide#source-23) "हमले का प्रयास हुआ" स्वचालित रूप से यह साबित नहीं होता है कि हमलावर ने प्रत्येक लक्ष्य पर विश्वसनीय रूप से आदेश निष्पादित किए हैं; जब घटना की प्रतिक्रिया शामिल होती है, तो समझौता संकेतकों और प्रक्रिया क्रैश की जांच विशेषाधिकार वृद्धि या दृढ़ता के सच्चे सबूत से अलग की जानी चाहिए। ### 7.2 पुराने संस्करणों और वितरण बैकपोर्ट के लिए उपचार NGINX विभिन्न शाखाओं के अपने स्वयं के समर्थन चक्र और अलग-अलग भेद्यता परिचय समय होते हैं। पाँच नए पैच बिना समीक्षा के सभी प्रारंभिक स्रोत पेड़ों पर लागू नहीं किए जा सकते। | दृश्य | अनुशंसित रणनीति | | ------------------------------------------------------------------------------------------ | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ | | रिलीज़ संस्करण ने पूर्ण सुरक्षा पैच की घोषणा की है | विक्रेता पैकेजों का उपयोग करें और संपूर्ण पैकेज संस्करणों का दस्तावेज़ीकरण करें; असंगत अपस्ट्रीम बेयर बायनेरिज़ से बदलने से बचें | | Debian 12 और अन्य प्रभावित रिलीज़ जो अभी तक इस बैच के सभी सीवीई द्वारा कवर नहीं किए गए हैं | जोखिम कार्य आदेश जमा करें, बाहरी जोखिम को सीमित करें, और आपूर्तिकर्ता/ELTS स्थिति की जांच करें; आवश्यक होने पर सत्यापन योग्य रखरखाव रिलीज़ श्रृंखला को स्थानांतरित करें या उसका उपयोग करें | | ऐतिहासिक शाखाएँ जिन्होंने अपस्ट्रीम समर्थन समाप्त कर दिया है | समर्थित संस्करणों में माइग्रेशन को प्राथमिकता दें; यदि अल्पकालिक बैकपोर्टिंग आवश्यक है, तो अनुरक्षक निर्भरता और पैच संगतता का मूल्यांकन करेंगे, और पूर्ण परीक्षण लिखेंगे। | | NGINX फोर्क (OpenResty, Tengine, अनुकूलित गेटवे) के साथ आता है | पहले यह निर्धारित करें कि संबंधित कोड पथ शामिल है या नहीं, और फिर फोर्क मेंटेनर के सुरक्षा कथन का उपयोग करें। यह सीधे तौर पर अपस्ट्रीम संस्करण के समकक्ष नहीं हो सकता। | | सुरक्षा पैच व्यावसायिक कार्यक्षमता में बदलाव लाते हैं | चरणबद्ध रोलआउट, संस्करणों के बीच ट्रैफ़िक स्विचिंग और कॉन्फ़िगरेशन अनुकूलन को अपनाना; सार्वजनिक नेटवर्क के अनफ़िक्स्ड संस्करण को अलगाव के बिना पुनर्स्थापित करना उचित नहीं है। | ### 7.3 njs, इनग्रेस और NGINX कोर के लिए अलग उपचार - njs: NGINX मुख्य प्रोग्राम के अलावा, आपको NGINX जावास्क्रिप्ट मॉड्यूल के संस्करण की भी जांच करनी होगी। `njs 1.0.2` अक्टूबर 2026 XML पार्सिंग मेमोरी थकावट और इकाई संदर्भ विशेषताओं के साथ XML सत्यापन असंगतता समस्या को ठीक करता है। `nginx-saml` का उपयोग करके XML हस्ताक्षर सत्यापन से जुड़ी तैनाती के लिए, आपको प्लग-इन परिदृश्यों के लिए आधिकारिक njs निर्देशों को आगे पढ़ना चाहिए। [S20](https://keendigit.com/hi/insights/nginx-remediation-guide#source-20) - F5 NGINX Plus / NGINX इनग्रेस कंट्रोलर: साथ ही, कंट्रोलर और गेटवे फैब्रिक प्रत्येक में अतिरिक्त सुरक्षा बुलेटिन, विभिन्न पैकेजिंग संस्करण और अद्वितीय नीति कमजोरियां हो सकती हैं। एक परत को अपग्रेड करने का मतलब स्वचालित रूप से दूसरी परत को अपडेट करना नहीं है। [S19](https://keendigit.com/hi/insights/nginx-remediation-guide#source-19) - Kubernetes समुदाय ingress-nginx: Kubernetes अधिकारियों ने पहले ही घोषणा की है कि नियंत्रक ने मार्च 2026 में रखरखाव बंद कर दिया है, और इसके गोदाम को F5 नियंत्रक के साथ भ्रमित नहीं किया जा सकता है। प्रभावित व्यवसायों को नए सुरक्षा संस्करण की प्रतीक्षा करने के बजाय सुचारू माइग्रेशन की योजना बनानी चाहिए और इनग्रेस एनोटेशन और Gateway API अर्थ संबंधी अंतरों को सत्यापित करना चाहिए। [S21](https://keendigit.com/hi/insights/nginx-remediation-guide#source-21) ## 8. स्वीकृति मानदंड और अनुवर्ती निरीक्षण यह अनुशंसा की जाती है कि निम्नलिखित सूची का उपयोग परिवर्तन कार्य आदेशों के लिए स्वीकृति शर्तों के रूप में किया जाए: | प्रोजेक्ट | योग्यता मानक | ऐसे साक्ष्य जिन्हें बरकरार रखा जा सकता है | | ------------------------------- | -------------------------------------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------- | | संपत्ति और पोर्टल कवरेज | सभी बाहरी और प्रत्यक्ष-जुड़े हुए उदाहरण जो CDN को बायपास कर सकते हैं, उनका आविष्कार किया गया है। | डोमेन नाम, एलबी, आईपी, पॉड/कंटेनर सूची | | पैकेज स्रोत और मरम्मत का दायरा | सभी लागू सीवीई को कवर करने के लिए पुष्टि किए गए संस्करणों का उपयोग करें | अपस्ट्रीम सुरक्षा सलाहकार, यूएसएन/डीएसए, पैकेज संस्करण, इमेज डाइजेस्ट | | पुरानी प्रक्रिया बाहर निकलती है | सभी पुराने master/worker/कंटेनरों को बदल दिया गया है | पीआईडी/प्रारंभ समय, रोलिंग परिनियोजन स्थिति, चल रही छवि | | कॉन्फ़िगरेशन ऑडिट | उच्च जोखिम वाले संयोजनों को समाप्त कर दिया गया है या पैच द्वारा कवर किया गया है, और विरासत संबंधों को सत्यापित किया गया है | `nginx -T` का संशोधित सारांश और ऑडिट रिकॉर्ड | | TLS/mTLS | विश्वसनीय प्रमाणपत्र पास; अमान्य या गुम प्रमाणपत्र अस्वीकार कर दिए जाते हैं; सत्र पुनः प्रारंभ प्रमाणीकरण को बायपास नहीं करता है | नकारात्मक/सकारात्मक प्राधिकरण परीक्षण, नियंत्रित TLS परीक्षण परिणाम | | HTTP/3 अनुरोध निकाय | पथ निश्चित सक्षम करें; अपस्ट्रीम अनुरोध बॉडी और थ्रॉटलिंग सही ढंग से व्यवहार करते हैं | HTTP/3, प्रॉक्सी अपलोड, वॉल्यूम सीमा प्रतिगमन परीक्षण | | SSI/AIO | फ़ंक्शन आवश्यकताओं को पूरा करता है, Worker में कोई असामान्य गर्भपात नहीं है | व्यवसाय प्रतिगमन, दुर्घटना और त्रुटि दर की निगरानी | | संचालन और रखरखाव की निगरानी | कोई स्पष्ट अपवाद नहीं 5xx, SIGSEGV, प्रक्रिया बार-बार बाहर निकलती है | परिवर्तन से पहले और बाद में सेवा संकेतक और लॉग | | रोलबैक रणनीति | यदि रोलबैक आवश्यक है, तो पहले एक्सपोज़र को सीमित करें और सुरक्षा सीमाओं को सुरक्षित रखें | परिवर्तन आदेश, आपातकालीन प्रवाह, और संगरोध योजनाएँ | | आगामी जीवन चक्र | सुरक्षा बुलेटिन सदस्यता, कंटेनर अद्यतन आवृत्ति और शाखा प्रवासन योजना निर्धारित करें | अपग्रेड लेजर, जिम्मेदार व्यक्ति और अगली ऑडिट तिथि | ### 8.1 आपको लॉग और रनिंग स्थिति में किस पर ध्यान देना चाहिए? लंबे समय से उजागर सर्वर पर असामान्यताओं का निवारण करें `worker process exited on signal` , `SIGSEGV` , अनुरोध विफलता स्पाइक्स, असामान्य स्रोत पहुंच एकत्रीकरण, अप्रत्याशित TLS सत्र पुनरारंभ / प्रमाणीकरण सफलता और असामान्य बैकएंड अनुरोध बॉडी व्यवहार। इन संकेतकों का उपयोग केवल जांच सुराग के रूप में किया जा सकता है और ये सीधे तौर पर यह साबित करने के लिए पर्याप्त सबूत नहीं हैं कि एक निश्चित सीवीई का शोषण किया गया है। ;प्रासंगिक लॉग की कमी यह साबित नहीं करती कि कोई हमला नहीं हुआ है। ### 8.2 अनुशंसित अंतिम जोखिम निष्कर्ष शब्दांकन उत्पादन परिवेश के लिए स्वीकृति रिपोर्ट में निम्नलिखित सटीक अभिव्यक्ति का उपयोग करना चाहिए: > NGINX बाहरी सेवा प्रवेश और सॉफ्टवेयर पैकेज स्रोत की पहचान की गई है। सभी लागू उदाहरणों को अपस्ट्रीम आधिकारिक सुरक्षा संस्करण में अपग्रेड कर दिया गया है, या रिलीज़ विक्रेता द्वारा पुष्टि की गई बैकपोर्ट पूरी हो गई है; पुराने Worker और पुराने कंटेनरों को बदल दिया गया है। उपनाम/पुनर्लेखन/मानचित्र, AIO/SSI, HTTP/3 अनुरोध निकाय और TLS सत्र टिकट/mTLS संबंधित कॉन्फ़िगरेशन का ऑडिट किया गया है और कार्यात्मक, प्रमाणीकरण और अनुरोध अखंडता प्रतिगमन परीक्षण पारित किया गया है। ऐसे उदाहरणों के लिए जिन्होंने अभी तक अपग्रेड पूरा नहीं किया है, अतिरिक्त रूप से एक्सपोज़र क्षेत्रों, मुआवजे के उपायों, जिम्मेदार व्यक्तियों और पूर्ण होने की समय सीमा को पंजीकृत करें। यदि Debian 12 या अन्य रिलीज़ के लिए पैच अभी भी अधूरा है, तो संपूर्ण स्वीकृति फॉर्म को "पूर्ण" मानना उचित नहीं है; अनसुलझा सीवीई, क्या संबंधित ट्रिगर कॉन्फ़िगरेशन है, अलगाव स्थिति और अंतिम अपग्रेड मार्ग स्पष्ट रूप से दर्ज किया जाना चाहिए। *** ## परिशिष्ट: उद्धृत स्रोत और लिंक विवरण: पाठ में `[Sx]` संख्याएँ समान रूप से इस अनुभाग से मेल खाती हैं। निम्नलिखित अपस्ट्रीम परियोजना सुरक्षा घोषणाओं, कोड प्रतिबद्धताओं, आपूर्तिकर्ता रिलीज घोषणाओं और राष्ट्रीय सुरक्षा एजेंसी की जानकारी को प्राथमिकता देता है। उद्धृत कमजोरियों की गंभीरता को प्रत्येक जारीकर्ता संगठन के रेटिंग मानदंडों के अनुसार वर्णित किया गया है; डेटा सत्यापन तिथि 27 अक्टूबर, 2026 है। ### S1 - NGINX Open Source आधिकारिक सुरक्षा बुलेटिन - इसमें अपस्ट्रीम प्रभावित संस्करण, फिक्स शाखाएं और पांच अक्टूबर सीवीई के आधिकारिक गंभीरता स्तर शामिल हैं, और 2026 तक ऐतिहासिक कमजोरियों को भी शामिल किया गया है। ### S2 - NGINX आधिकारिक संस्करण रिलीज़ रिकॉर्ड - - 2026-10-14 के 1.30.6 / 1.31.7, 2026-10-21 के 1.31.8 और मई से सितंबर तक महत्वपूर्ण सुरक्षा रिलीज मील के पत्थर की पुष्टि करें। ### S3 - सिंगापुर की साइबर सुरक्षा एजेंसी: F5 NGINX तीन महत्वपूर्ण कमजोरियाँ - CVSS v4.0 9.2 स्कोर, आवश्यक कॉन्फ़िगरेशन शर्तें, और CVE-2026-15176, CVE-2026-93479, और CVE-2026-97205 के लिए अंतरिम शमन अनुशंसाओं का विवरण। ### S4 - NHS इंग्लैंड: F5 NGINX उच्च जोखिम संबंधी सलाह - स्मृति सुरक्षा समस्याओं के DoS/संभावित RCE प्रभाव और ASLR को बंद या बायपास किए जाने जैसी बाधाओं का वर्णन करता है। ### S5 - आधिकारिक स्रोत प्रतिबद्धता: CVE-2026-15176 - `ngx_http_map_uri_to_path()` में `alias` और `r->uri_changed` की स्थिति जांच के अनुरूप है। ### S6 - आधिकारिक स्रोत प्रतिबद्धता: CVE-2026-93479 - HTTP/Stream स्क्रिप्ट लंबाई और आरक्षित बफर आवंटन तर्क के अनुरूप। ### S7 - आधिकारिक स्रोत प्रतिबद्ध: CVE-2026-97205 - `r->main->blocked` गणना सीमा `NGX_HTTP_MAX_BLOCKED 250` और अतुल्यकालिक पथ फ़ॉलबैक के अनुरूप है। ### S8 - आधिकारिक स्रोत प्रतिबद्ध: CVE-2026-95101 - HTTP/3 अज्ञात फ़्रेम शेष लंबाई और DATA अनुरोध बॉडी लंबाई के अनुरूप स्थिति पृथक्करण। ### S9 - आधिकारिक स्रोत प्रतिबद्ध: CVE-2026-97629 - सिंक्रनाइज़ेशन TLS सत्र टिकट रोटेशन के दौरान सभी प्रमुख स्लॉट से मेल खाता है। ### S10 - F5: CVE-2026-15176 विक्रेता की घोषणा - `alias`, `rewrite`, `$request_filename` और एक्सेस लॉग जैसे ट्रिगर कारकों की सूची बनाएं। ### S11 - F5: CVE-2026-93479 विक्रेता घोषणा - सूची मानचित्र रेगेक्स कैप्चर, root पथ, और लॉग चर मूल्यांकन स्थितियाँ। ### S12 - NGINX आधिकारिक TLS/SSL मॉड्यूल दस्तावेज़ीकरण - विवरण `ssl_session_cache`, `ssl_session_tickets`, `ssl_session_ticket_key` और क्लाइंट प्रमाणपत्र प्रमाणीकरण और अन्य निर्देश। ### S13 — सुरक्षा सलाह: Ubuntu USN-8955-1 (2026-10-26) - Ubuntu 22.04 / 24.04 / 26.04 / 26.10. का संपूर्ण सॉफ़्टवेयर पैकेज निश्चित संस्करण और वितरण दायरा प्रदान करें ### S14 — सुरक्षा सलाह: Debian DSA-6575-1 (2026-10-21) - Debian 13 / trixie के लिए सुरक्षा फिक्स पैकेज `1.26.3-3+deb13u10` की पुष्टि करें, और CVE-2026-93479 के लिए बैकपोर्ट एसोसिएशन रिकॉर्ड करें। ### S15 — भेद्यता ट्रैकिंग: Debian Security Tracker: CVE-2026-15176 - Debian 12 / bookworm और Debian 13 / trixie की वितरण फिक्स स्थिति को सत्यापित करने के लिए उपयोग किया जाता है। यह स्थिति भविष्य के सुरक्षा अद्यतनों के साथ बदल सकती है। ### S16 — भेद्यता ट्रैकिंग: Debian Security Tracker: CVE-2026-95101 - विभिन्न Debian शाखाओं पर HTTP/3 भेद्यता की सुरक्षा स्थिति की पूरक पुष्टि। ### S17 — सुरक्षा सलाह: Red Hat: CVE-2026-93479 - अक्टूबर प्रतिगमन भेद्यता और जुलाई CVE-2026-42533 के समाधान के बीच सहसंबंध की पूरक समझ। ### S18 - NGINX आधिकारिक रिवर्स प्रॉक्सी मॉड्यूल दस्तावेज़ - - `proxy_request_buffering`, `client_max_body_size`, `alias`, `aio`, आदि जैसे कॉन्फ़िगरेशन के शब्दार्थ और डिफ़ॉल्ट मानों को क्वेरी करें। ### S19 - NGINX Plus आधिकारिक रिलीज़ नोट्स - प्लस CR/LTS शाखाओं, संस्करणों, पैच और अपग्रेड संगतता अनुस्मारक की सूची बनाएं। ### S20 - NGINX जावास्क्रिप्ट / njs आधिकारिक सुरक्षा बुलेटिन - - इसमें अक्टूबर 2026 njs 1.0.2 और संबंधित XML सत्यापन, मेमोरी थकावट की समस्याएं शामिल हैं। ### S21 - Kubernetes: समुदाय ingress-nginx आधिकारिक सेवानिवृत्ति निर्देश - - ध्यान दें कि प्रोजेक्ट ने मार्च 2026 में नई रिलीज़ और सुरक्षा सुधार रोक दिए, और अनुरक्षित नियंत्रक या Gateway API को माइग्रेट करने की अनुशंसा की गई है। ### S22 - NGINX आधिकारिक सेवा नियंत्रण और ऑनलाइन बाइनरी अपग्रेड निर्देश - प्रक्रिया स्विचिंग स्वीकृति के लिए कॉन्फ़िगरेशन पुनः लोड, पुनरारंभ और ऑनलाइन निष्पादन योग्य फ़ाइल अपग्रेड विधियों में अंतर करें। ### S23 - सरकारी सुरक्षा सूचना: मई 2026 NGINX भेद्यता को फिर से लिखें - - CVE-2026-42945 के लिए ऐतिहासिक जोखिम पृष्ठभूमि और सुरक्षा अद्यतन सुझाव प्रदान करें; जंगली शोषण से संबंधित निर्णय उस समय एजेंसी की घोषणा और आगे की घटना के साक्ष्य पर आधारित होने चाहिए। ### S24 - F5: CVE-2026-95101 और CVE-2026-97629 विक्रेता घोषणाएँ - - क्रमशः HTTP/3 अनुरोध बॉडी इंजेक्शन और स्वचालित TLS टिकट कुंजी रोटेशन के जोखिमों को कवर करता है। ### S25 - F5: CVE-2026-97205 विक्रेता की घोषणा - विवरण SSI/AIO ट्रिगर स्थितियां और संभावित मेमोरी भ्रष्टाचार जोखिम। [NGINX सुरक्षा अद्यतन: कॉन्फ़िगरेशन जाँच, उन्नयन और सत्यापन](https://keendigit.com/hi/news/nginx-security-update) ## सुरक्षा रखरखाव परामर्श अनिश्चित हैं कि प्रमाणपत्र विश्वास परिवर्तन आपके सिस्टम को कैसे प्रभावित करते हैं? हम प्रभावित ग्राहकों का आकलन करने और सुरक्षा अपडेट की योजना बनाने में मदद कर सकते हैं। [सुरक्षा अद्यतन पर चर्चा करें]() [मूल पृष्ठ]() · [सामग्री सूचकांक]() KeenDigit LLC · व्योमिंग फाइलिंग आईडी: 2026-002106155 [व्योमिंग राज्य सचिव से सत्यापित करें]() © 2026 KeenDigit LLC · शेरिडन, व्योमिंग, यूएसए · सर्वाधिकार सुरक्षित.