CVE-2026-9256 NGINX ngx_http_rewrite_module PoC व्युत्पत्ति प्रक्रिया और विचार

उपयोग का दायरा: केवल स्थानीय प्रशिक्षण शृंखला, अधिकृत पुनरुत्पादन वातावरण, भेद्यता सत्यापन और सुरक्षा नियम विश्लेषण के लिए। अनधिकृत लक्ष्यों पर उपयोग न करें। इस लेख में PoC विचार केवल रिमोट से दिखाई देने वाले NGINX worker crash व्यवहार को सत्यापित करता है, इसमें RCE, ASLR बाइपास या स्थिर शोषण शृंखला शामिल नहीं है।

1. भेद्यता पृष्ठभूमि

CVE-2026-9256 NGINX ngx_http_rewrite_module में एक हीप बफ़र ओवरफ़्लो भेद्यता है। भेद्यता ट्रिगर करने के लिए केवल किसी निश्चित URI तक पहुँचना पर्याप्त नहीं है, बल्कि यह एक विशेष rewrite कॉन्फ़िगरेशन पैटर्न पर निर्भर करता है: rewrite रेगुलर एक्सप्रेशन में ओवरलैपिंग PCRE कैप्चर ग्रुप होते हैं, और replacement भाग में कई कैप्चर वेरिएबल्स (जैसे $1, $2) का संदर्भ होता है।

जब हमलावर एक विशेष URI बनाता है जो rewrite तर्क को संबंधित पथ में प्रवेश कराता है, तो NGINX कैप्चर की गई सामग्री को संसाधित करने, rewrite परिणाम को जोड़ने, या URI/पैरामीटर एस्केपिंग के दौरान लंबाई गणना और वास्तविक लेखन के बीच असंगति उत्पन्न कर सकता है, जिससे अंततः worker प्रक्रिया की हीप मेमोरी नष्ट हो जाती है।

इसलिए, इस भेद्यता की कुंजी /api पथ में नहीं है, बल्कि लक्ष्य NGINX कॉन्फ़िगरेशन में ऐसे कमज़ोर rewrite नियमों की उपस्थिति में है जिन्हें अनुरोध द्वारा हिट किया जा सकता है और जिनमें ओवरलैपिंग कैप्चर ग्रुप और कई कैप्चर वेरिएबल्स के संदर्भ हों। PoC में डिफ़ॉल्ट रूप से उपयोग किया जाने वाला /api केवल वर्तमान पुनरुत्पादन वातावरण में एक उदाहरण पथ है; वास्तविक परीक्षण में, लक्ष्य NGINX कॉन्फ़िगरेशन में मौजूद rewrite नियमों के अनुसार अनुरोध पथ को समायोजित करना आवश्यक है जिनमें ओवरलैपिंग कैप्चर ग्रुप और कई कैप्चर वेरिएबल्स के संदर्भ हों।

वर्तमान PoC का उद्देश्य worker crash / denial of service व्यवहार को सत्यापित करना है। यह सटीक हीप लेआउट बनाने, रिटर्न पता या फंक्शन पॉइंटर को ओवरराइट करने, या रिमोट कोड निष्पादन साबित करने का प्रयास नहीं करता है। रिमोट पक्ष पर स्थिर रूप से देखे जा सकने वाले साक्ष्य मुख्य रूप से हैं: ट्रिगर अनुरोध कनेक्शन का असामान्य रूप से डिस्कनेक्ट होना, उसके बाद NGINX सेवा का फिर से प्रतिक्रिया देना, और keep-alive कनेक्शन का ट्रिगर के बाद worker crash द्वारा बाधित होना।

2. केवल एक HTTP स्थिति कोड क्यों नहीं देखा जा सकता?

इस भेद्यता के ट्रिगर होने पर हमेशा एक निश्चित HTTP 500, 502 या 400 दिखाई नहीं देता। इसका कारण NGINX का master-worker मॉडल है, जिसमें worker प्रक्रिया क्रैश होने के बाद master एक नया worker शुरू करता है। हमलावर को रिमोट पक्ष पर जो दिखाई देता है, वह आमतौर पर पूरी सेवा का पूरी तरह से अनुपलब्ध होना नहीं है, बल्कि किसी कनेक्शन का अचानक टूटना, रीड टाइमआउट, कनेक्शन का रीसेट होना, और फिर / तक पुनः पहुँचने पर सामान्य प्रतिक्रिया प्राप्त करना है।

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

