
CVE-2026-23918 Apache http2 RCE के लिए पहचान नियम - श्रेय: stringa.ai, isec.pl
प्रकाशित: 2026-05-04
CVSSv3: 8.8 (उच्च)
प्रकार: दूरस्थ कोड निष्पादन / सेवा अस्वीकार (दोहरी-मुक्त मेमोरी भ्रष्टाचार)
घटक: Apache HTTP सर्वर mod_http2 (h2_mplx.c स्ट्रीम सफाई पथ)
प्रभावित: Apache HTTP सर्वर 2.4.66 HTTP/2 सक्षम और मल्टी-थ्रेडेड MPM के साथ
संदर्भ:
CVE-2026-23918 Apache HTTP सर्वर 2.4.66 के HTTP/2 प्रोटोकॉल कार्यान्वयन में एक दोहरी-मुक्त मेमोरी भ्रष्टाचार भेद्यता है, जो केवल mod_http2 मॉड्यूल के h2_mplx.c में स्ट्रीम सफाई पथ को प्रभावित करती है। यह एक अप्रमाणित दूरस्थ हमलावर को एकल TCP कनेक्शन और दो HTTP/2 फ्रेम के साथ Apache कार्यकर्ता प्रक्रियाओं को क्रैश करने (सेवा अस्वीकार) की अनुमति देता है। Debian-व्युत्पन्न सिस्टम और आधिकारिक Apache Docker इमेज पर मौजूद शर्तों के तहत, इस दोहरी-मुक्त को पूर्ण दूरस्थ कोड निष्पादन में आकार दिया जा सकता है।
DoS शोषण की पुष्टि वास्तविक दुनिया में हो चुकी है। HTTP/2 एंडपॉइंट को लक्षित करने वाले बड़े पैमाने पर इंटरनेट स्कैन देखे गए हैं। RCE शोषण को नियंत्रित वातावरण में व्यवहार्य साबित किया गया है, हालांकि इस समय RCE के लिए व्यापक सार्वजनिक शोषण का कोई सबूत नहीं है।
MPM prefork प्रभावित नहीं है — भेद्यता के लिए मल्टी-थ्रेडेड MPM कॉन्फ़िगरेशन (worker, event, या समान) की आवश्यकता है। CVE-2026-23918 केवल Apache HTTP सर्वर संस्करण 2.4.66 को प्रभावित करता है।
Attacker opens HTTP/2 connection to Apache 2.4.66 (mod_http2 loaded, multi-threaded MPM) └─ Sends HTTP/2 HEADERS frame on stream N (opens the stream) └─ Immediately sends RST_STREAM on stream N (non-zero error code) └─ Sent BEFORE the multiplexer has registered the stream
Two nghttp2 callbacks fire in sequence: ├─ on_frame_recv_cb (RST received) → calls h2_mplx_c1_client_rst → m_stream_cleanup └─ on_stream_close_cb (stream closed) → calls h2_mplx_c1_client_rst → m_stream_cleanup
Result: same h2_stream pointer pushed onto spurge[] cleanup array TWICE
c1_purge_streams() iterates spurge[] and calls h2_stream_destroy() on each entry: ├─ First call: valid — frees the stream └─ Second call: DOUBLE-FREE — operates on already-freed memory → heap corruption
DoS path (trivial, in the wild): └─ Heap corruption → SIGABRT in worker process → worker dies → service disruption
RCE path (requires mmap allocator — default on Debian/Ubuntu and official Docker): └─ Attacker places fake h2_stream struct at freed virtual address via mmap reuse └─ Points pool cleanup function pointer to system() └─ Uses Apache scoreboard shared memory (fixed address, ASLR-resistant) as payload container └─ c1_purge_streams() executes system() with attacker-controlled argument → RCE
> **Key asymmetry:** DoS पथ के लिए कोई हीप मैनिपुलेशन कौशल की आवश्यकता नहीं है और इसका सक्रिय रूप से शोषण किया जा रहा है। RCE पथ तकनीकी रूप से मांग वाला है लेकिन प्रयोगशाला स्थितियों में प्रदर्शित किया गया है और स्कोरबोर्ड के ASLR-प्रतिरोधी निश्चित पते को देखते हुए निकट भविष्य में लगभग निश्चित रूप से हथियारबंद किया जाएगा।
---
## डिटेक्शन आर्किटेक्चर
> यह खंड बताता है कि यहां डिटेक्शन टूलिंग एक सामान्य स्थानीय विशेषाधिकार वृद्धि पैकेज से काफी भिन्न क्यों है।
Copy Fail (CVE-2026-31431) एक **होस्ट-साइड, पोस्ट-एक्सेस** कमज़ोरी थी। हमलावर को सिस्टम पर मौजूदा उपस्थिति की आवश्यकता थी। डिटेक्शन मुख्य रूप से syscall लेयर (auditd, Wazuh) पर रहता था, जिसमें डिस्क पर PoC स्क्रिप्ट के लिए YARA स्कैनिंग होती थी।
CVE-2026-23918 एक **नेटवर्क-साइड, प्री-एक्सेस** कमज़ोरी है। एक्सप्लॉइट वायर पर HTTP/2 प्रोटोकॉल फ्रेम के रूप में आता है, इससे पहले कि कोई एप्लिकेशन कोड चले। यह डिटेक्शन स्टैक को महत्वपूर्ण रूप से बदल देता है:
| Layer | Copy Fail (LPE) | CVE-2026-23918 (RCE) |
|---|---|---|
| **Primary detection** | Auditd syscall नियम | Suricata नेटवर्क नियम |
| **WAF (ModSecurity)** | सीमित — एक्सप्लॉइट नहीं देख सकता | प्रासंगिक — एनॉमली + पोस्ट-एक्सप्लॉइट |
| **Auditd** | कोर डिटेक्शन | परिणाम डिटेक्शन (क्रैश, पोस्ट-एक्सप्लॉइट) |
| **YARA** | PoC स्क्रिप्ट के लिए स्कैन | वेब शेल (पोस्ट-एक्सप्लॉइट आर्टिफैक्ट) के लिए स्कैन |
| **Network IDS** | लागू नहीं | प्रथम श्रेणी डिटेक्शन लेयर |
| **TLS inspection** | N/A | पूर्ण Suricata कवरेज के लिए आवश्यक |
अंगूठे का नियम: नेटवर्क-स्तरीय RCE के लिए, बाहर से अंदर की ओर काम करें (नेटवर्क → WAF → होस्ट)। स्थानीय विशेषाधिकार वृद्धि के लिए, होस्ट से बाहर की ओर काम करें।
---
## डिटेक्शन सीमाएँ
> **कोई भी नियम तैनात करने से पहले इसे पढ़ें।**
**1. TLS HTTP/2 दृश्यता को समाप्त करता है।**
अधिकांश उत्पादन Apache तैनातियाँ HTTPS प्रदान करती हैं। TLS डिक्रिप्शन कॉन्फ़िगर किए बिना Suricata एन्क्रिप्टेड HTTP/2 फ्रेम की सामग्री का निरीक्षण नहीं कर सकता। यदि आपकी Suricata तैनाती के पास TLS सत्र कुंजियों या डिक्रिप्शन मिरर तक पहुँच नहीं है, तो नीचे दिए गए नेटवर्क-स्तरीय नियम केवल पकड़ेंगे:
- क्लियरटेक्स्ट HTTP/2 (h2c) — उत्पादन में असामान्य लेकिन आंतरिक वातावरण में मौजूद
- TCP कनेक्शन व्यवहार का नेटवर्क सिग्नेचर (कनेक्शन गणना, TCP लेयर पर RST पैटर्न)
HTTPS तैनातियों के लिए, `tls-decrypt` सेटिंग और सत्र कुंजी लॉगिंग के माध्यम से Suricata की TLS डिक्रिप्शन सक्षम करें, या इसके बजाय WAF (ModSecurity/Coraza) और होस्ट-आधारित (auditd/Wazuh) लेयर पर भरोसा करें।
**2. ModSecurity एक्सप्लॉइट ट्रिगर को ब्लॉक नहीं कर सकता।**
डबल-फ्री HTTP/2 फ्रेम पार्सर के अंदर होता है, इससे पहले कि एक पूर्ण HTTP अनुरोध इकट्ठा हो और ModSecurity को पास किया जाए। WAF अनुरोध को केवल फ्रेम पार्सिंग पूर्ण होने के बाद देखता है — उस बिंदु पर नुकसान पहले ही हो चुका हो सकता है। इस पैकेज में ModSecurity का उपयोग एनॉमली डिटेक्शन, रेट लिमिटिंग और पोस्ट-एक्सप्लॉइटेशन डिटेक्शन के लिए किया जाता है, न कि ट्रिगर के ब्लॉकर के रूप में।
**3. MPM prefork अप्रभावित है।**
यदि आपकी Apache तैनाती `mpm_prefork_module` (एकल-थ्रेडेड) का उपयोग करती है, तो यह कमज़ोरी लागू नहीं होती। बग केवल मल्टी-थ्रेडेड MPMs (`mpm_event_module` या `mpm_worker_module`) में प्रकट होता है। prefork सर्वरों पर गलत सकारात्मक उत्पन्न करने वाले नियमों को तैनात करने से पहले `apachectl -V | grep MPM` से जाँच करें।
**4. RCE के लिए mmap आवंटक की आवश्यकता है।**
RCE पथ (DoS पथ नहीं) के लिए APR के mmap आवंटक की आवश्यकता है, जो Debian-व्युत्पन्न वितरणों और आधिकारिक Apache Docker इमेज पर डिफ़ॉल्ट है। jemalloc या system malloc का उपयोग करने वाली RHEL/CentOS-आधारित तैनातियों में RCE जोखिम कम होता है, लेकिन वे अभी भी DoS के लिए पूरी तरह से कमजोर हैं।
**5. अभी तक कोई स्थिर पोस्ट-एक्सप्लॉइटेशन IoCs नहीं।**
इस लेखन के समय तक पोस्ट-एक्सप्लॉइटेशन गतिविधि के लिए कोई विक्रेता-प्रकाशित IoCs मौजूद नहीं हैं। पोस्ट-एक्सप्लॉइटेशन व्यवहार को लक्षित करने वाले YARA नियम और auditd नियम सामान्य वेब शेल और विशेषाधिकार वृद्धि पैटर्न पर आधारित हैं — वे सामान्य परिणामों को पकड़ लेंगे लेकिन एक परिष्कृत, विशेष पेलोड को नहीं।
---
## तत्काल शमन