An unauthenticated HTTP/2 client can exhaust Node.js server memory because inbound DATA queued on an undrained stream is charged to no session budget. Each inbound DATA frame creates one JavaScript Buffer view in the receiving stream's readable queue, but nothing charges that queue to current_session_memory_: the socket read buffer is accounted only during parsing and released immediately, so whatever stays queued is accounted to nothing. A peer that fills a stream's receive window with one-byte DATA frames pays about 10 wire bytes per frame while the server retains about 114 bytes per frame, so a single stream on one connection can retain hundreds of megabytes from tens of megabytes sent. maxSessionMemory neither bounds the growth nor refuses new streams, because Http2Session::CanAddStream gates admission on the same counter that never sees the queue. This vulnerability affects Node.js 26.x and 24.x.

There are packages installed that are affected by multiple vulnerabilities referenced in the following CVEs:

  - A client certificate authentication bypass in Node.js TLS lets a client change the servername during TLS
    1.2 renegotiation to reach endpoints it was not authorized for. On a server that applies different client-
    certificate policies per hostname, for example stricter admin-only client-cert auth on one host and
    ordinary client-cert auth on another, a client that authenticates for a permitted host can renegotiate the
    TLS 1.2 connection under a different servername and carry its existing authentication to the protected
    host, bypassing the stricter policy. This vulnerability affects Node.js 26.x, 24.x, and 22.x.
    (CVE-2026-123872)

  - A reachable assertion in Node.js HTTP/2 session teardown lets any unauthenticated client abort the server,
    over both TLS and cleartext. A client can arrange for an Http2Stream that still holds nghttp2-allocated
    header buffers to outlive its session: the stream is removed from the session's stream set but never
    detached, so when ~Http2Session() runs the memory accounting is nonzero and the
    CHECK_EQ(current_nghttp2_memory_, 0) assertion fails, terminating the process. The trigger needs only a
    default http2 server whose handler responds before the request body has ended, which is typical. It is a
    variant of CVE-2024-27983 that the earlier fix did not cover, because that fix only detached streams still
    tracked in the session. This vulnerability affects Node.js 26.x (since 26.9.0) and 24.x (since 24.22.0).
    (CVE-2026-123863)

  - A NULL pointer dereference in Node.js HTTP/2 lets an unauthenticated client crash the server, over both
    TLS and cleartext, by cancelling file downloads. When the server serves a file with
    stream.respondWithFile() or stream.respondWithFD() and the client cancels the request, a StreamPipe used
    for the transfer is torn down in an order that leaves a NULL pointer which is then dereferenced, aborting
    the process. No crafted frames are needed, and a handful of cancelled requests against a default file-
    serving handler is enough. This vulnerability affects Node.js 26.x, 24.x, and 22.x. (CVE-2026-123875)

  - An unauthenticated HTTP/2 client can permanently leak Node.js server memory and file descriptors. If a
    peer triggers a protocol error, for example an oversized frame header, while the session is already
    shutting down, nghttp2 tears the session down internally but Node.js never notices, leaving a dangling
    session: the socket stays in CLOSE_WAIT and all of Node.js's HTTP/2 state for that connection is held in
    memory indefinitely, with no further cost to the attacker. The attacker can start the shutdown remotely by
    sending GOAWAY(NO_ERROR), so it is reliable against default HTTP/2 servers. It is an incomplete-fix case
    of CVE-2026-48937: that fix detected nghttp2 internal terminations by watching for GOAWAY sent while not
    shutting down, but missed terminations that arrive while the session is already shutting down. This
    vulnerability affects Node.js 26.x, 24.x, and 22.x. (CVE-2026-123865)

  - A one-byte heap buffer overflow in Node.js HTTP/2 Alt-Svc handling lets a remote, unauthenticated attacker
    corrupt process memory. When an application passes an attacker-controlled value such as a request's
    :authority header to Http2Session.altsvc(), the AltSvc implementation in src/node_http2.cc allocates a
    buffer sized to the origin length and then writes it with a null terminator, placing one byte past the end
    of the allocation. A single request carrying a long but syntactically valid :authority triggers the out-
    of-bounds write, which aborts the process and serves as a remote heap-corruption primitive. This
    vulnerability affects Node.js 26.x and 24.x. (CVE-2026-123828)

