CVE-2026-12151

What it actually does

CVE-2026-12151 is a denial-of-service flaw in the undici WebSocket client. Starting with undici 6.17.0, the client enforces maxPayloadSize against the cumulative byte size of a WebSocket message, but it does not enforce a limit on the number of fragments that may compose that message. A malicious or compromised WebSocket server can send a very large number of small or empty continuation frames that individually satisfy size checks while forcing the client process to retain unbounded message-fragment state. This can cause uncontrolled memory growth, garbage-collection pressure, process termination, container restarts, or service unavailability in applications using new WebSocket(...) or the WebSocketStream API to connect to an attacker-controlled endpoint.

Why it matters to the business

Successful exploitation can make Node.js applications unavailable by exhausting memory in processes that initiate WebSocket connections to malicious or compromised servers. The most likely operational impact is degraded service, process crashes, restart loops, autoscaling churn, failed background jobs, or interruption of integrations that depend on outbound WebSocket connectivity. The issue has a high availability impact but no known direct confidentiality or integrity impact. It is not currently listed in CISA KEV, is not reported as used in ransomware campaigns, has low EPSS at the time of assessment, and has no indicated public exploit maturity; however, exploitation is technically straightforward if an attacker can influence the WebSocket endpoint a vulnerable application connects to.

How an attack unfolds

An attacker first needs to get a vulnerable application to establish a WebSocket connection to a server the attacker controls or to compromise a legitimate WebSocket endpoint already trusted by the application. When the undici client connects, the malicious server begins a fragmented WebSocket message and then sends a continuous stream of many small or empty continuation frames. Because each frame and the cumulative byte count remain within the configured maxPayloadSize, the client does not reject the message based on payload size. However, because there is no fragment-count limit, internal state and buffering grow with the number of fragments. Over time, the Node.js process consumes increasing memory until it slows significantly, is killed by the runtime or operating system, exits due to out-of-memory conditions, or is restarted by orchestration infrastructure. The attacker can repeat this against each reconnecting client to sustain denial of service.

How to fix it

Upgrade undici to a patched release. The vendor-provided fixed versions are undici >= 6.26.0, >= 7.28.0, or >= 8.5.0, depending on the major release line in use. Because no workaround is available, remediation requires applying an upgraded dependency version and redeploying affected applications. Review direct and transitive dependency trees for undici versions starting at 6.17.0 and below the fixed versions. Where Node.js runtime distributions bundle or pin undici, confirm whether the runtime-provided version is affected and update the runtime or package lock accordingly. As defense in depth, restrict outbound WebSocket destinations to trusted endpoints, avoid allowing user-controlled WebSocket URLs, enforce egress filtering, configure process memory limits and restart policies, and monitor for abnormal reconnect or memory-growth behavior; these controls reduce exposure but do not replace the upgrade.

How to confirm the fix worked

Confirm dependency versions using package manager tooling such as npm ls undici, pnpm why undici, yarn why undici, software composition analysis, or lockfile review. Any deployed application using undici versions starting at 6.17.0 should be considered exposed unless it is on undici >= 6.26.0, >= 7.28.0, or >= 8.5.0. Validate that applications using new WebSocket(...) or WebSocketStream have been rebuilt and redeployed with the patched dependency, not merely updated in source control. In test environments, verify that connections to a fragmented-frame test server no longer cause sustained memory growth or process termination. Operationally, confirm memory usage remains stable during WebSocket activity and that no vulnerable undici versions remain in container images, serverless bundles, or packaged artifacts.

Typical attack path

1. Identify an application or service that uses the undici WebSocket client or WebSocketStream API and can be induced to connect to an attacker-controlled or compromised WebSocket endpoint.
2. Prepare a malicious WebSocket server that accepts client connections and begins a fragmented message.
3. Send many small or empty continuation frames while keeping the total payload size within the configured maxPayloadSize threshold.
4. Keep the connection open and continue streaming fragments to force growth in client-side memory usage.
5. Wait for the client process to suffer garbage-collection pressure, memory exhaustion, crash, or orchestrated restart.
6. Repeat the behavior on reconnects or across multiple clients to sustain availability impact.

How to detect it

To determine whether exploitation may already have occurred, review application, process, container, host, and network telemetry for Node.js services that initiate outbound WebSocket connections. Focus on unexplained memory growth, JavaScript heap exhaustion, process crashes, out-of-memory kills, container restarts, and repeated reconnects to the same WebSocket endpoint. Useful log sources include application logs, Node.js stderr/stdout, process supervisor logs, Kubernetes pod events, container runtime logs, system logs, APM memory metrics, egress proxy logs, firewall logs, and packet captures or network flow records. Network evidence may show long-lived outbound WebSocket connections with unusually high frame counts but very low payload volume, especially continuation frames. If TLS interception or endpoint packet capture is unavailable, correlate memory exhaustion timing with outbound connections to newly observed, untrusted, or recently changed WebSocket hosts. There are no unique file-system artifacts for this vulnerability; detection is primarily behavioral and version-based.

• JavaScript heap out of memory
• FATAL ERROR: Reached heap limit Allocation failed - JavaScript heap out of memory
• FATAL ERROR: Ineffective mark-compacts near heap limit Allocation failed - JavaScript heap out of memory
• Allocation failed - JavaScript heap out of memory
• OOMKilled
• out of memory: Killed process
• Killed process node
• ContainerStatusUnknown
• CrashLoopBackOff
• WebSocketStream
• new WebSocket(
• undici@6.17.
• undici@6.18.
• undici@6.19.
• undici@6.20.
• undici@6.21.
• undici@6.22.
• undici@6.23.
• undici@6.24.
• undici@6.25.
• undici@7.0.
• undici@7.1.
• undici@7.2.
• undici@7.3.
• undici@7.4.
• undici@7.5.
• undici@7.6.
• undici@7.7.
• undici@7.8.
• undici@7.9.
• undici@7.10.
• undici@7.11.
• undici@7.12.
• undici@7.13.
• undici@7.14.
• undici@7.15.
• undici@7.16.
• undici@7.17.
• undici@7.18.
• undici@7.19.
• undici@7.20.
• undici@7.21.
• undici@7.22.
• undici@7.23.
• undici@7.24.
• undici@7.25.
• undici@7.26.
• undici@7.27.
• undici@8.0.
• undici@8.1.
• undici@8.2.
• undici@8.3.
• undici@8.4.

What your security team should do

• Inventory applications and packages that include undici, prioritizing internet-facing services, background workers, integrations, and applications that initiate outbound WebSocket connections.
• Upgrade affected deployments to undici >= 6.26.0, >= 7.28.0, or >= 8.5.0 based on the appropriate release line, and redeploy all affected artifacts.
• Search dependency lockfiles, container images, and software bills of materials for undici versions >= 6.17.0 and below the fixed versions.
• Review whether any application accepts user-supplied or externally influenced WebSocket URLs; remove that capability where unnecessary or restrict it through allowlists.
• Apply egress controls so production services can connect only to approved WebSocket endpoints.
• Add monitoring for abnormal Node.js memory growth, out-of-memory kills, frequent restarts, and long-lived outbound WebSocket sessions with unusual frame counts or low payload volume.
• Because there is no workaround, treat upgrade as the primary remediation even though KEV, ransomware use, and exploit maturity indicators are currently low.