इसलिए, PoC को बहु-चरण सत्यापन के रूप में डिज़ाइन करने की आवश्यकता है:

1. पहले लक्ष्य की जीवितता की पुष्टि करें।
2. फिर पुष्टि करें कि उदाहरण rewrite पथ संभवतः प्रभावी हो सकता है।
3. ओवरफ़्लो ट्रिगर अनुरोध भेजें और देखें कि कनेक्शन असामान्य रूप से डिस्कनेक्ट या टाइमआउट होता है या नहीं।
4. तुरंत एक सामान्य अनुरोध भेजें और पुष्टि करें कि NGINX ने प्रतिक्रिया पुनर्स्थापित कर ली है या नहीं।
5. keep-alive विधि का उपयोग करके बार-बार सत्यापित करें कि worker कनेक्शन ट्रिगर के बाद स्थिर रूप से ड्रॉप होता है या नहीं।

केवल जब "ट्रिगर कनेक्शन असामान्य + बाद में सेवा पुनर्स्थापित + keep-alive कई राउंड ड्रॉप" एक साथ होते हैं, तभी अधिक निश्चित रूप से CVE-2026-9256 शैली के worker crash व्यवहार के अस्तित्व का निर्णय लिया जा सकता है।

3. PoC निर्माण विचार

वर्तमान PoC का मुख्य ट्रिगर पथ है:

GET /api/++++++++++++++++++++++++++++++++... HTTP/1.1
Host: 127.0.0.1:19321

जहाँ /api/ वर्तमान प्रशिक्षण शृंखला में rewrite नियम को हिट करने के लिए उपयोग किया जाने वाला उदाहरण रूट है, और इसके बाद बड़ी संख्या में + वर्ण जोड़े जाते हैं। डिफ़ॉल्ट संख्या 4096 है।

+ चुनने के तीन मुख्य कारण हैं।

पहला, + एक वैध URI वर्ण है, और सामान्य HTTP क्लाइंट का उपयोग करते समय यह आमतौर पर स्पेस, # आदि वर्णों की तरह काटा या बलपूर्वक रीराइट नहीं किया जाता है। इसलिए, वर्तमान PoC को कुछ request-target बाइपास भेद्यताओं की तरह रॉ सॉकेट का उपयोग करके अवैध अनुरोध लाइन बनाने की आवश्यकता नहीं है।

दूसरा, बड़ी संख्या में दोहराए गए वर्ण rewrite कैप्चर ग्रुप को पर्याप्त लंबा इनपुट प्रदान करते हैं, जिससे बाद के replacement जोड़ या एस्केप प्रसंस्करण का आउटपुट आकार बढ़ जाता है, जिससे लंबाई गणना और वास्तविक लेखन के बीच असंगति को ट्रिगर करना आसान हो जाता है।

तीसरा, दोहराए गए + का पेलोड संरचना में सरल है, जिसे पैकेट कैप्चर, लॉग और IDS नियमों में देखना आसान है, और थ्रेशोल्ड परीक्षण के लिए लंबाई समायोजित करना भी आसान है।

हालाँकि, यह ध्यान रखना चाहिए कि + भेद्यता को ट्रिगर करने वाला एकमात्र सैद्धांतिक वर्ण नहीं है। वास्तविक ट्रिगर स्थिति अभी भी "कमज़ोर rewrite कॉन्फ़िगरेशन को हिट करना + इनपुट का संबंधित कैप्चर ग्रुप में प्रवेश + rewrite आउटपुट प्रसंस्करण द्वारा हीप ओवरफ़्लो ट्रिगर करना" है। विभिन्न वातावरणों में, ट्रिगर रूट, वर्ण प्रकार, लंबाई थ्रेशोल्ड को समायोजित करने की आवश्यकता हो सकती है।

3.1 अन्य संभावित ट्रिगर वर्ण

