---
title: "NGINX कमजोरीहरू: कारणहरू, समाधानहरू र उत्पादन प्रमाणिकरण"
description: "पाँच अक्टोबर 2026 NGINX कमजोरीहरू, तिनीहरूको कन्फिगरेसन आवश्यकताहरू, शाखा-विशेष समाधानहरू, वितरण ब्याकपोर्टहरू र उत्पादन प्रमाणिकरणको समीक्षा गर्नुहोस्।"
language: "ne"
url: "https://keendigit.com/ne/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 स्व-कम्पाइल गर्ने र तेस्रो-पक्ष मोड्युलहरू कायम गर्ने इन्जिनियरहरू।

यो लेखले अक्टोबर 14, 2026 मा खुलासा र गहन रूपमा फिक्स गरिएको पाँच NGINX कोर कमजोरीहरूमा केन्द्रित छ, र मे देखि सेप्टेम्बर 2026 सम्मको प्रतिनिधि मेमोरी सुरक्षा र अनुरोध अखण्डता कमजोरीहरूलाई पनि फर्काउँछ। सामग्रीले ट्रिगर अवस्थाहरू, कोड-स्तर प्रभाव, मिडिया-प्रवाह कारणहरू, सर्टमिडिया रिसेप्शन कारणहरू समावेश गर्दछ। उपायहरू, आधिकारिक प्याच कार्यान्वयन, पुराना शाखाहरूमा ब्याकपोर्टहरू र उत्पादन प्रमाणिकरण। सन्दर्भहरू जस्तै [S1](https://keendigit.com/ne/insights/nginx-remediation-guide#source-1) स्रोत परिशिष्टमा लिङ्क। उदाहरण कन्फिगरेसनहरू केवल तैनाती र लेखा परीक्षण विचारहरू चित्रण गर्न प्रयोग गरिन्छ, र कार्यान्वयन गर्नु अघि वास्तविक संस्करण, कन्फिगरेसन विरासत, निर्भरता, र व्यापार क्षमताको आधारमा प्रमाणित गरिनु पर्छ।

## TL; DR: प्राथमिकता कार्यहरू

1. सुरक्षा अपग्रेडलाई प्राथमिकता दिनुहोस्। को लागी nginx.org खुला स्रोत प्याकेजहरू, अपडेट गर्नुहोस् Stable 1.30 कम्तिमा शाखा 1.30.6 र Mainline 1.31 कम्तिमा शाखा 1.31.7. प्रमाणीकरण मितिमा, 1.31.8 नवीनतम छ Mainline रिलीज। यी अलग शाखा आधार रेखाहरू हुन्; शाखाहरूमा तिनीहरूको संख्या तुलना नगर्नुहोस्। [S1](https://keendigit.com/ne/insights/nginx-remediation-guide#source-1) [S2](https://keendigit.com/ne/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` अझै पनि प्रभावित भनी चिन्ह लगाइएको छ। प्रत्येक CVE जाँच गर्नुहोस्; Debian 13 सल्लाहकारले Debian 12 निश्चित छ भनेर स्थापित गर्दैन। [S13](https://keendigit.com/ne/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/ne/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/ne/insights/nginx-remediation-guide#source-15)
3. Audit five configuration combinations: `alias + rewrite + $request_filename`, `map` + regex + variable evaluation, `aio + ssi + include virtual`, HTTP/3 with `proxy_request_buffering on`, and `ssl_session_cache shared:...` with automatic TLS Session Ticket key परिक्रमा। निर्देशनको उपस्थितिले मात्र शोषण स्थापित गर्दैन; अनुरोध मार्ग र कन्फिगरेसन दायरा मूल्याङ्कन गर्नुहोस्। [S1](https://keendigit.com/ne/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/ne/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/ne/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/ne/insights/nginx-remediation-guide#source-3) [S4](https://keendigit.com/ne/insights/nginx-remediation-guide#source-4) [S8](https://keendigit.com/ne/insights/nginx-remediation-guide#source-8) [S12](https://keendigit.com/ne/insights/nginx-remediation-guide#source-12)

## 1. जोखिम अवलोकन र जोखिम निर्णय

NGINX ले 1.30.6 (Stable) र 1.31.7 (Mainline) अक्टोबर 14, 2026 मा जारी गर्‍यो, पाँच सुरक्षा समस्याहरू समाधान गर्दै। तीनमा हिप ओभरफ्लो वा प्रयोग-पश्चात-मुक्त र F5 CVSS v4.0 9.2 / क्रिटिकल स्कोरहरू समावेश छन्। अन्य दुईले HTTP/3 अनुरोध अखण्डता र TLS ग्राहक प्रमाणपत्र प्रमाणीकरणलाई असर गर्छ। [S1](https://keendigit.com/ne/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/ne/insights/nginx-remediation-guide#source-2)[S3](https://keendigit.com/ne/insights/nginx-remediation-guide#source-3)

मूल्याङ्कन प्रणालीहरू छुट्याउन: nginx.org सबै पाँचवटा मुद्दाहरूलाई `medium` को रूपमा सूचीबद्ध गर्दछ, जबकि F5 CVSS v4.0 र केही राष्ट्रिय सुरक्षा एजेन्सीहरूले तीनवटा मेमोरी मुद्दाहरूलाई गम्भीर रूपमा वर्गीकृत गर्छन्। यसको मतलब यो होइन कि सबै पाँचले बिना शर्त रिमोट कोड कार्यान्वयनलाई अनुमति दिन्छ। कन्फिगरेसन, ट्राफिक पहुँच योग्यता र आक्रमणकारीको नियन्त्रण बाहिर सर्तहरू। मेमोरी भ्रष्टाचार र विश्वसनीय RCE प्रमाणका विभिन्न स्तरहरू हुन्। [S1](https://keendigit.com/ne/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/ne/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/ne/insights/nginx-remediation-guide#source-4)

| CVE            | प्राविधिक समस्याहरू र विशिष्ट ट्रिगर अवस्थाहरू                                                    | कोर प्रभाव                                                                                                            | मूल्याङ्कन र निपटान                                                                          |
| -------------- | ------------------------------------------------------------------------------------------------- | --------------------------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------- |
| CVE-2026-15176 | `alias` पथ म्यापिङ + `rewrite` परिवर्तन URI + मूल्याङ्कन `$request_filename`                      | हिप बफर ओभरफ्लो, Worker दुर्घटना; केहि सर्तहरूमा सम्भावित RCE                                                         | F5 CVSS v4.0 9.2; समस्या निवारणलाई प्राथमिकता दिनुहोस्                                       |
| CVE-2026-93479 | HTTP/Stream लिपि मूल्याङ्कन, विशेष गरी `map` regex क्याप्चर र 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 बाइटहरू गलत रूपमा इन्जेक्सन गर्दै, सम्भवतः अनुरोधको शरीरको आकार सीमालाई बाइपास गर्दै | यो जोखिमले अनुरोधको अखण्डतालाई असर गर्छ। यो आफैले रिमोट कोड कार्यान्वयन (RCE) प्रदान गर्दैन। |
| CVE-2026-97629 | साझा TLS सत्र क्यास, स्वचालित कुञ्जी रोटेशन र Worker कुञ्जी मिररिङ                                | सत्र टिकट जाली; प्रभावित mTLS सेवाको लागि ग्राहक प्रमाणपत्र प्रमाणीकरण बाइपास हुन सक्छ                                | प्रमाणपत्र प्रमाणीकरण प्रकार API को व्यापार प्रभावमा विशेष ध्यान दिनु आवश्यक छ।              |

माथिको CVSS स्कोर F5 द्वारा v4.0 प्रयोग गरेर दिइएको छ; समान जोखिमले CVSS 3.1, nginx.org आफ्नै ग्रेड र वितरण गम्भीरता मूल्याङ्कनमा फरक गम्भीरता देखाउन सक्छ। [S1](https://keendigit.com/ne/insights/nginx-remediation-guide#source-1)[S3](https://keendigit.com/ne/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/ne/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, विशेष गरी अनुरोधको मुख्य भाग ब्याकइन्डमा प्रोक्सी गरिएको छ              | P0/P1: व्यापारिक महत्व अनुसार मिलाउनुहोस्                             |
| SSI डायनामिक पृष्ठ वा एसिन्क्रोनस फाइल I/O                                                     | CVE-2026-97205                                                                          | P1: संयोजन अवस्थाहरू पुष्टि गर्नुहोस् र सकेसम्म चाँडो मर्मत गर्नुहोस् |
| केवल स्थिर पृष्ठहरू + साधारण HTTP/1.1/2 रिभर्स प्रोक्सी                                        | कन्फिगरेसन र संस्करण अझै पनि अडिट गर्न आवश्यक छ, तर केही CVE सर्तहरू हराइरहेको हुन सक्छ | P1: आपतकालीन सुरक्षा अपग्रेड विन्डोमा समावेश                          |
| सेवानिवृत्त Kubernetes समुदाय ingress-nginx प्रयोग गर्नुहोस्                                   | परियोजनाले सुरक्षा मर्मत रोक्छ, र जोखिमहरू यी पाँच CVEहरूमा सीमित छैनन्                 | एक व्यक्तिगत नियन्त्रक माइग्रेसन योजना बनाउनुहोस्                     |

P0/P1 सार्वजनिक नेटवर्क एक्सपोजर र प्रमाणीकरण संवेदनशीलताको लागि यस लेखमा दिइएको सञ्चालन र मर्मत निपटान सुझावहरू हो। यो आधिकारिक CVSS वर्गीकरण होइन, न त यसले उद्यमको आन्तरिक सम्पत्ति र जोखिम मूल्याङ्कन परिवर्तन गर्नु पर्छ।

### 1.2 प्रभाव सीमा र आक्रमण अनुमतिहरू

यस ब्याचमा मुख्य कमजोरीहरू मुख्य रूपमा NGINX डाटा प्लेनमा अवस्थित छन्: आक्रमण प्रविष्टि बिन्दु ग्राहक जडान र अनुरोध हो, र वास्तविक प्रभाव सामान्यतया Worker प्रक्रियामा हुन्छ। यदि मेमोरी भ्रष्टाचारको लागि शोषणयोग्य सर्तहरू पूरा भएमा, कोड कार्यान्वयन अनुमति सामान्यतया चलिरहेको प्रयोगकर्ता, कन्टेनर अवरोधहरू, लिनक्स क्षमता, माउन्टिङ र Worker को नेटवर्क अनुमतिहरू द्वारा प्रतिबन्धित हुन्छ; सम्भावित RCE ले स्वचालित रूपमा root विशेषाधिकार वा होस्ट सम्झौतालाई संकेत गर्दैन। [S4](https://keendigit.com/ne/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/ne/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/ne/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/ne/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/ne/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/ne/insights/nginx-remediation-guide#source-9)

### 2.2 CVE-2026-15176: `alias` र पुनः लेखिएको URI बीचको मार्ग म्यापिङ अमान्य छ।

NGINX मा, मेल खाएको `location` र यसको `alias` फाइल मार्ग निर्धारण गर्दछ; `rewrite` ले हालको अनुरोध URI परिवर्तन गर्न सक्छ। पुनर्लेखन पछि, मूल `location` म्यापिङ द्वारा प्रयोग गरिएको अनुमानहरू अब धारण नहुन सक्छ।

प्रभावित प्रशोधन मार्गले जाँच गर्दा अनुरोध पुन: लेखिएको थियो कि छैन भनेर पर्याप्त रूपमा जाँच गरेन `alias` मा स्थिति `ngx_http_map_uri_to_path()` । जब कन्फिगरेसनले मूल्याङ्कन गर्न जारी राख्छ `$request_filename` पुन:लेखन पछि, मार्ग वर्तमान अनुरूप नहुने धारणाहरु संग निर्माण गर्न सकिन्छ URI राज्य, अन्ततः हिप मेमोरीमा आउट-अफ-बाउन्ड लेख्न ट्रिगर गर्दै। [S5](https://keendigit.com/ne/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/ne/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/ne/insights/nginx-remediation-guide#source-10)

आक्रमणको परिणाम: अनुरोध निर्माण गर्दा Worker पुन: सुरु गर्न वा सेवा अवरोध हुन सक्छ; ASLR बन्द भएको वा बाइपास गर्न सकिने जस्ता सर्तहरूमा, त्यहाँ सम्भावित RCE छ। अपस्ट्रीम प्याचको मूल भनेको निश्चित बफर विस्तार गर्नुको सट्टा `alias` सन्दर्भमा पुन: लेखिएको URI पथ म्यापिङ पूरा गर्न अस्वीकार गर्नु हो। [S5](https://keendigit.com/ne/insights/nginx-remediation-guide#source-5)[S10](https://keendigit.com/ne/insights/nginx-remediation-guide#source-10)

### 2.3 CVE-2026-93479: लिपि मूल्याङ्कनमा "आरक्षित ठाउँ" र वास्तविक चल लम्बाइ बीचको बेमेल

NGINX को HTTP र Stream मोड्युलहरूमा नतिजा स्ट्रिङमा शाब्दिक स्ट्रिङहरू र चर मानहरू जोड्ने स्क्रिप्ट मूल्याङ्कनकर्ताहरू छन्। अनुप्रयोग उदाहरणहरूमा HTTP कागजात root पथहरू, पहुँच लग पथहरू, र Stream मा चल अभिव्यक्तिहरू समावेश छन्।

`map` + रेगुलर एक्सप्रेशनका निश्चित कन्फिगरेसनहरूले `map` परिणाम चर मूल्याङ्कन गर्नु अघि कैप्चर गरिएका मानहरूलाई अन्य अभिव्यक्तिहरूद्वारा पढ्न अनुमति दिन्छ। आरक्षित लम्बाइको साथ स्क्रिप्ट कार्यान्वयन विधिसँग मिलाएर, पुरानो कार्यान्वयनले `len` आरक्षित ठाउँलाई मूल्याङ्कन गरिएको लम्बाइ सञ्चयकर्तामा पहिले नै गणना गर्नेछ, ताकि त्यसपछिको लेखन सूचक गणनाहरू अब बफर सीमासँग मेल खाँदैन। एक विशिष्ट चर मूल्याङ्कन अनुक्रममा, पछिको स्ट्रिङ राइटहरूले आरक्षित क्षेत्रलाई ओभरराइट गर्न सक्छ, जसले हिप ओभरफ्लो निम्त्याउँछ। [S6](https://keendigit.com/ne/insights/nginx-remediation-guide#source-6)

| सहभागी तत्वहरू                            | किन यो ध्यान दिन लायक छ                                                                                                  |
| ----------------------------------------- | ------------------------------------------------------------------------------------------------------------------------ |
| `map` मा regex                            | क्याप्चर चर मूल्याङ्कनमा स्वतन्त्र जीवन चक्र र क्यासिङ व्यवहार हुन सक्छ                                                  |
| बेनामी क्याप्चरहरू जस्तै `$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/ne/insights/nginx-remediation-guide#source-6)[S14](https://keendigit.com/ne/insights/nginx-remediation-guide#source-14)[S17](https://keendigit.com/ne/insights/nginx-remediation-guide#source-17)

यहाँ सम्भावित RCE जोखिम मेमोरी सुरक्षा वातावरणसँग सम्बन्धित छ, र यो दावी गर्नु हुँदैन कि `map` regex मात्र अज्ञात आक्रमणकारीहरूद्वारा शोषण गर्न सक्षम हुनेछ। [S11](https://keendigit.com/ne/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/ne/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/ne/insights/nginx-remediation-guide#source-7)

प्रयोज्यता निर्णय: SSI, AIO, भर्चुअल समावेशीकरण, सबरिक्वेस्टहरू र सम्बन्धित एसिन्क्रोनस अपरेसनहरू एउटै अनुरोध श्रृंखलामा संयोजनमा हुन सक्छन् कि भनेर मूल्याङ्कन गरिनुपर्छ। यी सामान्यतया पूर्वनिर्धारित सादा स्थिर प्रोक्सी कन्फिगरेसनहरू होइनन्। `aio off;` वा `ssi off;` ले विशिष्ट ट्रिगर तत्वहरू हटाउन सक्छ, तर व्यापार प्रकार्य निर्भरताहरू पहिले पुष्टि गर्नुपर्छ। [S4](https://keendigit.com/ne/insights/nginx-remediation-guide#source-4)[S7](https://keendigit.com/ne/insights/nginx-remediation-guide#source-7)[S25](https://keendigit.com/ne/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/ne/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/ne/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/ne/insights/nginx-remediation-guide#source-18)

यस भेद्यताको प्रत्यक्ष परिणाम ब्याकएन्ड अनुरोध अखण्डता र सुरक्षा सीमा परिवर्तनसँग सम्बन्धित छ, जुन RCE को प्रत्यक्ष रूपमा NGINX कोरमा पूरा भएको बराबर अभिव्यक्ति होइन। अन्तिम व्यापार प्रभाव कसरी यी बाइटहरू पार्स र भरोसा अपस्ट्रीम मा निर्भर गर्दछ। [S24](https://keendigit.com/ne/insights/nginx-remediation-guide#source-24)

### 2.6 CVE-2026-97629: TLS टिकट रोटेशनले तेस्रो कुञ्जी स्लट छुटेको छ

प्रभावित कन्फिगरेसनहरूमा, NGINX ले साझा मेमोरी क्यास मार्फत TLS सत्र टिकट कुञ्जीहरू स्वचालित रूपमा उत्पन्न र घुमाउन सक्छ, धेरै Worker लाई समान ब्याचको टिकटहरू प्रशोधन गर्न अनुमति दिन्छ।

सान्दर्भिक सिंक्रोनाइजेसन तर्कले प्रत्येक Worker को लागि 3 कुञ्जी स्लटहरू आवंटित गर्दछ, र डिक्रिप्शन कलब्याकले यी स्लटहरू पनि पार गर्नेछ; तर पुरानो कार्यान्वयनले प्रत्येक पटक साझा मेमोरीबाट 2 कुञ्जी स्लटहरू मात्र प्रतिलिपि गर्दछ, जसको परिणामस्वरूप कुञ्जी नाम, HMAC कुञ्जी र तेस्रो स्लटको AES। कुञ्जी सुरु नगरिएको हुन सक्छ। यदि टिकटको कुञ्जी पहिचानकर्ता यो स्थितिसँग मेल खान्छ भने, हस्ताक्षर प्रमाणीकरण र डिक्रिप्शनको लागि अप्रारम्भिक कुञ्जी सामग्री प्रयोग गर्न सकिन्छ, यसरी TLS सत्र फोर्ज गर्नको लागि मार्ग बनाउँछ। [S9](https://keendigit.com/ne/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/ne/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/ne/insights/nginx-remediation-guide#source-12)

यो TLS सत्र प्रमाणीकरण स्थिति मुद्दा हो र सर्भरको TLS निजी कुञ्जी क्र्याक भएको छ वा सार्वजनिक CA root प्रमाणपत्र प्रभावित छ कि छैन भन्नेसँग कुनै सरोकार छैन। [S24](https://keendigit.com/ne/insights/nginx-remediation-guide#source-24)

### 2.7 DoS, RCE, प्रमाणीकरण बाइपास र ज्ञात शोषण कसरी बुझ्ने

- DoS: मेमोरी त्रुटिले Worker लाई क्र्यास वा ठूलो रिबुट गराउँछ। यसले समग्र अनुपलब्धताको कारण ट्राफिक दबाब, प्रक्रिया पुन: सुरु गर्ने क्षमता, जडान मर्मत समय र उच्च-उपलब्धता वास्तुकलासँग सम्बन्धित छ।
- सम्भावित RCE: केही घोषणाहरूले ASLR बन्द वा बाइपास गर्दा कोड कार्यान्वयनको सम्भावना रहेको संकेत गर्छ। यसको मतलब यो होइन कि एक सार्वजनिक आक्रमण श्रृंखला जसले स्थिर र विश्वव्यापी रूपमा आदेशहरू कार्यान्वयन गर्न सक्छ खुलासा गरिएको छ। [S4](https://keendigit.com/ne/insights/nginx-remediation-guide#source-4)
- अनुरोध इंजेक्शन/प्रमाणीकरण बाइपास: यसले सीधै सुरक्षित व्यापार स्थिति वा अनुरोध सामग्री परिवर्तन गर्न सक्छ, र यसलाई बेवास्ता गर्न सकिँदैन किनभने यसले सीधै खोल प्राप्त गर्दैन।
- आक्रमण प्रयासहरू पत्ता लगाएको छ: CVE-2026-42945 मे 2026 मा जंगली शोषण गतिविधिहरूको रिपोर्ट छ; अक्टोबरका सबै पाँचवटा CVEs को ठूलो मात्रामा सफलतापूर्वक शोषण गरिएको छ भन्ने अर्थमा यस ऐतिहासिक तथ्यलाई प्रत्यक्ष रूपमा अनुमान लगाउनु हुँदैन। [S23](https://keendigit.com/ne/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/ne/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/ne/insights/nginx-remediation-guide#source-2)

### 3.2 पाँच CVE को अपस्ट्रीम प्रभाव दायरा

निम्न दायराहरू nginx.org सुरक्षा बुलेटिनको मूल पाठ अनुसार सूचीबद्ध छन् र "वर्तमान चलिरहेको शाखा" र "वास्तविक कन्फिगरेसन मार्ग" सँग संयोजनमा बुझ्न आवश्यक छ:

| CVE            | अपस्ट्रीम ट्यागहरू प्रभावित संस्करणहरू | आधिकारिक रूपमा लेबल गरिएको निश्चित संस्करण             |
| -------------- | -------------------------------------- | ------------------------------------------------------ |
| 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` regex जोखिम CVE-2026-42533 द्वारा प्रभावित हुन सक्छ। [S1](https://keendigit.com/ne/insights/nginx-remediation-guide#source-1)

### 3.3 Ubuntu: वितरण ब्याकपोर्टहरू (USN-8955-1)

क्यानोनिकल USN-8955-1 अक्टोबर 26, 2026 ले चार Ubuntu निर्माणहरूको लागि सुरक्षा अपडेट प्रदान गर्दछ: [S13](https://keendigit.com/ne/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/ne/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 संस्करण नम्बरबाट स्वतन्त्र प्याच सेट बोक्न सक्छ। अनुकूलन निर्माणहरूका लागि, तपाईंले पूर्ण स्रोत कोड प्याकेज फिक्स सेट जाँच गर्न आवश्यक छ, र तपाईंले एकल अपस्ट्रीम कमिट प्रतिलिपि गर्न सक्नुहुन्न र यसलाई पूर्ण रूपमा विचार गर्नुहोस्।

माथिको भिन्नता DSA र CVE ट्र्याकिङ रेकर्डहरूमा आधारित छ। [S14](https://keendigit.com/ne/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/ne/insights/nginx-remediation-guide#source-15)[S16](https://keendigit.com/ne/insights/nginx-remediation-guide#source-16)

### 3.5 NGINX Plus, njs र प्रवेश नियन्त्रक

| उत्पादनहरू/कम्पोनेन्टहरू                     | सुरक्षा चयन र प्रमाणीकरण मुख्य बिन्दुहरू                                                                                                                                                                                                                                                                                                                               |
| -------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| NGINX Plus (व्यावसायिक संस्करण)              | कृपया F5 सँग सम्बन्धित प्लस शाखाको घोषणा र अपग्रेड निर्देशनहरू हेर्नुहोस्। प्रमाणीकरणको समयमा पछिल्लो CR `PLS.37.2.0.1` हो, र LTS को सुरक्षा निर्माण `PLS.37.0.7.1` हो; प्लस संस्करण र समावेश ब्याकपोर्टलाई खुल्ला स्रोतको 1.30/1.31 थ्रेसहोल्डले प्रत्यक्ष रूपमा प्रतिस्थापन गर्न सकिँदैन। [S19](https://keendigit.com/ne/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/ne/insights/nginx-remediation-guide#source-20)                                                                                                      |
| F5 NGINX प्रवेश नियन्त्रक / गेटवे कपडा       | NGINX कोर एक सम्बन्धित तर स्वतन्त्र सफ्टवेयर वितरण श्रृंखला हो। तिनीहरूको सम्बन्धित नियन्त्रकहरू, छविहरू र रिलीज नोटहरूसँग सान्दर्भिक कमजोरीहरू ठीक गर्नुहोस्। तपाईंले पोडमा NGINX बाइनरी मात्र बदल्न सक्नुहुन्न।                                                                                                                                                      |
| Kubernetes समुदाय `kubernetes/ingress-nginx` | परियोजना मार्च 2026 मा खारेज गरिएको छ र अब नयाँ सुरक्षा मर्मतसम्भार प्रदान गर्दैन। तपाईंले F5 NGINX प्रवेश नियन्त्रकको लागि यसको रिलीज नम्बरलाई गल्ती गर्नुको सट्टा राखिएको नियन्त्रक वा Gateway API मा माइग्रेट गर्ने योजना बनाउनुपर्छ। [S21](https://keendigit.com/ne/insights/nginx-remediation-guide#source-21)                                                    |

### 3.6 तपाईले वास्तवमा कुन प्याच रोज्नुपर्छ?

| तैनाती फारम                                                                                       | सिफारिस गरिएका अभ्यासहरू                                                                                                                                       | मर्मतको प्रमाण                                                         |
| ------------------------------------------------------------------------------------------------- | -------------------------------------------------------------------------------------------------------------------------------------------------------------- | ---------------------------------------------------------------------- |
| nginx.org आधिकारिक DEB/RPM प्याकेज                                                                | अपस्ट्रिम शाखाको निश्चित संस्करणमा अपग्रेड गर्नुहोस्                                                                                                           | `nginx -v/-V`, प्याकेज स्रोत, आधिकारिक सुरक्षा घोषणा                   |
| Ubuntu/Debian आधिकारिक भण्डार                                                                     | विक्रेता सुरक्षा प्याकेजहरू स्थापना गर्नुहोस्                                                                                                                  | पूर्ण प्याकेज संस्करण + विक्रेता USN/DSA + CVE स्थिति                  |
| RHEL/अल्मा/रकी/SUSE/अन्य वितरण                                                                    | विशिष्ट वितरण सुरक्षा बुलेटिनहरू र प्याकेज संस्करणहरू अनुसार अपग्रेड गर्नुहोस्                                                                                 | सम्बन्धित विक्रेता CSAF/घोषणा, Ubuntu/Debian संस्करण लागू गर्न सकिँदैन |
| आधिकारिक वा अनुकूलन कन्टेनर छविहरू                                                                | प्रमाणित मर्मत छवि पुन: निर्माण वा तान्नुहोस् र यसलाई रोलिङ आधारमा बदल्नुहोस्                                                                                  | छवि डाइजेस्ट, SBOM निर्माण, पोड/कन्टेनर छवि ID चलिरहेको छ              |
| स्व-कम्पाइल गरिएको NGINX, OpenResty, Tengine वा तेस्रो-पक्ष मोड्युलहरूसँग प्याच गरिएका संस्करणहरू | मर्मतकर्ताको पूर्ण सुरक्षा संस्करणको प्रयोगलाई प्राथमिकता दिनुहोस्; आवश्यक हुँदा लक्षित स्रोत रूखको लागि समीक्षा गरिएको प्याच ब्याकपोर्टहरू प्रदर्शन गर्नुहोस् | पाँच जोखिम समाधान, ABI/मोड्युल अनुकूलता, एकाई र व्यापार प्रतिगमन       |

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` र regex क्याप्चर सक्षम गर्ने कि नगर्ने।

केवल पूर्वनिर्धारित `/etc/nginx/nginx.conf` जाँच नगर्नुहोस्। उत्पादन वातावरणले प्रायः धेरै साइटहरू, TLS र `include` मार्फत मोड्युल कन्फिगरेसनहरू लोड गर्दछ। त्यहाँ धेरै 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
```

यो केवल उम्मेद्वार पथ लोकेटर हो, भरपर्दो CVE स्वचालित निर्धारण उपकरण होइन:

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/ne/insights/nginx-remediation-guide#source-13)[S14](https://keendigit.com/ne/insights/nginx-remediation-guide#source-14)[S15](https://keendigit.com/ne/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/ne/insights/nginx-remediation-guide#source-22)

यदि तपाईंले `systemd` सकेट, कन्टेनर प्रविष्टि स्क्रिप्ट, वा बहु स्थापनाहरू मार्फत NGINX व्यवस्थापन गर्नुहुन्छ भने, तपाईंले `systemctl restart nginx` ले सबै उदाहरणहरू समेट्छ भनी सीधा मान्नुको सट्टा वास्तविक सुरुवात लक्ष्य र प्रक्रिया मार्ग जाँच गर्नुपर्छ।

### 4.6 स्वीकार गर्नुहोस् र वास्तविक बाह्य प्रवेशबाट व्यापार प्रतिगमन गर्नुहोस्

यो कम्तिमा प्रदर्शन गर्न सिफारिस गरिएको छ:

- के सामान्य HTTPS, पुन: लेखिएका मार्गहरू, स्थिर स्रोतहरू, र `alias` म्यापिङ पृष्ठहरू सही छन्।
- के नियमित `map` वितरण, चल root पथ, पहुँच लग पथ, SNI/प्रमाणपत्र मार्ग, र Stream प्रोक्सी सही छन्।
- सामान्य अपलोडहरू, chunked अपलोडहरू, API अनुरोधहरू र HTTP/3 (सक्षम हुँदा) को लागि अपस्ट्रीम भोल्युम सीमाहरू अझै अपेक्षित रूपमा छन्।
- mTLS: वैध प्रमाणपत्र अनुरोधहरू सफल हुनुपर्छ; हराइरहेको, म्याद सकिएको, वा अनाधिकृत प्रमाणपत्रहरू अझै पनि अस्वीकार गरिनुपर्छ, र TLS पुन: सुरु/पुन: जडानले गल्तिले अनुमतिहरू परिवर्तन गर्नु हुँदैन।
- SSI पृष्ठ र एसिन्क्रोनस फाइल पहुँच सामान्य छ कि छैन; त्रुटि लगले मेमोरी सन्दर्भ वा दोहोर्याइएको Worker क्र्यासहरूको लागि कुनै असामान्य अनुरोधहरू देखाउँदैन।
- ट्राफिक स्विच पछि, पुरानो संस्करण प्रक्रिया र पुरानो छवि प्रतिकृति बाहिर निस्कनु पर्छ।

परीक्षण आफ्नै वा अधिकृत वातावरणमा आयोजित हुनुपर्छ। सामान्य अनुरोध धुवाँ परीक्षणले एक्लै प्रमाणित गर्न सक्दैन कि मेमोरी कमजोरी फिक्स गरिएको छ; अन्ततः, स्वीकृतिको लागि आपूर्तिकर्ताको निश्चित संस्करण, स्रोत कोड प्याच र रनटाइम परीक्षण संयुक्त रूपमा स्वीकार गर्नुपर्छ।

## 5. तत्काल स्तरवृद्धि सम्भव नभएमा न्यूनीकरण उपायहरू

यो खण्ड जोखिम घटाउने विकल्प हो, प्याच प्रतिस्थापन होइन। सबै अस्थायी कन्फिगरेसन परिवर्तनहरू जगेडा गरिनुपर्छ, `nginx -t` कार्यान्वयन गर्नुपर्छ, ब्याचहरूमा जारी गरिएको छ, र आवश्यक भएमा तुरुन्तै फिर्ता गर्नुपर्छ। [S3](https://keendigit.com/ne/insights/nginx-remediation-guide#source-3)[S4](https://keendigit.com/ne/insights/nginx-remediation-guide#source-4)

### 5.1 बाह्य एक्सपोजरमा आधारित ट्राफिक प्राथमिकतालाई नियन्त्रण गर्नुहोस्

समयमा स्तरवृद्धि गर्न नसकिने सेवाहरूको आक्रमण सतहलाई कम गर्न प्राथमिकता दिनुहोस्: व्यवस्थापन सतह र आन्तरिक API मा विश्वसनीय स्रोत पहुँच नियन्त्रण, अपस्ट्रिम नेटवर्क अलगाव वा छोटो अवधि अफलाइन थप्नुहोस्; जडान थप्नुहोस्, उच्च-जोखिम प्रवेश द्वारहरूमा शरीर र दर सीमाहरू अनुरोध गर्नुहोस्; सुनिश्चित गर्नुहोस् कि स्रोत प्रमाणीकरण अनुरोध प्रशोधन श्रृंखला अघि प्रविष्टि-सम्बन्धित NGINX मा हुन्छ। यो ध्यान दिनुपर्छ कि धेरैजसो जोखिमहरू आफैं NGINX डाटा प्लेन भित्र अवस्थित छन्, परम्परागत WAF नियमहरूले अनुकूलन कन्फिगरेसन ट्रिगर अवस्थाहरू सही रूपमा निर्धारण गर्न सक्दैनन्।

### 5.2 `alias` / `rewrite`: पुनर्लेखन पछि `$request_filename` मूल्याङ्कन नगर्नुहोस्

यो जाँच गर्न र समायोजन गर्न सिफारिस गरिएको छ:

- `rewrite` प्रदर्शन नगर्ने प्रयास गर्नुहोस् जुन URI `location` `alias` प्रयोग गरेर एकै समयमा परिवर्तन हुनेछ।
- `$request_filename` प्रयोग नगर्नुहोस् जब URI पुन: लेखिएको छ तर सही स्थिति मिलान अझै पूरा भएको छैन।
- `return`, `set`, `if`, `add_header`, पहुँच लग ढाँचामा अप्रत्यक्ष चर सन्दर्भहरूको लागि जाँच गर्नुहोस्, र फाइलहरू समावेश गर्नुहोस्।
- व्यवसाय अनुमति दिँदा स्पष्ट `root`/`try_files`/स्वतन्त्र `location` प्रयोग गर्नुहोस्, तर `alias` लाई `root` मा परिवर्तन गर्नुहोस्। यसले फाइल मार्ग सिमान्टिक्स पनि परिवर्तन गर्न सक्छ, जुन एक एक गरेर प्रमाणित गरिनुपर्छ।

अवस्थित कन्फिगरेसन अधिलेखन गर्न इन्टरनेटमा सामान्य "सुरक्षित पुन: लेख्ने टेम्प्लेट" लाई सीधा प्रतिलिपि नगर्नुहोस्। विभिन्न `location` उपसर्गहरू र पुन: लेख्ने लक्ष्यहरू पूर्ण रूपमा फरक अर्थहरूका साथ पथ विभाजनमा परिणाम दिन्छ। [S5](https://keendigit.com/ne/insights/nginx-remediation-guide#source-5)

### 5.3 `map`/Regex: क्याप्चर चर स्टेट मिक्सिङ घटाउनुहोस्

`$1` जस्ता अज्ञात क्याप्चरहरूलाई समयसँगै विभिन्न regex मूल्याङ्कन मार्गहरूमा पुन: प्रयोग गर्न अनुमति दिनुको सट्टा नाम गरिएका क्याप्चरहरूलाई प्राथमिकता दिन र तिनीहरूको प्रसारको दायरा सीमित गर्न सिफारिस गरिन्छ। उदाहरणका लागि:

```nginx
# 演示具名捕获的结构，实际变量名和匹配表达式须按业务调整
map $host $tenant_root {
    default /srv/www/default;
    ~^(?<tenant>[a-z0-9-]+)\.example\.net$ /srv/www/$tenant;
}
```

यो स्निपेटले चर स्वामित्वको सजिलो-देखि-अडिट संरचना मात्र देखाउँछ; यसको मतलब यो होइन कि यो स्वतन्त्र रूपमा सबै CVE-2026-93479 ट्रिगर मार्गहरू हटाउन प्रमाणित भएको छ। विशेष रूपमा, क्याप्चर चरहरू अन्य `root` वा `log_format` द्वारा समय भन्दा अगाडि सन्दर्भ गरिएको छ कि छैन, र त्यहाँ `volatile`, गतिशील मार्गहरू, र अन्तरनिर्भर मूल्याङ्कन चेनहरू छन् कि छैनन् भनेर समीक्षा गर्नुहोस्। F5/CERT ले नामित क्याप्चर प्रयोग गर्न र छोटो अवधिको राहतको रूपमा सम्बन्धित नियमित मिल्दो कन्फिगरेसनमा प्रयोगको दायरा सीमित गर्न सिफारिस गर्दछ। [S3](https://keendigit.com/ne/insights/nginx-remediation-guide#source-3)[S6](https://keendigit.com/ne/insights/nginx-remediation-guide#source-6)

### 5.4 AIO + SSI: अनावश्यक प्रकार्य संयोजनहरू बन्द गर्नुहोस्

SSI वा एसिन्क्रोनस फाइल I/O आवश्यक नपर्ने सर्भर/पथहरूको लागि, प्रयोग गर्नुहोस्:

```nginx
# 在适当的 http/server/location 上下文中配置
ssi off;
aio off;
```

जोखिम ट्रिगर गर्ने अवस्थाहरूको परिप्रेक्ष्यमा, दुई मध्ये एउटा बन्द गर्नु सामान्यतया वर्णन गरिएको विशेष श्रृंखला हटाउन पर्याप्त हुन्छ; एकै समयमा बन्द हुनु केवल परिदृश्यहरूमा लागू हुन्छ जहाँ व्यवसायले यो क्षमतामा भर पर्दैन। `include virtual`, subrequests, क्यास, र थ्रेड पूल व्यवहार जाँच गर्नुहोस्; जब रिभर्स प्रोक्सी लोड उच्च हुन्छ, AIO बन्द गर्दा विलम्बता र I/O कार्यसम्पादन परिवर्तन हुन सक्छ। [S7](https://keendigit.com/ne/insights/nginx-remediation-guide#source-7)

### 5.5 HTTP/3 शरीर इन्जेक्सन अनुरोध गर्नुहोस्: यदि आवश्यक भएमा अस्थायी रूपमा प्रवेशद्वार बन्द गर्नुहोस्

असक्षम गर्नुहोस् `quic` श्रोता संलग्न HTTP/3 , रद्द गर्नुहोस् `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/ne/insights/nginx-remediation-guide#source-8)[S18](https://keendigit.com/ne/insights/nginx-remediation-guide#source-18)

### 5.6 TLS सत्र टिकट: प्राथमिकता सुरक्षा mTLS प्रमाणीकरण सीमा

यदि स्तरवृद्धि सम्भव छैन र उदाहरण साझा सत्र क्यास + स्वचालित टिकट कुञ्जी रोटेशनमा निर्भर छ भने, मूल्याङ्कन गर्नुहोस्:

```nginx
# 在 nginx http/server 适当作用域进行配置
ssl_session_tickets off;
```

यसले TLS सत्र टिकट संयन्त्रलाई बन्द गर्न सक्छ, जसले गर्दा यस जोखिममा वर्णन गरिएको टिकट जालसाजी मार्ग हटाउँछ; यद्यपि, यसले सत्र पुन: सुरुवात कार्यसम्पादनलाई असर गर्न सक्छ। तपाईंले "असुरक्षाहरूबाट बच्न" mTLS ग्राहक प्रमाणपत्र प्रमाणिकरणलाई बन्द गर्न सक्नुहुन्न, किनकि यसले प्रत्यक्ष प्रमाणीकरण सीमालाई मेटाउनेछ। [S9](https://keendigit.com/ne/insights/nginx-remediation-guide#source-9)[S12](https://keendigit.com/ne/insights/nginx-remediation-guide#source-12)

स्पष्ट `ssl_session_ticket_key` फाइलहरू र सुरक्षित रोटेशन पनि पेशेवर TLS व्यवस्थापन प्रक्रियाहरू द्वारा स्वचालित-उत्पन्न अवस्थाहरू रोक्न प्रयोग गर्न सकिन्छ, तर मुख्य हिरासत, पूर्ण नोड वितरण, रोटेशन, र पुरानो टिकट जीवनचक्रहरू सबै सावधानीपूर्वक अडिट गर्न आवश्यक छ। सामान्य वेब कन्फिगरेसन वा अस्थायी आपतकालिनका लागि स्क्रिप्टहरूमा दीर्घकालीन पुन: प्रयोगयोग्य कुञ्जीलाई हार्डकोड गर्न सिफारिस गरिँदैन। mTLS प्रयोग गर्ने आलोचनात्मक सेवाहरूलाई TLS सत्र पुन: सुरु गर्ने व्यवहार र वैध ग्राहक प्रमाणपत्र बिना अनुरोधहरूको अस्वीकारको लागि पनि निगरानी गरिनु पर्छ। [S12](https://keendigit.com/ne/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/ne/insights/nginx-remediation-guide#source-4)

### 5.8 सामान्य गलतफहमी: यी कार्यहरू मर्मत पूरा गर्न पर्याप्त छैनन्

| सामान्य कार्यहरू                                                                         | यो किन अपर्याप्त छ?                                                                                                |
| ---------------------------------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------ |
| "nginx -v अपेक्षाकृत नयाँ देखिन्छ"                                                       | यो कुन शाखासँग सम्बन्धित छ, रिलिज संस्करणको पूर्ण ब्याकपोर्टेड प्याकेज संस्करण र अनलाइन प्रक्रिया जाँच गरिएको छैन। |
| "इन्ट्रानेट मध्ये एउटा मात्र अपग्रेड गरिएको थियो"                                        | पुरानो Worker/पुरानो कन्टेनर/पुरानो CDN मूल उदाहरणले अझै पनि अनुरोधहरू प्राप्त गर्दछ                               |
| "साइटले PHP/गतिशील ट्यागहरू प्रयोग गर्दैन"                                               | दोष NGINX कोर पथ वा प्रोटोकल पार्सिङमा हुन्छ र PHP कार्यान्वयनमा भर पर्दैन।                                        |
| "WAF/Cloudflare खोल्नु पर्याप्त छ"                                                       | WAF सबै NGINX कन्फिगरेसन-निर्भर मेमोरी त्रुटिहरू वा TLS पुन: सुरु गर्ने त्रुटिहरू रोक्न प्रमाणित गर्न सकिँदैन।     |
| "ASLR पहिले नै खोलिएको छ"                                                                | केवल कठिनाई न्यूनीकरणको फाइदा उठाउँदै; DoS अनुरोध इंजेक्शन संग अझै पनि सम्भव छ                                     |
| "HTTP/3 सार्वजनिक नेटवर्कमा पर्दाफास गरिएको छैन, त्यसैले त्यहाँ अपग्रेड गर्न आवश्यक छैन" | अन्य चार CVE लाई अझै पनि स्वतन्त्र मूल्याङ्कन चाहिन्छ; र लुकेको उत्पत्तिसँग प्रत्यक्ष जडान हुन सक्छ                |
| "जुलाईको `map` जोखिम फिक्स गरिएको छ"                                                     | अक्टोबर CVE-2026-93479 ले पछिको लिपि मूल्याङ्कन प्रतिगमन समस्याहरू समावेश गर्दछ                                    |
| "क्यासिङ असक्षम गर्नाले सबै समस्या समाधान हुन्छ"                                         | केही TLS क्यास वा AIO परिदृश्यहरूलाई मात्र असर गर्छ, र उपनाम, स्क्रिप्ट, HTTP/3 कभर गर्दैन।                        |

## 6. आधिकारिक प्याच कार्यान्वयन विचार र समीक्षा अंक

यो खण्डले अक्टोबर 2026 अपस्ट्रीम NGINX फिक्सहरू पछ्याउँछ। स्निपेटहरूले प्याच समीक्षाको लागि प्रतिनिधि परिवर्तनहरू चित्रण गर्दछ; तिनीहरू पूर्ण छैनन्, स्वतन्त्र रूपमा कम्पाइल योग्य फिक्सहरू। अनुकूलन निर्माणहरूको लागि, पूर्ण कमिटहरू, वरपरको कोड र परीक्षणहरू समीक्षा गर्नुहोस्, र पूर्ण समर्थित रिलीजलाई प्राथमिकता दिनुहोस्। [S5](https://keendigit.com/ne/insights/nginx-remediation-guide#source-5)[S6](https://keendigit.com/ne/insights/nginx-remediation-guide#source-6)[S7](https://keendigit.com/ne/insights/nginx-remediation-guide#source-7)[S8](https://keendigit.com/ne/insights/nginx-remediation-guide#source-8)[S9](https://keendigit.com/ne/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/ne/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/ne/insights/nginx-remediation-guide#source-6)

अडिटिङ र ब्याकपोर्टिङ गर्दा, HTTP/Stream को सम्बन्धित मूल्याङ्कनकर्ता पनि कभर हुनुपर्छ; `map` को कन्फिगरेसन सिन्ट्याक्स फाइल मात्र जाँच गर्दा दोष फिक्स गरिएको छ भनेर प्रमाणित गर्न सक्दैन।

### 6.3 CVE-2026-97205: 8-बिट एसिन्क्रोनस सञ्चालन गणनाको लागि सुरक्षा थ्रेसहोल्ड सेट गर्नुहोस्

`src/http/ngx_http_request.h` मा Upstream थपियो:

```c
#define NGX_HTTP_MAX_BLOCKED 250
```

र एसिन्क्रोनस फाइल रिडिङ, क्यास पर्खाइ, आउटपुट फिल्टरिङ र थ्रेड सञ्चालनमा समान प्रविष्टिहरू थप्नुहोस्:

```c
if (r->main->blocked >= NGX_HTTP_MAX_BLOCKED) {
    /* 使用同步路径，或者拒绝新的异步操作 */
}
```

समीक्षा फोकस: `r->main->blocked` थप्ने सबै वास्तविक कोड पथहरू कभर हुनुपर्छ। तपाईंले हेडर फाइलमा थ्रेसहोल्ड स्थिरता मात्र लेख्न सक्नुहुन्न। ब्याकपोर्टले पनि सिंक्रोनस फलब्याक, एसिन्क्रोनस कलब्याक र त्रुटि फिर्ताको पूर्ण समन्वय जाँच गर्न आवश्यक छ कि कार्यहरूको प्रत्यक्ष अस्वीकृतिको कारणले गतिरोध वा सन्दर्भ चुहावट हुने छैन। [S7](https://keendigit.com/ne/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/ne/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/ne/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 नयाँ प्रमाणित निर्माणहरू चलाउँछन्, कुनै लिगेसी छविहरू बाँकी छैनन्         |

टोलीहरूका लागि तिनीहरूको आफ्नै विमोचनहरू कायम राख्न, प्रत्येक CVE को लागि अडिट योग्य प्याच आईडी, प्याकेज संस्करणहरू, लगहरू निर्माण, र रिग्रेसन रिपोर्टहरू राख्न सिफारिस गरिन्छ; सामान्य सञ्चालन र मर्मतसम्भारको लागि, सबैभन्दा सुरक्षित समाधान विक्रेताको पूर्ण सुरक्षा अपडेटहरू स्थापना गर्नु हो।

## 7. ऐतिहासिक जोखिम ब्याकट्र्याकिङ, पुराना शाखाहरू र अन्य उत्पादनहरू

### 7.1 NGINX कोर जोखिम मे देखि सेप्टेम्बर 2026 सम्म एक साथ पुष्टि गर्न योग्य

लामो समयदेखि अद्यावधिक नगरिएका धेरै NGINX उदाहरणहरू मात्र अक्टोबरमा नयाँ मुद्दाबाट प्रभावित छैनन्। निकट भविष्यमा निम्न प्रतिनिधि मर्मत नोडहरू छन्: [S1](https://keendigit.com/ne/insights/nginx-remediation-guide#source-1)[S2](https://keendigit.com/ne/insights/nginx-remediation-guide#source-2)

| CVE            | पहिलो फिक्स रिलीज                              | लेखापरीक्षण आवश्यक पर्ने प्रमुख जोखिम र सर्तहरू                                                                                                       |
| -------------- | ---------------------------------------------- | ----------------------------------------------------------------------------------------------------------------------------------------------------- |
| CVE-2026-42945 | Stable 1.30.1 / Mainline 1.31.0, मे १३         | `rewrite` बेनामी regex क्याप्चर र प्रतिस्थापन तर्कले हीप ओभरफ्लो ट्रिगर गर्दछ, सम्भावित RCE; त्यहाँ जंगली आक्रमण प्रयासहरूको सार्वजनिक रिपोर्टहरू छन् |
| CVE-2026-9256  | Stable 1.30.2 / Mainline 1.31.1, मे २२         | `rewrite` मा ओभरल्यापिङ regex क्याप्चर र लम्बाइ अनुमानले ओभरफ्लो निम्त्याउँछ                                                                          |
| CVE-2026-42055 | Stable 1.30.3 / Mainline 1.31.2, जुन १७        | HTTP/2 अपस्ट्रीम वा gRPC को लागि विशिष्ट कन्फिगरेसन, ठूलो अनुरोध हेडर अवस्था बफर ओभरफ्लो ट्रिगर गर्दछ                                                 |
| CVE-2026-42530 | Mainline 1.31.2, जुन १७                        | HTTP/3 प्रयोग पछि-नि:शुल्क; आधिकारिक मार्क प्रभावित दायरा `1.31.0–1.31.1`                                                                             |
| CVE-2026-42533 | Stable 1.30.4 / Mainline 1.31.3, जुलाई १५      | `map` + regex क्याप्चर चर मूल्याङ्कनले हिप ओभरफ्लो निम्त्याउँछ, र त्यसपछिका प्याचहरूमा CVE-2026-93479 सँग अक्टोबरमा रिग्रेसन सम्बन्ध छ।               |
| CVE-2026-60005 | Stable 1.30.4 / Mainline 1.31.3, जुलाई १५      | `ngx_http_slice_module` मेमोरी सामग्री विशिष्ट चर र क्यास अपडेट सर्तहरू अन्तर्गत लीक भयो                                                              |
| CVE-2026-56434 | Stable 1.30.4 / Mainline 1.31.3, जुलाई १५      | SSI UAF सँग सम्बन्धित छ; अक्टोबरको AIO गणना जोखिमको रूपमा समान root कारण होइन                                                                         |
| CVE-2026-90439 | Stable 1.30.5 / Mainline 1.31.6, सेप्टेम्बर 15 | HTTP/3 + विशिष्ट OpenSSL संस्करण संयोजनको सीमित हिप ओभरफ्लो, मुख्य रूपमा क्र्यास/सीमित मेमोरी भ्रष्टाचारको रूपमा प्रकट हुन्छ                          |

अन्य कमजोरीहरू जस्तै NGINX Core, HTTP/2, charset, र SMTP 2026 मा घोषणा गरिएको पनि आधिकारिक सुरक्षा बुलेटिनहरू अनुसार अनुसन्धान गरिनु पर्छ; यो तालिकाले जानाजानी सामान्य घटनाहरूमा केन्द्रित छ जुन हालको NGINX सार्वजनिक-फेसिङ रिभर्स प्रोक्सी डिप्लोइमेन्टहरूसँग सबैभन्दा सान्दर्भिक छन् र मेमोरी सुरक्षा वा अनुरोध अखण्डता प्रभावहरू छन्। 2026 मा सबै CVEs होइन। सूची। [S1](https://keendigit.com/ne/insights/nginx-remediation-guide#source-1)

#### CVE-2026-42945 मा किन विशेष ध्यान दिनुहोस्

त्यहाँ सरकारी एजेन्सीहरूबाट सुरक्षा बुलेटिनहरू छन् जुन मे महिनामा यस `rewrite` जोखिमको लागि जंगली शोषण गतिविधिहरू र सार्वजनिक शोषण कोड जानकारी रेकर्ड गर्दछ। तसर्थ, मे देखि हालसम्म लामो समयदेखि प्याच नगरिएको र सार्वजनिक नेटवर्कमा खुला जटिल नियमित अभिव्यक्ति पुन:लेखन भएका उदाहरणहरूको लागि, मर्मत पूरा गर्नुको अतिरिक्त, असामान्य Worker क्र्यास, पहुँच लगहरू र त्यस समयमा शंकास्पद परिवर्तनहरू थप रूपमा समीक्षा गर्नुपर्छ। [S23](https://keendigit.com/ne/insights/nginx-remediation-guide#source-23)

"एक आक्रमण प्रयास भयो" ले स्वचालित रूपमा प्रमाणित गर्दैन कि आक्रमणकारीले प्रत्येक लक्ष्यमा आदेशहरू विश्वसनीय रूपमा कार्यान्वयन गरेको छ; जब घटना प्रतिक्रिया संलग्न हुन्छ, सम्झौता सूचकहरू र प्रक्रिया क्र्यासहरू विशेषाधिकार वृद्धि वा निरन्तरताको वास्तविक प्रमाणहरूबाट अलग रूपमा छानबिन गरिनुपर्छ।

### 7.2 पुराना संस्करणहरू र वितरण ब्याकपोर्टहरूको लागि सुधार

NGINX विभिन्न शाखाहरूको आफ्नै समर्थन चक्र र विभिन्न जोखिम परिचय समयहरू छन्। पाँचवटा नयाँ प्याचहरू समीक्षा बिना सबै प्रारम्भिक स्रोत रूखहरूमा रोल आउट गर्न सकिँदैन।

| दृश्य                                                                             | सिफारिस गरिएको रणनीति                                                                                                                                                                          |
| --------------------------------------------------------------------------------- | ---------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------- |
| रिलीज संस्करणले पूर्ण सुरक्षा प्याचहरू घोषणा गरेको छ                              | विक्रेता प्याकेजहरू र कागजात पूरा प्याकेज संस्करणहरू प्रयोग गर्नुहोस्; असंगत अपस्ट्रीम बेयर बाइनरीहरूसँग प्रतिस्थापन नगर्नुहोस्                                                                |
| Debian 12 र अन्य प्रभावित रिलीजहरू जुन यस ब्याचमा सबै CVEs द्वारा कभर गरिएको छैन। | जोखिम कार्य आदेशहरू पेश गर्नुहोस्, बाह्य एक्सपोजर सीमित गर्नुहोस्, र आपूर्तिकर्ता/ELTS स्थिति जाँच गर्नुहोस्; माइग्रेट गर्नुहोस् वा आवश्यक पर्दा प्रमाणित मर्मत जारी श्रृंखला प्रयोग गर्नुहोस् |
| अपस्ट्रीम समर्थन समाप्त भएको ऐतिहासिक शाखाहरू                                     | समर्थित संस्करणहरूमा माइग्रेसनलाई प्राथमिकता दिनुहोस्; यदि छोटो अवधि ब्याकपोर्टिङ आवश्यक छ भने, रखरखावकर्ताहरूले निर्भरता र प्याच अनुकूलता मूल्याङ्कन गर्नेछन्, र पूर्ण परीक्षणहरू लेख्नेछन्।  |
| NGINX फोर्कको साथ आउँछ (OpenResty, Tengine, अनुकूलित गेटवे)                       | पहिले सम्बन्धित कोड मार्ग समावेश गरिएको छ कि छैन भनेर निर्धारण गर्नुहोस्, र त्यसपछि फोर्क मर्मतकर्ताको सुरक्षा कथन प्रयोग गर्नुहोस्। यो प्रत्यक्ष रूपमा अपस्ट्रीम संस्करणको बराबर हुन सक्दैन।  |
| सुरक्षा प्याचहरूले व्यापार कार्यक्षमतामा परिवर्तनहरू निम्त्याउँछ                  | चरणबद्ध रोलआउटहरू, संस्करणहरू बीच ट्राफिक स्विचिङ, र कन्फिगरेसन अनुकूलन अपनाउनुहोस्; सार्वजनिक नेटवर्कको अनफिक्स्ड संस्करणलाई अलगाव बिना पुनर्स्थापना गर्न उपयुक्त छैन।                        |

### 7.3 njs, प्रवेश र NGINX कोरको लागि अलग उपचार

- njs: NGINX मुख्य कार्यक्रमको अतिरिक्त, तपाईंले NGINX JavaScript मोड्युलको संस्करण पनि जाँच गर्न आवश्यक छ। `njs 1.0.2` ले एक अक्टोबर 2026 XML पार्सिङ मेमोरी थकान र XML प्रमाणीकरण असंगतता मुद्दालाई संस्था सन्दर्भ विशेषताहरू समाधान गर्छ। `nginx-saml` प्रयोग गरेर XML हस्ताक्षर प्रमाणीकरणसँग सम्बन्धित डिप्लोयमेन्टहरूका लागि, तपाईंले प्लग-इन परिदृश्यहरूको लागि आधिकारिक njs निर्देशनहरू थप पढ्नुपर्छ। [S20](https://keendigit.com/ne/insights/nginx-remediation-guide#source-20)
- F5 NGINX Plus / NGINX प्रवेश नियन्त्रक: प्लस, नियन्त्रक र गेटवे कपडा प्रत्येकमा अतिरिक्त सुरक्षा बुलेटिनहरू, विभिन्न प्याकेजिङ्ग संस्करणहरू र अद्वितीय नीति कमजोरीहरू हुन सक्छन्। एउटा लेयर अपग्रेड गर्नु भनेको अर्को लेयर स्वतः अपडेट गर्नु होइन। [S19](https://keendigit.com/ne/insights/nginx-remediation-guide#source-19)
- Kubernetes समुदाय ingress-nginx: Kubernetes अधिकारीहरूले मार्च 2026 मा नियन्त्रकले मर्मत बन्द गरेको घोषणा गरिसकेका छन्, र यसको गोदाम F5 नियन्त्रकसँग भ्रमित हुन सक्दैन। प्रभावित व्यवसायहरूले नयाँ सुरक्षा संस्करणको प्रतीक्षा गर्नुको सट्टा सहज स्थानान्तरण योजना र Ingress एनोटेसनहरू र Gateway API सिमान्टिक भिन्नताहरू प्रमाणित गर्नुपर्छ। [S21](https://keendigit.com/ne/insights/nginx-remediation-guide#source-21)

## 8. स्वीकृति मापदण्ड र अनुवर्ती निरीक्षणहरू

यो सिफारिस गरिएको छ कि निम्न सूची परिवर्तन कार्य आदेश को लागी स्वीकृति शर्तहरु को रूप मा प्रयोग गरिन्छ:

| परियोजना                    | योग्यता मापदण्डहरू                                                                                                    | राख्न सकिने प्रमाण                                                       |
| --------------------------- | --------------------------------------------------------------------------------------------------------------------- | ------------------------------------------------------------------------ |
| सम्पत्ति र पोर्टल कभरेज     | CDN लाई बाइपास गर्न सक्ने सबै बाह्य र प्रत्यक्ष-जडित उदाहरणहरू आविष्कार गरिएका छन्।                                   | डोमेन नाम, LB, IP, Pod/कन्टेनर सूची                                      |
| प्याकेज स्रोत र मर्मत दायरा | सबै लागू हुने CVE लाई कभर गर्न पुष्टि गरिएका संस्करणहरू प्रयोग गर्नुहोस्                                              | अपस्ट्रीम सुरक्षा सल्लाहकार, USN/DSA, प्याकेज संस्करण, छवि डाइजेस्ट      |
| पुरानो प्रक्रिया बाहिर      | सबै पुराना master/worker/कन्टेनरहरू प्रतिस्थापन गरिएको छ                                                              | PID/सुरु समय, रोलिङ डिप्लोइमेन्ट स्थिति, चलिरहेको छवि                    |
| कन्फिगरेसन अडिट             | उच्च जोखिम संयोजनहरू हटाइएका छन् वा प्याचहरूद्वारा कभर गरिएको छ, र विरासत सम्बन्धहरू प्रमाणित गरिएको छ।               | `nginx -T` को संशोधित सारांश र लेखा परीक्षण रेकर्ड                       |
| TLS/mTLS                    | विश्वसनीय प्रमाणपत्रहरू पास; अवैध वा हराएको प्रमाणपत्रहरू अस्वीकार गरियो; सत्र पुनःसुरुले प्रमाणीकरणलाई बाइपास गर्दैन | नकारात्मक/सकारात्मक प्रमाणीकरण परीक्षण, नियन्त्रित TLS परीक्षण परिणामहरू |
| HTTP/3 अनुरोध मुख्य भाग     | निश्चित मार्ग सक्षम गर्नुहोस्; अपस्ट्रिम अनुरोध मुख्य भाग र थ्रोटलिंग सही व्यवहार                                     | HTTP/3, प्रोक्सी अपलोड, भोल्युम सीमा प्रतिगमन परीक्षण                    |
| SSI/AIO                     | प्रकार्यले आवश्यकताहरू पूरा गर्दछ, Worker को कुनै असामान्य गर्भपात छैन                                                | व्यापार प्रतिगमन, दुर्घटना र त्रुटि दर अनुगमन                            |
| सञ्चालन र मर्मत अनुगमन      | कुनै स्पष्ट अपवाद 5xx, SIGSEGV, प्रक्रिया बारम्बार बाहिर निस्कन्छ                                                     | परिवर्तन अघि र पछि सेवा सूचकहरू र लगहरू                                  |
| रोलब्याक रणनीति             | यदि रोलब्याक आवश्यक छ भने, पहिले एक्सपोजर सीमित गर्नुहोस् र सुरक्षा सीमाहरू सुरक्षित गर्नुहोस्                        | आदेशहरू, आपतकालीन प्रवाहहरू, र क्वारेन्टाइन योजनाहरू परिवर्तन गर्नुहोस्  |
| त्यसपछिको जीवन चक्र         | सुरक्षा बुलेटिन सदस्यताहरू, कन्टेनर अद्यावधिक आवृत्ति, र शाखा माइग्रेसन योजनाहरू निर्धारण गर्नुहोस्                   | लेजर, जिम्मेवार व्यक्ति र अर्को लेखापरीक्षण मिति अपग्रेड गर्नुहोस्       |

### 8.1 लग र चलिरहेको स्थितिमा तपाईले केमा ध्यान दिनुपर्छ?

`worker process exited on signal` 、`SIGSEGV` , अनुरोध विफलता स्पाइकहरू, असामान्य स्रोत पहुँच एकत्रीकरण, अप्रत्याशित TLS सत्र पुन: सुरु/प्रमाणिक व्यवहार फिर्ताको लागि अनुरोध गरिएको लामो समयदेखि खुलासा भएका सर्भरहरूमा असामान्यताहरूको समस्या निवारण गर्नुहोस्। यी सूचकहरू केवल अनुसन्धान सुरागको रूपमा प्रयोग गर्न सकिन्छ र कुनै निश्चित CVE शोषण गरिएको छ भनेर प्रत्यक्ष प्रमाणित गर्न पर्याप्त प्रमाणहरू छैनन्। ;सान्दर्भिक लगहरूको अभावले त्यहाँ आक्रमण भएको छैन भनेर प्रमाणित गर्दैन।

### 8.2 सिफारिस गरिएको अन्तिम जोखिम निष्कर्ष शब्दहरू

उत्पादन वातावरणको लागि स्वीकृति रिपोर्टले निम्न सटीक अभिव्यक्ति प्रयोग गर्नुपर्छ:

> NGINX बाह्य सेवा प्रवेश द्वार र सफ्टवेयर प्याकेज स्रोत पहिचान गरिएको छ। सबै लागू उदाहरणहरू अपस्ट्रीम आधिकारिक सुरक्षा संस्करणमा अपग्रेड गरिएको छ, वा रिलीज विक्रेता द्वारा पुष्टि ब्याकपोर्ट पूरा भएको छ; पुरानो Worker र पुराना कन्टेनरहरू प्रतिस्थापन गरिएको छ। उपनाम/पुनर्लेखन/नक्सा, AIO/SSI, HTTP/3 अनुरोधको मुख्य भाग र TLS सत्र टिकट/mTLS सम्बन्धित कन्फिगरेसनहरू लेखा परीक्षित गरिएका छन् र कार्यात्मक र पुन: परीक्षण अनुरोधको परीक्षणमा पास भएका छन्। अझै सम्म स्तरवृद्धि पूरा नगरेका उदाहरणहरूको लागि, थप रूपमा एक्सपोजर क्षेत्रहरू, क्षतिपूर्ति उपायहरू, जिम्मेवार व्यक्तिहरू, र पूरा गर्ने समय सीमाहरू दर्ता गर्नुहोस्।

यदि Debian 12 वा अन्य रिलीजहरूको लागि प्याच अझै अपूर्ण छ भने, सम्पूर्ण स्वीकृति फारमलाई "पूर्ण" भनी न्याय गर्नु उपयुक्त हुँदैन; समाधान नभएको CVE, सम्बन्धित ट्रिगर कन्फिगरेसन छ कि छैन, अलगाव स्थिति र अन्तिम अपग्रेड मार्ग स्पष्ट रूपमा रेकर्ड हुनुपर्छ।

***

## परिशिष्ट: उद्धृत स्रोत र लिङ्कहरू

विवरण: पाठमा `[Sx]` नम्बरहरू समान रूपमा यस खण्डसँग मेल खान्छ। निम्नले अपस्ट्रीम परियोजना सुरक्षा घोषणाहरू, कोड कमिटहरू, आपूर्तिकर्ता रिलीज घोषणाहरू र राष्ट्रिय सुरक्षा एजेन्सी जानकारीलाई प्राथमिकता दिन्छ। उद्धृत कमजोरीहरूको गम्भीरता प्रत्येक जारी गर्ने संस्थाको मूल्याङ्कन मापदण्ड अनुसार वर्णन गरिएको छ; डाटा प्रमाणिकरण मिति अक्टोबर 27, 2026 हो।

### S1 — NGINX Open Source आधिकारिक सुरक्षा बुलेटिन

- <https://nginx.org/en/security_advisories.html>

अपस्ट्रीम प्रभावित संस्करणहरू, फिक्स शाखाहरू, र पाँच अक्टोबर CVEs को आधिकारिक गम्भीरता स्तरहरू समावेश गर्दछ, र 2026 मार्फत ऐतिहासिक कमजोरीहरू पनि समावेश गर्दछ।

### S2 — NGINX आधिकारिक संस्करण रिलीज रेकर्ड

- <https://nginx.org/news.html>
- <https://nginx.org/en/CHANGES-1.30>

1.30.6 / 1.31.7 को 2026-10-14, 1.31.8 को 2026-10-21, र मे देखि सेप्टेम्बरसम्म महत्वपूर्ण सुरक्षा रिलीज माइलस्टोनहरू पुष्टि गर्नुहोस्।

### S3 - सिंगापुरको साइबर सुरक्षा एजेन्सी: F5 NGINX तीन महत्वपूर्ण कमजोरीहरू

- <https://www.csa.gov.sg/alerts-and-advisories/alerts/al-2026-150/>

CVSS v4.0 9.2 स्कोर, आवश्यक कन्फिगरेसन अवस्था, र CVE-2026-15176, CVE-2026-93479, र CVE-2026-97205 को लागि अन्तरिम शमन सिफारिसहरूको विवरण।

### S4 - NHS इङ्गल्याण्ड: F5 NGINX उच्च जोखिम सल्लाह

- <https://digital.nhs.uk/cyber-alerts/2026/cc-4872>

मेमोरी सुरक्षा समस्याहरूको DoS / सम्भावित RCE प्रभाव, र ASLR बन्द वा बाइपास गरिँदै जस्ता अवरोधहरू वर्णन गर्दछ।

### S5 — आधिकारिक स्रोत प्रतिबद्ध: CVE-2026-15176

- <https://github.com/nginx/nginx/commit/f8a23425bd6840c4c36b4264edf576ba3646156f>

`alias` र `r->uri_changed` मा `ngx_http_map_uri_to_path()` को स्थिति जाँचसँग मेल खान्छ।

### S6 — आधिकारिक स्रोत प्रतिबद्ध: CVE-2026-93479

- <https://github.com/nginx/nginx/commit/6aa4b3fdd4fdc156153f2981eb4070690624447c>

HTTP/Stream लिपि लम्बाइ र आरक्षित बफर आवंटन तर्कसँग सम्बन्धित।

### S7 - आधिकारिक स्रोत प्रतिबद्ध: CVE-2026-97205

- <https://github.com/nginx/nginx/commit/6adfc05ece48f92446383ec1f145446848694698>

`r->main->blocked` काउन्ट थ्रेसहोल्ड `NGX_HTTP_MAX_BLOCKED 250` र एसिन्क्रोनस पथ फलब्याकसँग मेल खान्छ।

### S8 — आधिकारिक स्रोत प्रतिबद्ध: CVE-2026-95101

- <https://github.com/nginx/nginx/commit/1c173a2d8767730e678c27446138d7ae5dd6fd64>

HTTP/3 अज्ञात फ्रेम बाँकी लम्बाइ र DATA अनुरोध शरीर लम्बाइ अनुरूप स्थिति विभाजन।

### S9 — आधिकारिक स्रोत प्रतिबद्ध: CVE-2026-97629

- <https://github.com/nginx/nginx/commit/1916f26e6ca49296568633d309777e36527e5bb2>

सिङ्क्रोनाइजेसन TLS सत्र टिकट रोटेशनको समयमा सबै प्रमुख स्लटहरूसँग मेल खान्छ।

### S10 — F5: CVE-2026-15176 विक्रेताको घोषणा

- <https://my.f5.com/manage/s/article/K000162416>

`alias`, `rewrite`, `$request_filename` र पहुँच लगहरू जस्ता ट्रिगर कारकहरू सूचीबद्ध गर्नुहोस्।

### S11 — F5: CVE-2026-93479 विक्रेता घोषणा

- <https://my.f5.com/manage/s/article/K000162607>

सूची नक्शा regex क्याप्चर, root पथ, र लग चल मूल्याङ्कन सर्तहरू।

### S12 — NGINX आधिकारिक TLS/SSL मोड्युल कागजात

- <https://nginx.org/en/docs/http/ngx_http_ssl_module.html>

विवरण `ssl_session_cache`, `ssl_session_tickets`, `ssl_session_ticket_key` र ग्राहक प्रमाणपत्र प्रमाणीकरण र अन्य निर्देशनहरू।

### S13 — सुरक्षा सल्लाह: Ubuntu USN-8955-1 (2026-10-26)

- <https://ubuntu.com/security/notices/USN-8955-1>

Ubuntu 22.04 / 24.04 / 26.04 / 26.10. को पूर्ण सफ्टवेयर प्याकेज निश्चित संस्करण र वितरण दायरा प्रदान गर्नुहोस्।

### S14 — सुरक्षा सल्लाह: Debian DSA-6575-1 (2026-10-21)

- <https://lists.debian.org/debian-security-announce/2026/msg00490.html>

Debian 13 / trixie को लागि सुरक्षा फिक्स प्याकेज `1.26.3-3+deb13u10` पुष्टि गर्नुहोस्, र CVE-2026-93479 को ब्याकपोर्ट एसोसिएसन रेकर्ड गर्नुहोस्।

### S15 — जोखिम ट्र्याकिङ: Debian Security Tracker: CVE-2026-15176

- <https://security-tracker.debian.org/tracker/CVE-2026-15176>

Debian 12 / bookworm र Debian 13 / trixie को वितरण फिक्स स्थिति प्रमाणित गर्न प्रयोग गरियो। यो स्थिति भविष्यमा सुरक्षा अद्यावधिकहरूसँग परिवर्तन हुन सक्छ।

### S16 — जोखिम ट्र्याकिङ: Debian Security Tracker: CVE-2026-95101

- <https://security-tracker.debian.org/tracker/CVE-2026-95101>

विभिन्न Debian शाखाहरूमा HTTP/3 जोखिमको सुरक्षा स्थितिको पूरक पुष्टि।

### S17 — सुरक्षा सल्लाह: Red Hat: CVE-2026-93479

- <https://access.redhat.com/security/cve/cve-2026-93479>

अक्टोबर प्रतिगमन जोखिम र जुलाई CVE-2026-42533 को लागि फिक्स बीचको सम्बन्धको पूरक समझ।

### S18 — NGINX आधिकारिक रिभर्स प्रोक्सी मोड्युल कागजात

- <https://nginx.org/en/docs/http/ngx_http_proxy_module.html>
- <https://nginx.org/en/docs/http/ngx_http_core_module.html>

`proxy_request_buffering`, `client_max_body_size`, `alias`, `aio`, आदि जस्ता कन्फिगरेसनहरूको अर्थशास्त्र र पूर्वनिर्धारित मानहरू क्वेरी गर्नुहोस्।

### S19 — NGINX Plus आधिकारिक रिलीज नोटहरू

- <https://docs.nginx.com/nginx/releases/>

सूची प्लस CR/LTS शाखाहरू, संस्करणहरू, प्याचहरू र अपग्रेड अनुकूलता रिमाइन्डरहरू।

### S20 — NGINX JavaScript / njs आधिकारिक सुरक्षा बुलेटिन

- <https://nginx.org/en/docs/njs/security.html>
- <https://nginx.org/en/docs/njs/changes.html>

अक्टोबर 2026 njs 1.0.2 र सम्बन्धित XML प्रमाणीकरण, मेमोरी थकान समस्याहरू समावेश गर्दछ।

### S21 — Kubernetes: समुदाय ingress-nginx आधिकारिक सेवानिवृत्ति निर्देशनहरू

- <https://kubernetes.io/blog/2025/11/11/ingress-nginx-retirement/>
- <https://kubernetes.io/blog/2026/01/29/ingress-nginx-statement/>

ध्यान दिनुहोस् कि परियोजनाले मार्च 2026 मा नयाँ रिलीजहरू र सुरक्षा समाधानहरू रोकेको थियो, र यसलाई कायम राखिएको नियन्त्रक वा Gateway API मा स्थानान्तरण गर्न सिफारिस गरिन्छ।

### S22 — NGINX आधिकारिक सेवा नियन्त्रण र अनलाइन बाइनरी अपग्रेड निर्देशनहरू

- <https://nginx.org/en/docs/control.html>

प्रक्रिया स्विचिङ स्वीकृतिको लागि कन्फिगरेसन पुन: लोड, पुन: सुरु र अनलाइन कार्यान्वयनयोग्य फाइल अपग्रेड विधिहरू छुट्याउनुहोस्।

### S23 - सरकारी सुरक्षा सूचना: मे 2026 NGINX पुनर्लेखन जोखिम

- <https://its.ny.gov/2026-051>
- <https://www.govcert.gov.hk/en/alerts_detail.php?id=1881>

CVE-2026-42945 को लागि ऐतिहासिक जोखिम पृष्ठभूमि र सुरक्षा अद्यावधिक सुझावहरू प्रदान गर्नुहोस्; इन-द-वाइल्ड शोषण सम्बन्धी निर्णयहरू त्यस समयमा एजेन्सी घोषणा र थप घटना प्रमाणहरूमा आधारित हुनुपर्छ।

### S24 — F5: CVE-2026-95101 र CVE-2026-97629 विक्रेता घोषणाहरू

- <https://my.f5.com/manage/s/article/K000162613>
- <https://my.f5.com/manage/s/article/K000162606>

HTTP/3 अनुरोध बडी इन्जेक्सन र स्वचालित TLS टिकट कुञ्जी क्रमशः घुमाउने जोखिमहरू समावेश गर्दछ।

### S25 — F5: CVE-2026-97205 विक्रेताको घोषणा

- <https://my.f5.com/manage/s/article/K000162608>

वर्णन SSI/AIO ट्रिगर अवस्था र सम्भावित मेमोरी भ्रष्टाचार जोखिम।

[NGINX सुरक्षा अपडेट: कन्फिगरेसन जाँच, अपग्रेड र प्रमाणीकरण](https://keendigit.com/ne/news/nginx-security-update)

## सुरक्षा मर्मत परामर्श

प्रमाणपत्र विश्वास परिवर्तनहरूले तपाइँको प्रणालीलाई कसरी असर गर्छ भनेर निश्चित छैन? हामी प्रभावित ग्राहकहरूको मूल्याङ्कन गर्न र सुरक्षा अपडेटहरू योजना गर्न मद्दत गर्न सक्छौं।

[सुरक्षा अपडेटहरू छलफल गर्नुहोस्](<https://keendigit.com/ne/contact?service=security-remediation#form>)

[मूल पृष्ठ](<https://keendigit.com/ne/insights/nginx-remediation-guide>) · [सामग्री सूचकांक](<https://keendigit.com/ne/llms.txt>)

KeenDigit LLC · वायोमिङ फाइलिङ आईडी: 2026-002106155

[वायोमिङ सेक्रेटरी अफ स्टेटसँग पुष्टि गर्नुहोस्](<https://wyobiz.wyo.gov/Business/filingSearch.aspx>)

© 2026 KeenDigit LLC · Sheridan, वायोमिङ, संयुक्त राज्य अमेरिका · सबै अधिकार सुरक्षित।