w5m1n9/nginx-ngx_http_rewrite_module-heap-buffer-overflow-cve-2026-9256CVE-2026-9256 के लिए प्रूफ-ऑफ-कॉन्सेप्ट, NGINX के ngx_http_rewrite_module में हीप बफर ओवरफ्लो। अतिव्यापी PCRE कैप्चर समूहों के साथ तैयार किए गए URI के माध्यम से वर्कर क्रैश और सेवा से इनकार प्रदर्शित करता है। बहु-चरणीय सत्यापन और कीप-अलाइव प्रोबिंग शामिल है।
उपयोग का दायरा: केवल स्थानीय प्रशिक्षण शृंखला, अधिकृत पुनरुत्पादन वातावरण, भेद्यता सत्यापन और सुरक्षा नियम विश्लेषण के लिए। अनधिकृत लक्ष्यों पर उपयोग न करें। इस लेख में PoC विचार केवल रिमोट से दिखाई देने वाले NGINX worker crash व्यवहार को सत्यापित करता है, इसमें RCE, ASLR बाइपास या स्थिर शोषण शृंखला शामिल नहीं है।
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 में डिफ़ॉल्ट रूप से उपयोग किया जाने वाला केवल वर्तमान पुनरुत्पादन वातावरण में एक उदाहरण पथ है; वास्तविक परीक्षण में, लक्ष्य NGINX कॉन्फ़िगरेशन में मौजूद rewrite नियमों के अनुसार अनुरोध पथ को समायोजित करना आवश्यक है जिनमें ओवरलैपिंग कैप्चर ग्रुप और कई कैप्चर वेरिएबल्स के संदर्भ हों।
/apiवर्तमान PoC का उद्देश्य worker crash / denial of service व्यवहार को सत्यापित करना है। यह सटीक हीप लेआउट बनाने, रिटर्न पता या फंक्शन पॉइंटर को ओवरराइट करने, या रिमोट कोड निष्पादन साबित करने का प्रयास नहीं करता है। रिमोट पक्ष पर स्थिर रूप से देखे जा सकने वाले साक्ष्य मुख्य रूप से हैं: ट्रिगर अनुरोध कनेक्शन का असामान्य रूप से डिस्कनेक्ट होना, उसके बाद NGINX सेवा का फिर से प्रतिक्रिया देना, और keep-alive कनेक्शन का ट्रिगर के बाद worker crash द्वारा बाधित होना।
इस भेद्यता के ट्रिगर होने पर हमेशा एक निश्चित HTTP 500, 502 या 400 दिखाई नहीं देता। इसका कारण NGINX का master-worker मॉडल है, जिसमें worker प्रक्रिया क्रैश होने के बाद master एक नया worker शुरू करता है। हमलावर को रिमोट पक्ष पर जो दिखाई देता है, वह आमतौर पर पूरी सेवा का पूरी तरह से अनुपलब्ध होना नहीं है, बल्कि किसी कनेक्शन का अचानक टूटना, रीड टाइमआउट, कनेक्शन का रीसेट होना, और फिर / तक पुनः पहुँचने पर सामान्य प्रतिक्रिया प्राप्त करना है।
इसलिए, PoC केवल एक अनुरोध के HTTP स्थिति कोड के आधार पर भेद्यता के अस्तित्व का निर्णय नहीं कर सकता। यदि कोई केवल एक बार लंबा URI भेजता है और फिर कनेक्शन टूटता देखता है, और सीधे "भेद्यता मौजूद है" का निष्कर्ष निकालता है, तो गलत-सकारात्मक जोखिम अधिक है। कनेक्शन टूटना नेटवर्क उतार-चढ़ाव, प्रॉक्सी टाइमआउट, मध्यवर्ती उपकरण द्वारा अनुरोध अवरोधन, बैकएंड रेट लिमिटिंग, या सर्वर साइड द्वारा सक्रिय रूप से कनेक्शन बंद करने के कारण भी हो सकता है।
इसलिए, PoC को बहु-चरण सत्यापन के रूप में डिज़ाइन करने की आवश्यकता है:
केवल जब "ट्रिगर कनेक्शन असामान्य + बाद में सेवा पुनर्स्थापित + keep-alive कई राउंड ड्रॉप" एक साथ होते हैं, तभी अधिक निश्चित रूप से CVE-2026-9256 शैली के worker crash व्यवहार के अस्तित्व का निर्णय लिया जा सकता है।
वर्तमान 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 आउटपुट प्रसंस्करण द्वारा हीप ओवरफ़्लो ट्रिगर करना" है। विभिन्न वातावरणों में, ट्रिगर रूट, वर्ण प्रकार, लंबाई थ्रेशोल्ड को समायोजित करने की आवश्यकता हो सकती है।
वर्तमान 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 अनुक्रम की व्याख्या करने का प्रयास कर सकते हैं। यदि ठीक से निर्मित नहीं किया गया, तो लक्ष्य को मूल % वर्ण के बजाय क्लाइंट द्वारा पूर्व-संसाधित सामग्री प्राप्त हो सकती है।
? सैद्धांतिक रूप से एस्केप करने योग्य वर्णों में से है, लेकिन HTTP request-target में यह path और query को अलग करता है। यदि इसे सीधे पथ में रखा जाता है, तो इसके बाद की सामग्री को क्वेरी स्ट्रिंग के रूप में पार्स किया जा सकता है, जिससे rewrite कैप्चर रेंज बदल जाती है। इसलिए, यह पूरक परीक्षण वर्ण के रूप में अधिक उपयुक्त है, डिफ़ॉल्ट PoC मुख्य वर्ण के रूप में नहीं।
# सैद्धांतिक रूप से एस्केप को ट्रिगर कर सकता है, लेकिन ब्राउज़र # और उसके बाद के फ़्रैगमेंट को सर्वर पर नहीं भेजते हैं, और कई उन्नत HTTP क्लाइंट भी इसे एन्कोड या काट देते हैं। इसलिए, यदि शाब्दिक # का परीक्षण करना है, तो आमतौर पर रॉ सॉकेट, Burp Repeater या मूल request-target को बनाए रखने वाले टूल की आवश्यकता होती है, ब्राउज़र एड्रेस बार पर निर्भर नहीं किया जा सकता।
स्पेस 0x20 भी एस्केप करने योग्य वर्ण है, लेकिन सामान्य HTTP/1.1 अनुरोध लाइन में स्पेस स्वयं एक विभाजक है, इसे सीधे request-target में रखने से अनुरोध लाइन संरचना खराब हो जाती है। वास्तविक परीक्षण में, यदि इसे %20 के रूप में लिखा जाता है, तो सर्वर प्रसंस्करण चरण में यह एन्कोडेड रूप या डीकोडेड स्पेस के रूप में दिखाई देता है, यह विशिष्ट पार्सिंग प्रक्रिया और rewrite स्थान पर निर्भर करता है। इसलिए, स्पेस सिद्धांत स्पष्टीकरण और सहायक परीक्षण के लिए अधिक उपयुक्त है, डिफ़ॉल्ट पेलोड के रूप में नहीं।
0x00-0x1F नियंत्रण वर्ण और 0x7F-0xFF उच्च बाइट भी एस्केप रेंज में हैं, लेकिन वास्तविक HTTP लिंक में वे क्लाइंट, प्रॉक्सी, WAF या NGINX HTTP पार्सर द्वारा अवरोधित, सामान्यीकृत या अस्वीकार किए जाने की अधिक संभावना रखते हैं। उन्हें स्रोत कोड स्तर पर एस्केप ऑब्जेक्ट के रूप में समझाया जा सकता है, लेकिन नियमित PoC के डिफ़ॉल्ट ट्रिगर वर्ण के रूप में अनुशंसित नहीं किया जाता है।
इसलिए, वर्तमान PoC में + का उपयोग करने का कारण यह नहीं है कि भेद्यता केवल + द्वारा ट्रिगर की जा सकती है, बल्कि यह है कि + एक साथ तीन शर्तों को पूरा करता है: यह args एस्केप विस्तार को ट्रिगर कर सकता है, इसे स्थिर रूप से भेजना आसान है, और यह URI संरचना को स्पष्ट रूप से नहीं बदलता है। सुरक्षा नियम या ट्रैफ़िक विश्लेषण करते समय केवल सन्निहित + से मेल खाना पर्याप्त नहीं है, बल्कि अन्य एस्केप करने योग्य वर्णों के उच्च-घनत्व संयोजनों पर भी विचार करना चाहिए, विशेष रूप से लंबे URI में बड़ी संख्या में +, &, %, ?, # आदि वर्णों का दिखना।
पता लगाने के दृष्टिकोण से, अधिक उचित सामान्यीकरण यह नहीं है:
/api/ के बाद बड़ी संख्या में +
बल्कि यह है:
लंबे URI में बड़ी संख्या में विशेष वर्ण जो NGX_ESCAPE_ARGS मोड में %XX में विस्तारित होते हैं
यदि केवल ++++ का पता लगाया जाता है, तो नियम केवल वर्तमान PoC के डिफ़ॉल्ट लेखन को कवर करेगा; यदि हमलावर पेलोड को &&&&, %%%%, ???? में बदलता है, या +%&?# को मिलाकर उपयोग करता है, तो एकल + विशेषता से चूक जाने की संभावना है। अधिक स्थिर पता लगाने का दृष्टिकोण URI लंबाई, विशेष वर्ण घनत्व, सन्निहित पुनरावृत्ति संख्या, rewrite जोखिम पथ और NGINX सेवा एक्सपोज़र सतह को संयोजित करके सामूहिक निर्णय लेना है।
PoC का normalize_target फ़ंक्शन कमांड-लाइन इनपुट को संसाधित करने के लिए जिम्मेदार है, तीन रूपों का समर्थन करता है:
python3 CVE-2026-9256-poc.py 127.0.0.1:19321
python3 CVE-2026-9256-poc.py 127.0.0.1 19321
python3 CVE-2026-9256-poc.py http://127.0.0.1:19321
यदि उपयोगकर्ता केवल host:port बिना स्कीम के दर्ज करता है, तो स्क्रिप्ट स्वचालित रूप से http://host:port जोड़ देगी। फिर urllib.parse.urlparse का उपयोग करके hostname और port को पार्स किया जाएगा, और base उत्पन्न किया जाएगा, उदाहरण के लिए:
host = 127.0.0.1
port = 19321
base = http://127.0.0.1:19321
वर्तमान कार्यान्वयन मुख्य रूप से HTTP प्लेनटेक्स्ट प्रशिक्षण शृंखला के लिए है। हालाँकि normalize_target https:// रूप को स्वीकार करता है, बाद में keep-alive पता लगाना सामान्य TCP सॉकेट का उपयोग करता है, जिसमें TLS परत शामिल नहीं है, इसलिए HTTPS परिदृश्य में crash probe गलत होगा। HTTPS का समर्थन करने के लिए, सॉकेट में ssl.wrap_socket या ssl.create_default_context().wrap_socket() जोड़ने की आवश्यकता है।
PoC पहले check_alive(base) को कॉल करता है और रूट पथ / तक पहुँचता है:
GET /
यदि लक्ष्य कोई भी HTTP स्थिति कोड वापस कर सकता है, तो सेवा मूल रूप से जीवित है, और परीक्षण जारी रखा जा सकता है। यदि कनेक्शन विफल हो जाता है, तो यह सीधे बाहर निकल जाता है, अप्राप्य लक्ष्य को भेद्यता ट्रिगर विफलता के रूप में गलत निर्णय लेने से बचाता है।
इसके बाद, check_rewrite(base) को कॉल करके एक्सेस किया जाता है:
GET /api/test
यह अनुरोध यह देखने के लिए है कि /api/* वर्तमान प्रशिक्षण शृंखला में rewrite तर्क को हिट कर सकता है या नहीं। यदि यह 301, 302, 303, 307, 308 जैसे रीडायरेक्ट स्थिति कोड लौटाता है, तो rewrite रीडायरेक्ट व्यवहार स्पष्ट है, PoC सहायक साक्ष्य के रूप में Location शीर्षक प्रिंट करेगा।
लेकिन यह चरण अनिवार्य सफलता की शर्त नहीं है। क्योंकि कुछ पुनरुत्पादन कॉन्फ़िगरेशन में, /api/* स्वयं समस्याग्रस्त rewrite पथ में प्रवेश कर सकता है, और सामान्य जांच अनुरोध भी टाइमआउट या असामान्य रूप से संसाधित हो सकता है। इसलिए, स्क्रिप्ट सामान्य rewrite प्रतिक्रिया प्राप्त न होने पर भी ट्रिगर चरण में प्रवेश करती रहेगी।
ट्रिगर फ़ंक्शन send_trigger(base, plus_count=4096) है, मुख्य तर्क जोड़ रहा है:
payload = "/api/" + ("+" * plus_count)
डिफ़ॉल्ट अंतिम अनुरोध पथ इस प्रकार है:
/api/++++++++++++++++++++++++++++++++... कुल 4096 +
फिर requests.get(base + payload, timeout=10, allow_redirects=False) के माध्यम से अनुरोध भेजा जाता है।
यहाँ स्वचालित रीडायरेक्ट को अक्षम करने के दो कारण हैं।
पहला, rewrite स्वयं रीडायरेक्ट वापस कर सकता है। यदि HTTP क्लाइंट स्वचालित रूप से रीडायरेक्ट का अनुसरण करता है, तो मूल ट्रिगर अनुरोध और बाद के रीडायरेक्ट अनुरोध मिश्रित हो जाएंगे, जिससे यह निर्णय करना कठिन हो जाएगा कि पहले अनुरोध के साथ वास्तव में क्या हुआ।
दूसरा, PoC ट्रिगर चरण के दौरान कनेक्शन स्थिति पर ध्यान केंद्रित करता है, रीडायरेक्ट के बाद के व्यावसायिक पृष्ठ पर नहीं। मूल प्रतिक्रिया को बनाए रखना विश्लेषण के लिए अधिक अनुकूल है।
ट्रिगर परिणाम कई श्रेणियों में विभाजित है:
यदि ConnectionError पकड़ा जाता है, तो इसका मतलब है कि ट्रिगर अनुरोध के दौरान कनेक्शन असामान्य रूप से बंद हो गया, जो worker crash का रिमोट प्रकटीकरण हो सकता है।
यदि ReadTimeout पकड़ा जाता है, तो इसका मतलब है कि अनुरोध भेजने के बाद लंबे समय तक कोई सामान्य प्रतिक्रिया नहीं मिली, यह worker के हैंग होने, क्रैश होने से पहले सामान्य रूप से वापस न आने, या नेटवर्क वातावरण के कारण टाइमआउट का संकेत हो सकता है।
यदि HTTP प्रतिक्रिया सामान्य रूप से प्राप्त होती है, तो स्थिति कोड और प्रतिक्रिया निकाय लंबाई प्रिंट होती है, लेकिन केवल सामान्य प्रतिक्रिया के आधार पर भेद्यता को नकारा नहीं जा सकता, क्योंकि कुछ वातावरणों में ट्रिगर स्थितियाँ पूरी तरह से संतुष्ट नहीं हो सकती हैं, या पेलोड लंबाई अपर्याप्त हो सकती है।
ट्रिगर अनुरोध के बाद, PoC 1 सेकंड प्रतीक्षा करता है, फिर follow_up(base) को कॉल करके फिर से रूट पथ / तक पहुँचता है।
इस कदम का उद्देश्य ओवरफ़्लो को साबित करना नहीं है, बल्कि यह निर्धारित करना है कि NGINX "worker crash के बाद master द्वारा पुनर्प्रारंभ किया गया" की विशेषता दिखाता है या नहीं।
यदि ट्रिगर अनुरोध कनेक्शन असामान्य रूप से डिस्कनेक्ट होता है, लेकिन बाद में / तक पहुँचने पर 200 या कोई अन्य सामान्य HTTP स्थिति कोड मिलता है, तो इसका मतलब है कि सेवा पूरी तरह से डाउन नहीं हुई है, बल्कि एक एकल worker प्रक्रिया क्रैश होकर पुनर्स्थापित हुई है।
यदि ट्रिगर के बाद सेवा लंबे समय तक अप्राप्य रहती है, तो यह पूरी सेवा के बंद होने, कंटेनर क्रैश या नेटवर्क असामान्यता का संकेत हो सकता है, ऐसा परिणाम सीधे CVE-2026-9256 के सफल ट्रिगर के बराबर नहीं ठहराया जा सकता।
इसलिए, वर्तमान PoC का निर्णय मानदंड है: रिमोट से दिखाई देने वाला worker crash, न कि केवल "सेवा अनुपलब्ध"।
PoC में सबसे महत्वपूर्ण स्थिरता सत्यापन keepalive_probe(host, port, rounds=5, plus_count=4096) है।
यह requests का उपयोग नहीं करता, बल्कि सीधे socket.create_connection का उपयोग करके TCP कनेक्शन स्थापित करता है, और उसी keep-alive कनेक्शन पर लगातार तीन अनुरोध भेजता है।
पहला अनुरोध सामान्य अनुरोध है:
GET / HTTP/1.1
Host: 127.0.0.1
Connection: keep-alive
यह अनुरोध यह पुष्टि करने के लिए है कि वर्तमान कनेक्शन उपलब्ध है, और यह सुनिश्चित करने का प्रयास करता है कि बाद का ट्रिगर अनुरोध उसी कनेक्शन पर पड़े।
दूसरा अनुरोध ट्रिगर अनुरोध है:
GET /api/++++++++++++++++++++++++++++++++... HTTP/1.1
Host: 127.0.0.1
Connection: keep-alive
यदि यह अनुरोध worker crash को ट्रिगर करता है, तो उस worker द्वारा बनाए रखा गया keep-alive कनेक्शन संभवतः सीधे बंद हो जाएगा।
तीसरा अनुरोध फिर से सामान्य अनुरोध है:
GET / HTTP/1.1
Host: 127.0.0.1
Connection: close
यदि तीसरे अनुरोध पर प्रतिक्रिया प्राप्त होती है, तो इसका मतलब है कि ट्रिगर अनुरोध के कारण कनेक्शन बाधित नहीं हुआ, इस राउंड में worker crash नहीं माना जाता।
यदि तीसरा अनुरोध भेजने में विफल होता है, डेटा नहीं पढ़ा जा सकता, या कनेक्शन पहले ही बंद हो चुका है, तो इसे रिकॉर्ड किया जाता है:
keepalive connection dropped
PoC डिफ़ॉल्ट रूप से 5 राउंड दोहराता है। कई राउंड दोहराने का अर्थ यादृच्छिक नेटवर्क त्रुटियों के कारण गलत निर्णय को कम करना है। यदि 5 राउंड में कई बार keep-alive ड्रॉप होता है, और सेवा बाद में प्रतिक्रिया पुनर्स्थापित करती है, तो रिमोट पक्ष पर साक्ष्य अधिक पर्याप्त होता है।
PoC का अंतिम निर्णय तीन स्तरों में विभाजित है।
पहला स्तर: भेद्यता पुष्टि।
शर्तें हैं:
crash_count > 0 and recovered == True
अर्थात, keep-alive जांच में कम से कम एक राउंड में कनेक्शन ड्रॉप का पता चला, और फ़ॉलो-अप सामान्य अनुरोध से साबित हुआ कि सेवा ने प्रतिक्रिया पुनर्स्थापित कर ली है। स्क्रिप्ट आउटपुट:
VULNERABILITY CONFIRMED - CVE-2026-9256 style crash behavior
Impact confirmed: worker crash / denial of service
RCE is not proven by this script
यह दर्शाता है कि वर्तमान वातावरण CVE-2026-9256 शैली का worker crash व्यवहार प्रदर्शित करता है, लेकिन रिमोट कोड निष्पादन साबित नहीं होता।
दूसरा स्तर: संदिग्ध उपस्थिति।
शर्तें हैं:
kind == "connection_error" and recovered == True
अर्थात, मुख्य ट्रिगर अनुरोध पर कनेक्शन डिस्कनेक्ट हुआ, और बाद में सेवा पुनर्स्थापित हुई, लेकिन keep-alive probe ने worker crash की स्थिर पुष्टि नहीं की। स्क्रिप्ट आउटपुट VULNERABILITY SUSPECTED।
यह स्थिति एक असामान्य घटना का संकेत देती है, लेकिन साक्ष्य पर्याप्त स्थिर नहीं हैं, सर्वर-साइड error.log, core dump, कंटेनर लॉग या डीबगर के संयोजन से आगे पुष्टि की आवश्यकता है।
तीसरा स्तर: पुष्टि नहीं हुई।
यदि न तो विश्वसनीय keep-alive ड्रॉप है, न ही ट्रिगर कनेक्शन असामान्यता और सेवा पुनर्स्थापना का संयोजन है, तो स्क्रिप्ट आउटपुट:
VULNERABILITY NOT CONFIRMED
इसका अर्थ यह नहीं है कि लक्ष्य में निश्चित रूप से भेद्यता नहीं है, बल्कि यह हो सकता है कि पथ ने rewrite को हिट नहीं किया, पेलोड लंबाई अपर्याप्त थी, वर्ण चयन अनुकूल नहीं था, लक्ष्य संस्करण पहले ही ठीक कर दिया गया है, फ्रंटएंड प्रॉक्सी ने URI बदल दिया है, या वर्तमान स्क्रिप्ट HTTPS के लिए अनुकूलित नहीं है।
स्क्रिप्ट निष्पादन प्रवाह को संक्षेप में प्रस्तुत किया जा सकता है:
/ का अनुरोध करें, लक्ष्य सेवा की जीवितता की पुष्टि करें।/api/test का अनुरोध करें, उदाहरण rewrite पथ की सक्रियता का निर्धारण करने का प्रयास करें।/api/ जोड़कर 4096 + का लंबा URI ट्रिगर अनुरोध भेजें।/ का अनुरोध करें, worker की पुनर्प्राप्ति की पुष्टि करें।स्थानीय प्रशिक्षण शृंखला उदाहरण:
python3 CVE-2026-9256-poc.py http://127.0.0.1:19321
या:
python3 CVE-2026-9256-poc.py 127.0.0.1 19321
सफल ट्रिगर होने पर, विशिष्ट आउटपुट इस प्रकार होगा:
[+] Connection dropped during trigger request
[+] Worker is responding after trigger (HTTP 200)
round 1: worker likely crashed (keepalive connection dropped)
round 2: worker likely crashed (keepalive connection dropped)
...
[+] VULNERABILITY CONFIRMED - CVE-2026-9256 style crash behavior
[+] Impact confirmed: worker crash / denial of service
[*] RCE is not proven by this script
इस प्रकार का आउटपुट इंगित करता है कि रिमोट पक्ष पर अपेक्षाकृत स्थिर worker crash साक्ष्य देखा गया।
इस PoC की सुरक्षा सीमाएँ काफी स्पष्ट हैं:
पहला, यह केवल crash सत्यापन करता है, RCE शोषण नहीं।
दूसरा, यह हीप स्प्रे, ROP, ASLR बाइपास, शेलकोड या कमांड निष्पादन तर्क नहीं बनाता।
तीसरा, इसकी सफलता का मापदंड worker कनेक्शन ड्रॉप और सेवा पुनर्प्राप्ति है, न कि शेल प्राप्त करना या फ़ाइलें पढ़ना।
चौथा, यह स्थानीय पुनरुत्पादन, भेद्यता सत्यापन, IDS/IPS नियम निर्माण, और फिक्स से पहले और बाद में तुलनात्मक परीक्षण के लिए उपयुक्त है।
सुरक्षा को और बढ़ाने के लिए, निम्नलिखित प्रतिबंध जोड़े जा सकते हैं:
127.0.0.1, localhost, निजी पतों या स्पष्ट रूप से अधिकृत प्रयोगात्मक नेटवर्क खंडों तक पहुँच की अनुमति दें।--plus-count पैरामीटर जोड़ें, डिफ़ॉल्ट रूप से बड़ा पेलोड भेजने से बचें।--route पैरामीटर जोड़ें, उपयोगकर्ता को स्पष्ट रूप से ट्रिगर पथ निर्दिष्ट करने दें, न कि /api/ को हार्डकोड करें।--rounds पैरामीटर जोड़ें, keep-alive जांच संख्या को नियंत्रित करें।--print-request डीबग पैरामीटर जोड़ें, वास्तव में भेजे गए HTTP अनुरोध को प्रिंट करें, पैकेट कैप्चर परिणामों से तुलना करना आसान हो।PoC व्युत्पत्ति के दृष्टिकोण से, पता लगाने के नियम केवल /api/ पर टिके नहीं रह सकते, क्योंकि /api भेद्यता का निश्चित पथ नहीं है, बल्कि केवल वर्तमान प्रशिक्षण शृंखला का उदाहरण है। वास्तव में अधिक मूल्यवान पता लगाने के बिंदु होने चाहिए:
+, या +, &, %, ?, # आदि विशेष वर्णों का मिश्रण।यदि नियम केवल /api/++++ को हार्डकोड करता है, तो यह केवल वर्तमान PoC और वर्तमान प्रशिक्षण शृंखला को कवर करेगा; यदि अधिक सामान्य हमले ट्रैफ़िक को कवर करना है, तो विशेषताओं को "लंबा URI + बड़ी संख्या में विशेष वर्णों का घना दिखना + HTTP अनुरोध दिशा + NGINX rewrite जोखिम पथ" के आसपास निकाला जाना चाहिए।
साथ ही, चूंकि वैध व्यवसाय में भी लंबे URL या बड़ी संख्या में एन्कोडेड वर्ण हो सकते हैं, नियमों को लंबाई थ्रेशोल्ड, वर्ण घनत्व, पुनरावृत्ति संख्या और पथ संदर्भ के माध्यम से गलत-सकारात्मकता को कम करना चाहिए। एक अपेक्षाकृत स्थिर पता लगाने की दिशा है:
लंबा URI
+
बड़ी संख्या में विशेष वर्ण जो NGX_ESCAPE_ARGS द्वारा एस्केप और विस्तारित हो सकते हैं
+
अनुरोध दिशा to_server
+
NGINX rewrite संबंधित एक्सपोज़र सतह
न कि केवल पता लगाना:
/api/++++
Suricata / Snort नियमों के लिए, यदि केवल वर्तमान सार्वजनिक PoC को कवर करना है, तो सन्निहित + को एक मजबूत विशेषता के रूप में उपयोग किया जा सकता है; यदि विविधताओं को कवर करना है, तो विशेष वर्ण रेंज को PCRE में शामिल करना होगा, जैसे +, %, #, &, ? और अन्य वर्ण जो एस्केप और विस्तारित हो सकते हैं। लेकिन ऐसे नियमों में भी गलत-सकारात्मकता की अधिक संभावना होती है, उन्हें urilen, वर्ण पुनरावृत्ति थ्रेशोल्ड, पथ बाधाओं और NGINX संपत्ति रेंज के संयोजन में उपयोग करने की आवश्यकता होती है।
CVE-2026-9256 के PoC व्युत्पत्ति का मुख्य बिंदु एक निश्चित भेद्यता पथ की खोज करना नहीं है, बल्कि पहले भेद्यता ट्रिगर स्थितियों को समझना है: कमज़ोर rewrite कॉन्फ़िगरेशन, ओवरलैपिंग कैप्चर ग्रुप, कई कैप्चर वेरिएबल्स के संदर्भ, और विशेष URI इनपुट जो rewrite प्रसंस्करण परिणाम को असामान्य रूप से विस्तारित कर सकते हैं।
वर्तमान स्क्रिप्ट /api/ जोड़कर 4096 + चुनती है, क्योंकि यह पथ वर्तमान पुनरुत्पादन वातावरण में rewrite नियम को हिट कर सकता है, और बड़ी संख्या में + स्थिर रूप से लंबा इनपुट दबाव बना सकते हैं। स्क्रिप्ट RCE को लागू नहीं करती, बल्कि कनेक्शन डिस्कनेक्ट, सेवा पुनर्प्राप्ति और keep-alive कई राउंड ड्रॉप के माध्यम से worker crash साबित करती है।
साथ ही, + केवल सबसे स्थिर, सबसे आसानी से भेजा जाने वाला डिफ़ॉल्ट वर्ण है, यह एकमात्र संभावित ट्रिगर वर्ण नहीं है। जो भी वर्ण NGX_ESCAPE_ARGS मोड में %XX में विस्तारित होते हैं, उन्हें सिद्धांत विश्लेषण और सुरक्षा नियम विचार में शामिल किया जाना चाहिए। अधिक सटीक समझ यह होनी चाहिए: लंबे URI में घने रूप से एस्केप करने योग्य विस्तारित वर्ण, कमज़ोर rewrite कैप्चर और replacement प्रसंस्करण में प्रवेश करने के बाद, लंबाई गणना और वास्तविक लेखन के बीच असंगति को ट्रिगर करते हैं, जिसके परिणामस्वरूप अंततः worker crash या अधिक गंभीर मेमोरी विनाश होता है।