वर्तमान PoC डिफ़ॉल्ट रूप से बड़ी संख्या में + को ट्रिगर वर्ण के रूप में चुनता है, लेकिन इसका मतलब यह नहीं है कि केवल + ही समस्या को ट्रिगर कर सकता है। + केवल एक वर्ण है जो सामान्य PoC में लिखने के लिए सबसे उपयुक्त है, क्योंकि यह URI में अपेक्षाकृत स्थिर है, सामान्य HTTP क्लाइंट द्वारा आसानी से भेजा जा सकता है, और पैकेट कैप्चर में स्पष्ट विशेषताएँ होती हैं।

भेद्यता सिद्धांत से, जब तक कोई वर्ण NGINX rewrite प्रसंस्करण के दौरान NGX_ESCAPE_ARGS एस्केप तर्क में प्रवेश करता है और मूल 1 बाइट से %XX रूप में 3 बाइट में विस्तारित होता है, तो "लंबाई गणना मान वास्तविक लेखन मान से कम होने" का अंतर उत्पन्न हो सकता है। दूसरे शब्दों में, ट्रिगर बिंदु मूल रूप से + नहीं है, बल्कि "args मोड द्वारा एस्केप किए जा सकने वाले वर्णों का घना होना" है।

+ के अलावा, सैद्धांतिक रूप से जिन वर्णों पर ध्यान देने की आवश्यकता है, उनमें शामिल हैं:

स्पेस: 0x20
#: 0x23
%: 0x25
&: 0x26
?: 0x3F
नियंत्रण वर्ण: 0x00-0x1F
उच्च बाइट: 0x7F-0xFF

यदि ये वर्ण संबंधित कैप्चर में प्रवेश करते हैं और rewrite replacement में args सामग्री के रूप में एस्केप प्रसंस्करण के अधीन होते हैं, तो समान विस्तार प्रभाव उत्पन्न होगा। उदाहरण के लिए:

+      -> %2B
&      -> %26
%      -> %25
#      -> %23
?      -> %3F
स्पेस   -> %20

ऐसे प्रत्येक वर्ण के प्रकट होने पर, सैद्धांतिक रूप से 1 बाइट से 3 बाइट में विस्तार होगा, वास्तविक लेखन लंबाई में 2 बाइट की वृद्धि होगी। यदि इनपुट में बड़ी संख्या में ऐसे वर्ण हैं, तो वास्तविक लेखन लंबाई पहले से गलत गणना की गई बफ़र लंबाई से काफी अधिक हो सकती है, जिससे हीप बफ़र ओवरफ़्लो को ट्रिगर करना आसान हो जाता है।

हालाँकि, PoC में विभिन्न वर्णों की उपलब्धता पूरी तरह से समान नहीं है।

+ सबसे स्थिर है। यह आमतौर पर सीधे HTTP request-target में दिखाई दे सकता है, ब्राउज़र या कमांड-लाइन टूल द्वारा काटे जाने की संभावना कम है, और यह URI के path/query संरचना को स्वाभाविक रूप से नहीं बदलता है। इसलिए, वर्तमान PoC डिफ़ॉल्ट पेलोड के रूप में 4096 + का उपयोग करता है।

& भी एक उम्मीदवार वर्ण हो सकता है, क्योंकि args मोड में इसे %26 में एस्केप किया जाता है। लेकिन शेल में & का बैकग्राउंड निष्पादन अर्थ होता है, और URL में इसे अक्सर क्वेरी पैरामीटर विभाजक के रूप में माना जाता है, इसलिए परीक्षण करते समय उद्धरण और स्थान पर ध्यान देने की आवश्यकता है, अन्यथा अनुरोध अपेक्षित रूप से नहीं भेजा जा सकता है।

% भी एक उम्मीदवार वर्ण हो सकता है, क्योंकि इसे %25 में एस्केप किया जाता है। लेकिन % स्वयं URL एन्कोडिंग उपसर्ग है, और कुछ क्लाइंट, प्रॉक्सी या फ्रेमवर्क %XX अनुक्रम की व्याख्या करने का प्रयास कर सकते हैं। यदि ठीक से निर्मित नहीं किया गया, तो लक्ष्य को मूल % वर्ण के बजाय क्लाइंट द्वारा पूर्व-संसाधित सामग्री प्राप्त हो सकती है।