mj-bin/poc_cve-2026-45185nuclei-templates के लिए POC_CVE-2026-45185
यह भंडार एक सामान्य-उद्देश्य शोषण PoC भंडार नहीं है। यह projectdiscovery/nuclei-templates में योगदान के लिए इच्छित CVE-2026-45185 टेम्पलेट के व्यवहार को पुन: उत्पन्न करने और समीक्षा करने के लिए एक स्थानीय सत्यापन प्रयोगशाला है।
The nuclei code template is not a version-only detector.
It directly controls STARTTLS, BDAT, TLS close_notify, and a following
SMTP plaintext byte on the same TCP connection.
This sequence matches in the local vulnerable Exim 4.99.2 GnuTLS lab and does
not match in the patched Exim 4.99.3 GnuTLS lab under the same conditions.
वर्तमान सत्यापन संकेत एक दूरस्थ SMTP प्रतिक्रिया ऑरेकल है, न कि UAF लेखन का प्रत्यक्ष अवलोकन। आंतरिक रूप से, यह CVE एक use-after-free है जहां TLS शटडाउन के बाद मुक्त किए गए GnuTLS स्थानांतरण बफर में न्यूलाइन बाइट्स (\r/\n) लिखी जा सकती हैं। व्यवहार में, कोई क्लाइंट SMTP प्रतिक्रियाओं के माध्यम से उस मुक्त बफर लेखन को यथार्थवादी रूप से सीधे नहीं देख सकता है। इसलिए, यह README और टेम्पलेट bdat_ungetc -> tls_ungetc UAF लेखन या RCE को सीधे साबित करने का दावा नहीं करते हैं। इसके बजाय, टेम्पलेट एक प्राप्ति स्टैक/अवस्था पुनर्प्राप्ति अंतर का पता लगाता है जो ट्रिगर प्रवाह के दौरान दिखाई देता है।
भेद्यता तंत्र पर नज़र रखते हुए, मैंने देखा कि STARTTLS + BDAT हैंडलिंग के दौरान TLS close_notify के बाद, BDAT प्राप्ति स्टैक की निचली परत में अस्थायी tls_* फ़ंक्शन पॉइंटर रह सकते हैं, जिन्हें smtp_* फ़ंक्शन पॉइंटर्स में ठीक से बहाल नहीं किया जाता। यह स्थिति इस बात में दिखाई देती है कि सर्वर अगले SMTP कमांड को कैसे संभालता है। विभाजित BDAT पहली पूर्णता तक पहुँचने के बाद, उसी सत्र पर NOOP भेजने से असुरक्षित Exim 4.99.2 GnuTLS प्रयोगशाला 421 lost input connection लौटाती है, जबकि पैच किया गया Exim 4.99.3 GnuTLS प्रयोगशाला सामान्य रूप से 250 OK के साथ इसे संभालता है। इस स्पष्ट असुरक्षित/पैच किए गए प्रतिक्रिया अंतर का उपयोग स्थानीय, अधिकृत nuclei कोड टेम्पलेट के लिए मिलानकर्ता के रूप में किया जाता है।
गहन भेद्यता प्रवाह वॉकथ्रू के लिए, CVE-2026-45185-Technical-Analysis.md देखें।
| लक्ष्य | संस्करण | TLS बैकएंड | STARTTLS | CHUNKING | पोर्ट | अपेक्षित nuclei परिणाम |
|---|---|---|---|---|---|---|
| असुरक्षित | Exim 4.99.2 | GnuTLS | हाँ | हाँ | 127.0.0.1:2525 | मिलान |
| पैच किया गया | Exim 4.99.3 | GnuTLS | हाँ | हाँ | 127.0.0.1:2526 | कोई मिलान नहीं |
सामान्य SMTP लिफाफा प्राप्तकर्ता (RCPT TO):
Docker प्रयोगशाला का lab_rcpt ACL इस लिफाफा प्राप्तकर्ता को स्वीकार करता है। एक सामान्य SMTP लक्ष्य पर, यदि RCPT TO अस्वीकार कर दिया जाता है, तो अनुक्रम BDAT बॉडी पार्सर तक नहीं पहुँच सकता है, इसलिए टेम्पलेट को एक स्वीकृत प्राप्तकर्ता की आवश्यकता है।
यह मान BDAT बॉडी के अंदर To: हेडर से अलग है। RCPT TO प्राप्तकर्ता एक SMTP लिफाफा पता है जिसे सर्वर की प्राप्तकर्ता जाँचों को पार करना होगा। BDAT बॉडी में To: मान केवल संदेश हेडर टेक्स्ट है; इसे सर्वर द्वारा मेलबॉक्स के रूप में मौजूद या स्वीकार किए जाने की आवश्यकता नहीं है।
templates/CVE-2026-45185.yaml
टेम्पलेट नाम:
Exim 4.97-4.99.2 GnuTLS STARTTLS BDAT - Same-Session Response Check
टेम्पलेट को metadata.verified: true के साथ लिखा गया है और इसमें code और intrusive टैग हैं।
निम्नलिखित कमांड POC_2026_45185/ निर्देशिका से चलाएँ।
docker compose build
docker compose up -d
टेम्पलेट सिंटैक्स सत्यापित करें:
nuclei -duc -validate -code -t templates/CVE-2026-45185.yaml
स्थानीय कोड टेम्पलेट पर हस्ताक्षर करें, फिर चलाएँ:
nuclei -duc -code -t templates/CVE-2026-45185.yaml -sign
असुरक्षित प्रयोगशाला के विरुद्ध चलाएँ:
nuclei -code \
-t templates/CVE-2026-45185.yaml \
-u 127.0.0.1:2525 \
-var [email protected] \
-debug
अपेक्षित परिणाम:
CVE-2026-45185: vulnerable response oracle matched
पैच की गई प्रयोगशाला के विरुद्ध चलाएँ:
nuclei -code \
-t templates/CVE-2026-45185.yaml \
-u 127.0.0.1:2526 \
-var [email protected] \
-debug
अपेक्षित परिणाम:
no match
NO-MATCH: patched-like response: NOOP succeeded after split trigger
ध्यान दें कि nuclei code प्रोटोकॉल डिफ़ॉल्ट रूप से निष्पादित नहीं होता है, इसलिए -code आवश्यक है। Nuclei अहस्ताक्षरित code टेम्पलेट को भी अवरुद्ध करता है। यदि स्थानीय nuclei निजी कुंजी पासफ़्रेज़ से सुरक्षित है, तो हस्ताक्षर कमांड को एक इंटरैक्टिव टर्मिनल में चलाएँ और वह पासफ़्रेज़ दर्ज करें। प्रत्येक टेम्पलेट परिवर्तन के बाद पुन: हस्ताक्षर करें क्योंकि डाइजेस्ट टेम्पलेट सामग्री को कवर करता है।
ये स्क्रीनशॉट टेम्पलेट पर हस्ताक्षर करने के बाद स्थानीय प्रयोगशाला के प्रतिक्रिया-ऑरेकल परिणाम दिखाते हैं। ये ऊपर वर्णित समान-सत्र प्रतिक्रिया अंतर के लिए सत्यापन साक्ष्य हैं, न कि आंतरिक UAF लेखन का प्रत्यक्ष डीबगर या ASAN प्रमाण।
127.0.0.1:2525 पर असुरक्षित Exim 4.99.2 GnuTLS प्रयोगशाला:
127.0.0.1:2526 पर पैच किया गया Exim 4.99.3 GnuTLS प्रयोगशाला:
इस CVE का मूल कोई SMTP बैनर या संस्करण जाँच नहीं है। टेम्पलेट को उसी TCP कनेक्शन पर निम्नलिखित परिवहन-अवस्था संक्रमण बनाने की आवश्यकता है:
plaintext SMTP EHLO
-> STARTTLS
-> TLS handshake on the same TCP connection
-> TLS EHLO / MAIL FROM / RCPT TO / BDAT 70 LAST
-> first 69 bytes of the BDAT body as TLS application data
-> TLS close_notify without closing the TCP socket
-> final body byte as plaintext on the same TCP connection
-> same-session plaintext NOOP response check
YAML टेम्पलेट के अंदर Python कोड निश्चित मार्कर को तभी प्रिंट करता है जब निम्नलिखित सभी शर्तें पूरी होती हैं। nuclei मिलानकर्ता केवल उस मार्कर से मेल खाता है।
Exim identity is found
AND STARTTLS is advertised in plaintext EHLO
AND CHUNKING is advertised in plaintext EHLO
AND STARTTLS is accepted
AND CHUNKING is advertised in TLS EHLO
AND MAIL FROM is accepted
AND RCPT TO is accepted
AND the split close_notify BDAT reaches first completion
AND first completion contains "250 OK id="
AND the same-session plaintext NOOP response contains "421"
AND the same-session plaintext NOOP response contains "lost input connection"
टेम्पलेट निम्नलिखित में से किसी भी अकेले संकेत पर मेल नहीं खाता:
version-only
timeout-only
connection-drop-only
empty-response-only
recipient rejection
STARTTLS/CHUNKING advertisement only
दोनों प्रयोगशालाएँ पहली पूर्णता तक विभाजित BDAT संदेश को संसाधित करती हैं।
250- 70 byte chunk, total 72
250 OK id=...
अंतर तब दिखाई देता है जब अगला SMTP प्लेनटेक्स्ट कमांड उसी SMTP सत्र पर भेजा जाता है।
असुरक्षित 4.99.2:
NOOP -> 421 exim-lab.local lost input connection
QUIT -> 421 exim-lab.local lost input connection
RSET -> 421 exim-lab.local lost input connection
पैच किया गया 4.99.3:
NOOP -> 250 OK
QUIT -> 221 exim-lab.local closing connection
RSET -> 250 Reset OK
व्याख्या:
अवलोकन:
दोनों प्रयोगशालाएँ विभाजित BDAT संदेश पूर्णता तक पहुँचती हैं।
केवल असुरक्षित प्रयोगशाला उसी सत्र में अगले प्लेनटेक्स्ट SMTP कमांड लूप पर साफ-साफ वापस नहीं आती।
साक्ष्य:
असुरक्षित अनुवर्ती प्रतिक्रिया 421 lost input connection है।
पैच किए गए अनुवर्ती प्रतिक्रिया 250 OK या 221 closing connection है।
अनुमान:
यह अंतर STARTTLS close_notify के बाद प्राप्ति स्टैक/अवस्था पुनर्प्राप्ति अंतर के अनुरूप है।
टेम्पलेट BDAT बॉडी के रूप में निम्नलिखित 70-बाइट संदेश का उपयोग करता है।
From: [email protected]\r\n
To: [email protected]\r\n
Subject: poc\r\n
\r\n
body
SMTP लिफाफा प्राप्तकर्ता टेम्पलेट वेरिएबल recipient के माध्यम से अलग से पारित किया जाता है। बॉडी में To: हेडर टेक्स्ट है और SMTP RCPT TO के स्वीकृत होने से संबंधित नहीं है, इसलिए इसे सर्वर द्वारा मौजूद या स्वीकार किए जाने की आवश्यकता नहीं है।
विभाजित आकार:
BDAT 70 LAST
TLS body: first 69 bytes, ending with "bod"
TLS event: close_notify
Plaintext: final byte "y"
Follow-up: NOOP
आप मैन्युअल रूप से सत्यापित कर सकते हैं कि दोनों प्रयोगशालाएँ Exim, STARTTLS और CHUNKING का विज्ञापन करती हैं।
printf 'EHLO lab-client.local\r\nQUIT\r\n' | nc -w 3 127.0.0.1 2525
printf 'EHLO lab-client.local\r\nQUIT\r\n' | nc -w 3 127.0.0.1 2526
अपेक्षित संकेत:
Exim
STARTTLS
CHUNKING
आप सामान्य STARTTLS पथ भी जाँच सकते हैं:
openssl s_client -starttls smtp -connect 127.0.0.1:2525 -crlf
openssl s_client -starttls smtp -connect 127.0.0.1:2526 -crlf
debugging/ और notes/source-walkthrough-progress.md में ट्रैक किया जाता है।POC_2026_45185/
compose.yaml
images/ local nuclei validation screenshots
vulnerable/ Exim 4.99.2 + GnuTLS debug build
patched/ Exim 4.99.3 + GnuTLS debug build
nuclei-templates/ submodule: local nuclei template workspace