HIGH 7.5

CVE-2026-12151: undici WebSocket Memory Exhaustion DoS Vulnerability

The undici WebSocket client, a widely-used library in Node.js applications, has a vulnerability that allows a malicious or compromised WebSocket server to exhaust memory on the client side. The issue stems from the library's failure to limit the number of WebSocket message fragments—even though each fragment individually respects size limits, an attacker can send hundreds or thousands of small fragments to accumulate unbounded memory usage. This causes the client process to crash due to memory exhaustion, creating a denial-of-service condition. Any application that connects to untrusted WebSocket endpoints is at risk.

Source data · NVD / CISA · public domain

CVSS
3.1 · 7.5 HIGH · CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
Weaknesses (CWE)
CWE-400, CWE-770
Affected products
1 configuration(s)
Published / Modified
2026-06-17 / 2026-07-21

NVD description (verbatim)

Impact: The undici WebSocket client enforces maxPayloadSize on the cumulative byte count of fragments in a message but does not enforce a limit on the number of fragments. A malicious WebSocket server can stream many small or empty continuation frames that each pass per-frame and cumulative-size validation, collectively causing unbounded memory growth in the client process. The result is memory exhaustion and a denial of service. Affected applications are those using the undici WebSocket client (new WebSocket(...)) or the WebSocketStream API that can be induced to connect to an attacker-controlled or compromised WebSocket endpoint. All releases starting at undici 6.17.0 are affected. Patches: Upgrade to undici >= 6.26.0, >= 7.28.0, or >= 8.5.0. Workarounds: No workaround is available. The fix must be applied through an upgrade.

19 reference(s) · View on NVD →

SEC.co analysis · AI-assisted, reviewed against source

Technical summary

CVE-2026-12151 is a resource exhaustion vulnerability in undici's WebSocket implementation. The client correctly validates maxPayloadSize against the cumulative byte count of fragments within a single message, but fails to enforce a per-message limit on the number of fragments itself. A malicious server can exploit this by sending continuation frames with minimal or zero-length payloads; each frame passes validation independently, but their aggregate causes unbounded growth of internal data structures tracking message state. This leads to memory exhaustion without triggering payload-size checks. The vulnerability affects all versions from 6.17.0 onward until patched. The weakness is classified under CWE-400 (Uncontrolled Resource Consumption) and CWE-770 (Allocation of Resources Without Limits or Throttling).

Business impact

Applications relying on undici for WebSocket communication—particularly those connecting to third-party or user-supplied WebSocket endpoints—face availability risk. A denial-of-service attack via resource exhaustion could crash critical services, disrupt real-time communication features (chat, notifications, live data streams), or trigger cascading failures in microservice architectures. In cloud environments, repeated attacks could inflate infrastructure costs through aggressive auto-scaling. The impact is amplified for always-on services that must maintain WebSocket connections to external or less-trusted providers.

Affected systems

The vulnerability affects Node.js applications using undici versions 6.17.0 through 6.25.x, 7.0.0 through 7.27.x, and 8.0.0 through 8.4.x. Any code instantiating a WebSocket client via undici's `new WebSocket(...)` constructor or using the WebSocketStream API is vulnerable. This includes both direct usage and indirect dependency through frameworks or libraries that embed undici. Notably, undici is a core component of Node.js's native fetch and WebSocket support in recent versions, making exposure potentially widespread.

Exploitability

Exploitation requires only network-level control: the attacker must convince or trick the victim application into connecting to a malicious WebSocket server, or compromise an existing trusted endpoint. No authentication or elevated privileges are needed. The attack is trivial to execute—sending small continuation frames in rapid succession—and requires no special tools or exploit code. The barrier to exploitation is low, especially for applications that connect to external services based on user input or configuration.

Remediation

Upgrade undici immediately to version 6.26.0 or later, 7.28.0 or later, or 8.5.0 or later. No interim workaround exists; patching is mandatory. Organizations should prioritize this upgrade for any production systems handling WebSocket connections. For applications unable to update immediately, restrict network connectivity to WebSocket endpoints under trusted administrative control only.

