ALPINE-CVE-2026-123865: High severity alpine/nodejs vulnerability
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 CLOSEWAIT 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(NOERROR), 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.
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
alpine/nodejsto a version that resolves this vulnerability.Fixed in 22.23.5-r0 - Upgrade
Upgrade
alpine/nodejsto a version that resolves this vulnerability.Fixed in 24.22.3-r0
Event History
Frequently Asked Questions
Which deployments are exposed to this issue?
Node.js HTTP/2 servers in the affected 26.x, 24.x, and 22.x release lines are exposed. The issue is reliable against default HTTP/2 server configurations.
What does an attacker need to exploit it?
An attacker only needs unauthenticated network access to the HTTP/2 service. They can initiate shutdown with GOAWAY(NO_ERROR) and then trigger a protocol error, such as an oversized frame header, while the session is shutting down.
What is the operational impact of repeated exploitation?
Each successful attempt can leave a connection socket in CLOSE_WAIT and retain all Node.js HTTP/2 state for that connection indefinitely. Repeated dangling sessions can permanently consume memory and file descriptors, resulting in denial of service.
How can operators identify potentially affected sessions?
Look for HTTP/2 connections whose sockets remain in CLOSE_WAIT while associated Node.js HTTP/2 session state is not released. Persistent growth in memory or open file descriptors after HTTP/2 peers disconnect or encounter protocol errors is also indicative.