The Rocky Linux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1794442042 advisory.

  - A certificate validation bypass in Node.js https.Agent lets a cached TLS session authenticated under one     CA policy be reused by a later request with a stricter policy. https.Agent.prototype.getName() assigns the     same Agent and session-cache key to a request that omits ca and one that explicitly supplies ca: [],     because an omitted value appends nothing to the key while an empty array stringifies to an empty string.
    The two policies differ: omitting ca uses the default trust store, while supplying ca replaces it. Since     they share a key, a TLS session authenticated under the broader default policy is handed to a new     connection made under the later ca: [] policy, and TLS 1.3 session resumption carries the earlier     authentication forward, so the second request reports authorized === true and transmits confidential data     to a server its own CA policy would reject on a fresh connection. This vulnerability affects Node.js 26.x,     24.x, and 22.x. (CVE-2026-123877)

  - An unauthenticated HTTP/2 client can exhaust Node.js server memory because inbound DATA queued on an     undrained stream is charged to no session budget. Each inbound DATA frame creates one JavaScript Buffer     view in the receiving stream's readable queue, but nothing charges that queue to current_session_memory_:
    the socket read buffer is accounted only during parsing and released immediately, so whatever stays queued     is accounted to nothing. A peer that fills a stream's receive window with one-byte DATA frames pays about     10 wire bytes per frame while the server retains about 114 bytes per frame, so a single stream on one     connection can retain hundreds of megabytes from tens of megabytes sent. maxSessionMemory neither bounds     the growth nor refuses new streams, because Http2Session::CanAddStream gates admission on the same counter     that never sees the queue. This vulnerability affects Node.js 26.x and 24.x. (CVE-2026-123868)

  - A per-host mutual-TLS authorization bypass in Node.js lets a client authorized for the default hostname     reach a protected hostname it is not authorized for. When a TLS server assigns a hostname a different     client-certificate CA with server.addContext(host, { ca: protectedCA }) but no server certificate in that     SNI context, the per-host client CA is never installed and the handshake falls back to the default client     CA. In src/crypto/crypto_tls.cc, CertCbDone installs the SNI context's CA only when setSniContext     succeeds, but setSniContext returns false for a context with no server certificate, so a CA-only SNI     context silently keeps the default CA. A client holding a certificate trusted by the default CA, but not     the protected CA, can therefore complete mTLS to the protected hostname and read its response even with     requestCert and rejectUnauthorized enabled, while a client certified by the protected CA is rejected. This     vulnerability affects Node.js 26.x, 24.x, and 22.x. (CVE-2026-123867)

  - A client certificate authentication bypass in Node.js TLS lets a client change the servername during TLS     1.2 renegotiation to reach endpoints it was not authorized for. On a server that applies different client-     certificate policies per hostname, for example stricter admin-only client-cert auth on one host and     ordinary client-cert auth on another, a client that authenticates for a permitted host can renegotiate the     TLS 1.2 connection under a different servername and carry its existing authentication to the protected     host, bypassing the stricter policy. This vulnerability affects Node.js 26.x, 24.x, and 22.x.
    (CVE-2026-123872)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The AlmaLinux 9.2 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.2:CLSA-2026:1794441621 advisory.

  - A certificate validation bypass in Node.js https.Agent lets a cached TLS session authenticated under one     CA policy be reused by a later request with a stricter policy. https.Agent.prototype.getName() assigns the     same Agent and session-cache key to a request that omits ca and one that explicitly supplies ca: [],     because an omitted value appends nothing to the key while an empty array stringifies to an empty string.
    The two policies differ: omitting ca uses the default trust store, while supplying ca replaces it. Since     they share a key, a TLS session authenticated under the broader default policy is handed to a new     connection made under the later ca: [] policy, and TLS 1.3 session resumption carries the earlier     authentication forward, so the second request reports authorized === true and transmits confidential data     to a server its own CA policy would reject on a fresh connection. This vulnerability affects Node.js 26.x,     24.x, and 22.x. (CVE-2026-123877)

  - An unauthenticated HTTP/2 client can exhaust Node.js server memory because inbound DATA queued on an     undrained stream is charged to no session budget. Each inbound DATA frame creates one JavaScript Buffer     view in the receiving stream's readable queue, but nothing charges that queue to current_session_memory_:
    the socket read buffer is accounted only during parsing and released immediately, so whatever stays queued     is accounted to nothing. A peer that fills a stream's receive window with one-byte DATA frames pays about     10 wire bytes per frame while the server retains about 114 bytes per frame, so a single stream on one     connection can retain hundreds of megabytes from tens of megabytes sent. maxSessionMemory neither bounds     the growth nor refuses new streams, because Http2Session::CanAddStream gates admission on the same counter     that never sees the queue. This vulnerability affects Node.js 26.x and 24.x. (CVE-2026-123868)

  - A per-host mutual-TLS authorization bypass in Node.js lets a client authorized for the default hostname     reach a protected hostname it is not authorized for. When a TLS server assigns a hostname a different     client-certificate CA with server.addContext(host, { ca: protectedCA }) but no server certificate in that     SNI context, the per-host client CA is never installed and the handshake falls back to the default client     CA. In src/crypto/crypto_tls.cc, CertCbDone installs the SNI context's CA only when setSniContext     succeeds, but setSniContext returns false for a context with no server certificate, so a CA-only SNI     context silently keeps the default CA. A client holding a certificate trusted by the default CA, but not     the protected CA, can therefore complete mTLS to the protected hostname and read its response even with     requestCert and rejectUnauthorized enabled, while a client certified by the protected CA is rejected. This     vulnerability affects Node.js 26.x, 24.x, and 22.x. (CVE-2026-123867)

  - A client certificate authentication bypass in Node.js TLS lets a client change the servername during TLS     1.2 renegotiation to reach endpoints it was not authorized for. On a server that applies different client-     certificate policies per hostname, for example stricter admin-only client-cert auth on one host and     ordinary client-cert auth on another, a client that authenticates for a permitted host can renegotiate the     TLS 1.2 connection under a different servername and carry its existing authentication to the protected     host, bypassing the stricter policy. This vulnerability affects Node.js 26.x, 24.x, and 22.x.
    (CVE-2026-123872)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