Patch guidance

Apply one of the following patched versions depending on your current baseline: undici >= 6.26.0 (for the 6.x line), >= 7.28.0 (for the 7.x line), or >= 8.5.0 (for the 8.x line). Use your package manager (npm, yarn, pnpm) to upgrade: `npm update undici` or manually specify the minimum version in package.json and reinstall. Test in a staging environment to ensure compatibility with your application's WebSocket usage patterns. If undici is a transitive dependency, verify that dependent packages are compatible with the patched version before deploying to production.

Detection guidance

Monitor for unexpected spikes in memory consumption in Node.js processes using WebSocket clients, particularly following connections to external or user-supplied endpoints. Log WebSocket connection attempts and their sources; correlate memory exhaustion incidents with new or suspicious server connections. Implement resource limits (e.g., memory caps via cgroups or container orchestration) to prevent a single process from consuming excessive system resources. Consider using APM or memory profiling tools to detect unusual fragment accumulation patterns. Network-level IDS rules could flag servers sending excessive continuation frames, though this may generate false positives in legitimate high-frequency streaming scenarios.

Why prioritize this

This vulnerability merits immediate attention despite lacking CISA KEV status. It combines a network-accessible attack vector, trivial exploitability, and direct denial-of-service impact with a CVSS score of 7.5 (HIGH). The widespread adoption of undici in Node.js ecosystems—including as a built-in component—amplifies blast radius. Applications accepting WebSocket connections from external or semi-trusted sources face elevated risk and should patch first. Even internal-only deployments should be prioritized if network boundaries cannot be absolutely guaranteed.

Risk score, explained

The CVSS 3.1 score of 7.5 reflects a network-accessible vulnerability (AV:N) with low attack complexity (AC:L), no privilege or user interaction requirements (PR:N/UI:N), and a direct availability impact through denial of service (A:H). Confidentiality and integrity are unaffected (C:N/I:N). The score appropriately captures the threat level for services exposed to untrusted WebSocket peers. Organizations with strict perimeter controls limiting WebSocket connections to internal or administratively controlled servers may assess lower practical risk, but should not rely on this assumption without explicit validation.

Frequently asked questions

Can an attacker gain code execution or steal data through this vulnerability?

No. This vulnerability is strictly a denial-of-service attack via memory exhaustion. It does not enable code execution, data theft, or other integrity/confidentiality breaches. The impact is limited to availability.

Do I need to upgrade if my application only connects to trusted WebSocket servers under my control?

If your servers are genuinely isolated from untrusted input and administrative access is strictly controlled, your practical risk is lower. However, upgrades are still recommended to protect against misconfiguration, compromised internal systems, or supply-chain scenarios. A blanket 'trusted server' assumption is risky and should be validated explicitly.

Will upgrading undici break my application?

Patched versions are intended to be backwards-compatible drop-in replacements. Test in staging first, but major disruption is unlikely. If you have strict version pinning or unusual WebSocket usage, review release notes for the specific patched version to confirm compatibility.

Is there a way to mitigate this without upgrading immediately?

Implementing strict per-process memory limits (via containerization, cgroups, or process management) can prevent full system impact, but will not prevent the DoS of individual processes. Restricting WebSocket endpoint connectivity to administratively controlled servers is the best interim control. Upgrade as soon as operationally feasible.

This analysis is provided for informational purposes and reflects information available as of the publish date. Security assessments are context-dependent; your organization's risk posture depends on network architecture, exposure, and operational controls. Always validate vulnerability details against official vendor advisories and your specific software inventory before making remediation decisions. SEC.co does not provide legal or compliance advice; consult your security and legal teams regarding regulatory obligations related to vulnerability remediation. Source: NVD (public-domain), retrieved 2026-07-27. Analysis generated by SEC.co (claude-haiku-4-5).