Cloudanix VulnDB

CVE-2026-1526

High · 7.5

CVSS

7.5

EPSS

1.2%

Published

Mar 12, 2026

CISA due date

—

Cloudanix analysis

Next patch cycle SSVC: Track

A malicious WebSocket server can crash affected Node.js applications by sending compressed data that expands until the application runs out of memory.

Exploitation
Remote Unauthenticated
Attacker needs
None
Complexity
Low
Impact
Denial Of Service
Component
Library
Class
Denial of service
Remediation
Upgrade
Effort
Medium
Patch risk
Low

What it actually does

CVE-2026-1526 is a denial-of-service vulnerability in the undici WebSocket client for Node.js. When a WebSocket connection negotiates the permessage-deflate extension, undici decompresses compressed WebSocket frames in PerMessageDeflate.decompress() without enforcing a maximum decompressed size. A malicious or compromised WebSocket server can send a small compressed payload that expands to a very large buffer in memory. Because the implementation accumulates decompressed chunks and concatenates them into a single Buffer, the Node.js process can experience excessive memory growth, out-of-memory termination, garbage collection pressure, or prolonged unresponsiveness. The impact is availability-only: there is no direct confidentiality or integrity impact described, but affected client processes can crash or become unavailable over the network with low attack complexity and no authentication required by the attacker-controlled server side.

Why it matters to the business

Applications, services, agents, CLIs, workers, or backend integrations that use undici as a WebSocket client may be taken offline if they connect to a malicious, compromised, or spoofed WebSocket endpoint that negotiates compression. This can interrupt real-time messaging, streaming, telemetry, automation, job processing, or API integrations that depend on long-lived WebSocket connections. The CVSS score of 7.5 reflects high availability impact, but the current EPSS score of 0.0115 and lack of known KEV listing indicate no confirmed broad exploitation signal at this time. Risk is highest where Node.js applications connect to third-party or user-controlled WebSocket servers, where endpoint trust cannot be guaranteed, or where process crashes trigger cascading service degradation.

How an attack unfolds

An attacker first positions a WebSocket server that the vulnerable Node.js client will connect to, or compromises an existing WebSocket service trusted by the client. During the WebSocket handshake, the attacker negotiates the permessage-deflate extension so that compressed frames will be decompressed by undici. The attacker then sends a deliberately crafted compressed WebSocket message that is small on the wire but expands to a very large decompressed output. The vulnerable PerMessageDeflate.decompress() path reads and accumulates decompressed chunks without a total output limit, then attempts to concatenate them into one Buffer. Memory usage spikes rapidly, potentially exhausting the V8 heap or system memory. The process may be killed by the runtime or operating system, crash with out-of-memory errors, or become unresponsive due to memory pressure and garbage collection, resulting in denial of service for the affected application.

How to fix it

Upgrade undici to a version that enforces safe decompressed-size limits for WebSocket permessage-deflate handling as soon as an official fixed version is available from the package maintainer. Because no fixed versions were provided in the input, track the upstream undici advisory, Node.js dependency advisories, package manager audit output, and release notes for the exact patched version. Where immediate upgrade is not possible, mitigate by disabling WebSocket compression/permessage-deflate for undici WebSocket client connections if supported, avoiding connections to untrusted or user-controlled WebSocket endpoints, enforcing strict allowlists for WebSocket destinations, placing memory limits and restart policies around affected Node.js processes, and monitoring memory usage for abnormal growth after WebSocket messages. Consider isolating workloads that connect to external WebSocket services so a crash does not affect unrelated application functions.

How to confirm the fix worked

Confirm exposure by inventorying Node.js applications that depend on undici and use WebSocket client functionality, especially where permessage-deflate is enabled or negotiated by default. Use package manager tooling such as npm ls undici, pnpm why undici, yarn why undici, npm audit, and software composition analysis to identify affected versions once upstream version ranges are available. Validate remediation by confirming the deployed undici version is at or above the upstream fixed release when published, and by verifying that WebSocket compression is disabled or bounded where mitigation is used. In test environments only, connect the client to a controlled WebSocket server that negotiates permessage-deflate and sends large-expansion compressed messages; the corrected or mitigated client should reject, abort, cap, or safely handle the message without unbounded memory growth or process failure. Also verify operational controls by checking that memory limits, health checks, and process restart policies behave as expected.

Typical attack path

  1. Identify or induce a vulnerable Node.js application that uses undici as a WebSocket client.
  2. Operate or compromise a WebSocket server that the client will connect to.
  3. Negotiate the permessage-deflate WebSocket extension during the handshake.
  4. Send a compressed WebSocket frame designed to expand to an extremely large decompressed payload.
  5. Trigger unbounded accumulation and Buffer concatenation in the undici decompression path.
  6. Exhaust process memory or cause severe garbage collection pressure.
  7. Cause the Node.js process to crash, be killed, or become unresponsive, disrupting dependent application functionality.

How to detect it

