CVE-2026-56848

NVD विवरण

Node.js HTTP/2 हैंडलिंग में एक दोष nghttp2_session_mem_send() को nghttp2_session_mem_recv() के निष्पादन के दौरान पुनः-प्रवेशी (re-entrantly) रूप से कॉल करने की अनुमति देता है, जिसके परिणामस्वरूप heap-use-after-free होता है।

यह भेद्यता Node.js 26.x, 24.x और 22.x को प्रभावित करती है।

(नोट: विवरण में उल्लिखित संस्करण केवल अपस्ट्रीम nodejs पैकेज पर लागू होते हैं, न कि Alpine द्वारा वितरित nodejs पैकेज पर।)

रिलीज़ लाइन	प्रभावित	सुरक्षित
22.x (LTS)	≤ 22.23.1	22.23.2
24.x (LTS)	≤ 24.18.0	24.18.1
26.x	≤ 26.5.0	26.5.1

• गंभीरता: उच्च (CVSS 7.5, AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H — रिमोट, बिना प्रमाणीकरण के, हीप भ्रष्टाचार के माध्यम से DoS)
• रिपोर्टकर्ता: hahahkim (HackerOne #3833629)
• द्वारा सुधारित: Matteo Collina (mcollina)
• फिक्स कमिट (v22): daa6d25e3dce — "http2: defer rst stream while in scope" (nodejs-private/node-private#921)
• खुलासा: Node.js सुरक्षा रिलीज़, 2026-07-29

मूल कारण

Http2Stream::SubmitRstStream() src/node_http2.cc में RST_STREAM को कतारबद्ध करने से पहले लंबित आउटबाउंड डेटा को शुद्ध (purge) करने के लिए बाध्य करता है:```cpp void Http2Stream::SubmitRstStream(const uint32_t code) { CHECK(!this->is_destroyed()); code_ = code;

// (NGHTTP2_CANCEL is deferred — fix for an older double-free) if (session_->is_in_scope() && is_stream_cancel(code)) { session_->AddPendingRstStream(id_); return; }

// If possible, force a purge of any currently pending data here to make // sure it is sent before closing the stream. ... if (session_->SendPendingData() != 0) { // ← RE-ENTRANT mem_send() session_->AddPendingRstStream(id_); return; }

FlushRstStream(); }

`SendPendingData()` `nghttp2_session_mem_send()` को कॉल करता है ([node_http2.cc:1970](https://github.com/nodejs/node/blob/v22.23.1/src/node_http2.cc#L1970))। इसका एकमात्र re-entrancy गार्ड `is_sending()` है, जो *send-during-send* (पहले से प्रगति पर एक लेखन) से सुरक्षा करता है — **send-during-receive से नहीं**। जब `SubmitRstStream()` किसी `nghttp2_session_mem_recv()` कॉलबैक श्रृंखला के अंदर ("in scope") चलता है, तो purge `mem_send()` को पुनः-प्रवेशी (re-entrantly) रूप से चलाता है।

पुनः-प्रवेशी `mem_send()` उन फ्रेमों को flush करता है जिनकी send-पक्षीय प्रक्रिया स्ट्रीमों को तोड़ देती है (`nghttp2_session_close_stream_on_goaway()` → `on_stream_close` → `Http2Stream::Destroy()` → C++ `Http2Stream` की मुक्ति)। मुक्त की गई स्ट्रीम अभी भी प्रगति पर मौजूद receive ऑपरेशन द्वारा संदर्भित है: `SubmitRstStream()` स्वयं मुक्त किए गए `this` पर निष्पादित होता रहता है (इसका अंतिम `FlushRstStream()` `is_destroyed()` पढ़ता है), और बाहरी `mem_recv()` बंद स्ट्रीम के लिए frame/header स्थिति पर चलता रहता है → **heap-use-after-free**।

### ट्रिगर श्रृंखला (सभी एक ही `nghttp2_session_mem_recv()` कॉल के भीतर)

1. हमलावर एक ही TCP सेगमेंट में `GOAWAY(lastStreamID=0, NO_ERROR)` के तुरंत बाद नई स्ट्रीमों (3, 5, 7, …) के लिए `HEADERS` फ्रेम भेजता है।
2. सर्वर का `mem_recv()` GOAWAY को संसाधित करता है → JS `session.close()` → `session.closed = true` हो जाता है और एक आउटबाउंड GOAWAY **सबमिट किया जाता है लेकिन अभी तक भेजा नहीं गया है**।
3. nghttp2 नई आने वाली स्ट्रीमों को तभी अस्वीकार करता है जब GOAWAY वास्तव में *भेजा* गया हो (`session_allow_incoming_new_stream()` `TERM_ON_SEND | SENT` की जाँच करता है, `SUBMITTED` की नहीं), इसलिए `HEADERS(3)` अभी भी स्वीकार किया जाता है।
4. JS `onSessionHeaders()` बंद सत्र पर एक नई स्ट्रीम देखता है और उसे अस्वीकार करता है: `handle.rstStream(NGHTTP2_REFUSED_STREAM)` (lib/internal/http2/core.js)।
5. C++ `SubmitRstStream(NGHTTP2_REFUSED_STREAM)` in scope (यानी `mem_recv` के अंदर) चलता है, `REFUSED_STREAM ≠ CANCEL` → `SendPendingData()` तक पहुँचता है → **re-entrant `nghttp2_session_mem_send()`**।
6. re-entrant send आउटबाउंड GOAWAY को flush करता है; nghttp2 की send-पक्षीय GOAWAY प्रक्रिया id > 1 वाली आने वाली स्ट्रीमों को बंद कर देती है (`session_close_stream_on_goaway(..., NGHTTP2_REFUSED_STREAM)`), जिससे `on_stream_close` सक्रिय होता है → `Http2Stream::Destroy()` स्ट्रीम 3 के लिए C++ स्ट्रीम ऑब्जेक्ट को मुक्त करता है।
7. निष्पादन मुक्त किए गए ऑब्जेक्ट पर `SubmitRstStream()` में वापस unwinds होता है (`FlushRstStream()`), और बाहरी `mem_recv()` दूषित session/stream स्थिति पर फिर से शुरू होता है → UAF।

एक कमजोर सर्वर पर `NODE_DEBUG_NATIVE=http2` से प्राप्त साक्ष्य (एक 86-बाइट रीड):```
receiving 86 bytes, offset 0
complete frame received: type: 7          ← GOAWAY
submitting goaway                          ← GOAWAY submitted, NOT yet sent
beginning headers for stream 3             ← still accepted (only SUBMITTED)
handle headers frame for stream 3          ← JS: session.closed → refuse
sending rst_stream with code 7             ← SubmitRstStream(REFUSED_STREAM), in scope
sending pending data                       ← RE-ENTRANT mem_send()
stream 3 closed with code: 7               ← GOAWAY send closes stream 3
Removing stream: 3 / destroying stream     ← Http2Stream freed mid-recv

व्यवहारिक हस्ताक्षर

वायर-स्तर का आउटपुट कमजोर और पैच किए गए बिल्ड दोनों पर समान होता है (दोनों ही अंततः केवल बाहरी GOAWAY भेजते हैं — कमजोर बिल्ड पर RST पहले से बंद स्ट्रीम के विरुद्ध सबमिट किया जाता है, जबकि पैच किए गए बिल्ड पर nghttp2 GOAWAY पहले भेजे जाने के बाद क्यू में लगे RST को हटा देता है)। अंतर आंतरिक है, जो NODE_DEBUG_NATIVE=http2 के साथ दिखाई देता है:

• कमजोर: sending pending data बीच में sending rst_stream with code 7 और stream 3 closed with code: 7 के बीच प्रकट होता है — री-एंट्रेंट mem_send() रिसीव के मध्य में चलता है और स्ट्रीम 3 को बंद/नष्ट कर देता है जबकि mem_recv() अभी भी प्रगति पर है (ASan के अंतर्गत क्रैश)।
• पैच किया गया: उनके बीच कोई sending pending data नहीं होता — RST केवल क्यू में लगाया जाता है; स्ट्रीम 3 केवल सामान्य रिसीव-पश्चात फ्लश के दौरान बंद होती है।

PoC```

server.js # minimal http2.createServer() target (no handler needed) exploit.js # raw-socket HTTP/2 client that drives the trigger

### त्वरित रन```bash
# Terminal 1: the target (any vulnerable node: 22.23.1 / 24.18.0 / 26.5.0 or older in their lines)
node server.js 8000                       # NODE_BIN=/path/to/node for a specific binary

# Terminal 2: the attack — a crash shows up in terminal 1 (ASan report / segfault)
node exploit.js --port 8000 --iterations 200

./bin/node (नीचे उपयोग किया गया स्थानीय ASan बिल्ड) git में ट्रैक नहीं किया जाता है — इसे "ASan-इंस्ट्रूमेंटेड संवेदनशील Node.js बनाना" के निर्देशों के साथ बनाएं, या Docker मार्ग का उपयोग करें।

एक्सप्लॉइट प्रति-कनेक्शन स्थिति रिपोर्ट करता है; पहले कनेक्शन के बाद SKIPPED (no handshake) का अर्थ है कि लक्ष्य हमले से पहले ही नष्ट हो चुका है।

Docker

Dockerfile एक कंटेनर के अंदर ASan के साथ एक संवेदनशील v22.23.1 लक्ष्य बनाता है (किसी स्थानीय टूलचेन की आवश्यकता नहीं — केवल Docker डेमन):```bash docker build -t cve-2026-56848 . docker run --rm -p 8000:8000 --name cve-target cve-2026-56848

from the host, in another terminal:

you could reuse ./bin/node

node exploit.js --port 8000 --iterations 10