The AlmaLinux 9.6 host has packages installed that are affected by multiple vulnerabilities as referenced in the TuxCare ALMALINUX9.6:CLSA-2026:1794442042 advisory.

  - A certificate validation bypass in Node.js https.Agent lets a cached TLS session authenticated under one     CA policy be reused by a later request with a stricter policy. https.Agent.prototype.getName() assigns the     same Agent and session-cache key to a request that omits ca and one that explicitly supplies ca: [],     because an omitted value appends nothing to the key while an empty array stringifies to an empty string.
    The two policies differ: omitting ca uses the default trust store, while supplying ca replaces it. Since     they share a key, a TLS session authenticated under the broader default policy is handed to a new     connection made under the later ca: [] policy, and TLS 1.3 session resumption carries the earlier     authentication forward, so the second request reports authorized === true and transmits confidential data     to a server its own CA policy would reject on a fresh connection. This vulnerability affects Node.js 26.x,     24.x, and 22.x. (CVE-2026-123877)

  - An unauthenticated HTTP/2 client can exhaust Node.js server memory because inbound DATA queued on an     undrained stream is charged to no session budget. Each inbound DATA frame creates one JavaScript Buffer     view in the receiving stream's readable queue, but nothing charges that queue to current_session_memory_:
    the socket read buffer is accounted only during parsing and released immediately, so whatever stays queued     is accounted to nothing. A peer that fills a stream's receive window with one-byte DATA frames pays about     10 wire bytes per frame while the server retains about 114 bytes per frame, so a single stream on one     connection can retain hundreds of megabytes from tens of megabytes sent. maxSessionMemory neither bounds     the growth nor refuses new streams, because Http2Session::CanAddStream gates admission on the same counter     that never sees the queue. This vulnerability affects Node.js 26.x and 24.x. (CVE-2026-123868)

  - A per-host mutual-TLS authorization bypass in Node.js lets a client authorized for the default hostname     reach a protected hostname it is not authorized for. When a TLS server assigns a hostname a different     client-certificate CA with server.addContext(host, { ca: protectedCA }) but no server certificate in that     SNI context, the per-host client CA is never installed and the handshake falls back to the default client     CA. In src/crypto/crypto_tls.cc, CertCbDone installs the SNI context's CA only when setSniContext     succeeds, but setSniContext returns false for a context with no server certificate, so a CA-only SNI     context silently keeps the default CA. A client holding a certificate trusted by the default CA, but not     the protected CA, can therefore complete mTLS to the protected hostname and read its response even with     requestCert and rejectUnauthorized enabled, while a client certified by the protected CA is rejected. This     vulnerability affects Node.js 26.x, 24.x, and 22.x. (CVE-2026-123867)

  - A client certificate authentication bypass in Node.js TLS lets a client change the servername during TLS     1.2 renegotiation to reach endpoints it was not authorized for. On a server that applies different client-     certificate policies per hostname, for example stricter admin-only client-cert auth on one host and     ordinary client-cert auth on another, a client that authenticates for a permitted host can renegotiate the     TLS 1.2 connection under a different servername and carry its existing authentication to the protected     host, bypassing the stricter policy. This vulnerability affects Node.js 26.x, 24.x, and 22.x.
    (CVE-2026-123872)

Note that Nessus has not tested for these issues but has instead relied only on the application's self-reported version number.

ID	Name	Product	Family	Type	Severity
479025	Alpine: nodejs: security update to 22.23.5-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	Local	high
479025	Alpine: nodejs: security update to 22.23.5-r0	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	Local	high
479024	Alpine: nodejs: security update to 24.22.3-r0	Tenable Cloud Security	Alpine Linux Local Security Checks	Local	high
479024	Alpine: nodejs: security update to 24.22.3-r0	Tenable Self-Hosted Container Security	Alpine Linux Local Security Checks	Local	high
379274	Rocky Linux 9.6 [TuxCare] Security Update: nodejs / nodejs-devel / nodejs-docs / nodejs-full-i18n / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1794442042)	Nessus	Rocky Linux Local Security Checks	Local	high
379273	AlmaLinux 9.2 [TuxCare] Security Update: nodejs / nodejs-devel / nodejs-docs / nodejs-full-i18n / etc Multiple Vulnerabilities (ALMALINUX9.2:CLSA-2026:1794441621)	Nessus	Alma Linux Local Security Checks	Local	high
379269	AlmaLinux 9.6 [TuxCare] Security Update: nodejs / nodejs-devel / nodejs-docs / nodejs-full-i18n / etc Multiple Vulnerabilities (ALMALINUX9.6:CLSA-2026:1794442042)	Nessus	Alma Linux Local Security Checks	Local	high

Detections

Analytics

CVE-2026-123868

medium

Tenable Plugins

high

high

high

high

high

high

high