Look for evidence of denial-of-service rather than data theft or code execution. Primary sources include application logs, Node.js runtime stderr/stdout, process manager logs, container orchestration events, host system logs, APM metrics, and network telemetry for WebSocket connections. Focus on abnormal memory growth, V8 heap exhaustion, operating-system or container out-of-memory kills, sudden process exits, and restarts that occur shortly after outbound WebSocket connections where permessage-deflate was negotiated. Investigate WebSocket sessions with the Sec-WebSocket-Extensions header containing permessage-deflate, followed by unusually small inbound compressed frames and disproportionate memory growth. In Kubernetes, review pod events for OOMKilled and correlate timestamps with application logs showing WebSocket activity. In systemd or supervisor-managed deployments, review service restart loops and exit codes associated with SIGKILL or fatal JavaScript heap errors. If proxy or packet metadata is available, identify unexpected WebSocket destinations, newly contacted hosts, or server responses that negotiate permessage-deflate. There are no unique attacker file artifacts for this vulnerability; exploitation generally leaves availability and memory-pressure indicators rather than durable host-based IOCs.

  • permessage-deflate
  • Sec-WebSocket-Extensions: permessage-deflate
  • 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
  • JavaScript heap out of memory
  • Allocation failed - JavaScript heap out of memory
  • OOMKilled
  • Out of memory: Killed process
  • Killed process node
  • signal SIGKILL
  • exit code 137
  • PerMessageDeflate.decompress
  • undici
  • WebSocket

What your security team should do

  • Inventory all Node.js services, agents, workers, and tools that include undici and use WebSocket client connections.
  • Prioritize systems that connect to third-party, internet-facing, partner-managed, or user-controllable WebSocket servers.
  • Track upstream undici and Node.js security advisories for the patched version, and schedule upgrade as soon as a fixed release is available.
  • Temporarily disable permessage-deflate/WebSocket compression where business functionality allows.
  • Restrict WebSocket destination hosts with egress allowlists and certificate validation to reduce exposure to malicious endpoints.
  • Apply process-level memory limits, container limits, health checks, and automatic restarts to reduce blast radius from out-of-memory failures.
  • Add monitoring for sudden Node.js heap growth, container memory pressure, OOMKilled events, process restarts, and WebSocket-related error spikes.
  • Review dependency lockfiles and transitive dependencies to ensure patched undici versions are actually deployed across build artifacts.
  • Prepare detection queries for Node.js out-of-memory crashes occurring shortly after WebSocket connections or compressed WebSocket traffic.
  • Because this issue is not currently in CISA KEV and has low EPSS, treat it as important for exposed WebSocket-client workloads but prioritize based on whether applications connect to untrusted WebSocket servers.

The record

The undici WebSocket client is vulnerable to a denial-of-service attack via unbounded memory consumption during permessage-deflate decompression. When a WebSocket connection negotiates the permessage-deflate extension, the client decompresses incoming compressed frames without enforcing any limit on the decompressed data size. A malicious WebSocket server can send a small compressed frame (a "decompression bomb") that expands to an extremely large size in memory, causing the Node.js process to exhaust available memory and crash or become unresponsive. The vulnerability exists in the PerMessageDeflate.decompress() method, which accumulates all decompressed chunks in memory and concatenates them into a single Buffer without checking whether the total size exceeds a safe threshold.

Affected packages

Ecosystem Package Introduced Fixed
npm undici 0 6.24.0
npm undici 7.0.0 7.24.0
Chainguard code-server 0 4.110.1-r2
Chainguard jitsucom-jitsu-console 0 2.11.0-r17
Chainguard jitsucom-jitsu-rotor 0 2.11.0-r17
Chainguard kibana-8.17 0 8.17.10-r13
Chainguard kibana-8.17-bitnami 0 8.17.10-r13
Chainguard kibana-8.17-iamguarded 0 8.17.10-r13
Chainguard kibana-8.18 0 8.18.8-r11
Chainguard kibana-8.18-bitnami 0 8.18.8-r11
Chainguard kibana-8.18-iamguarded 0 8.18.8-r11
Chainguard kibana-8.19 0 8.19.13-r4
Chainguard kibana-8.19-bitnami 0 8.19.13-r4
Chainguard kibana-8.19-iamguarded 0 8.19.13-r4
Chainguard kibana-9.0 0 9.0.8-r14
Chainguard kibana-9.0-bitnami 0 9.0.8-r14
Chainguard kibana-9.0-iamguarded 0 9.0.8-r14
Chainguard kibana-9.1 0 9.1.10-r7
Chainguard kibana-9.1-iamguarded 0 9.1.10-r7
Chainguard kibana-9.2 0 9.2.7-r0
Chainguard kibana-9.2-iamguarded 0 9.2.6-r3
Chainguard kibana-9.3 0 9.3.2-r0
Chainguard kibana-9.3-iamguarded 0 9.3.2-r0
Chainguard pelias-api 0 7.6.0-r4
Chainguard renovate 0 43.84.0-r1
Wolfi code-server 0 4.110.1-r2
Wolfi jitsucom-jitsu-console 0 2.11.0-r17
Wolfi jitsucom-jitsu-rotor 0 2.11.0-r17
Wolfi renovate 0 43.84.0-r1

Related vulnerabilities