CVE-2026-85014

Executive Summary

CVE-2026-85014 is a denial-of-service (DoS) vulnerability in undici, the Node.js HTTP client library, affecting the experimental WebSocketStream client. When a remote peer abruptly closes a TCP connection without performing a proper WebSocket close handshake, the internal socket-close handler aborts the locked writable stream unconditionally, discarding the rejected promise that results from per WHATWG Streams standard. Because the application holds a writer on that writable stream, the unhandled rejection triggers Node.js's default unhandled-rejection behavior, crashing the entire process. An unauthenticated, untrusted remote server can exploit this flaw with a single abrupt disconnect to terminate any Node.js process using a vulnerable undici version with WebSocketStream. The vulnerability affects undici versions 7.0.0 through 7.29.1 and 8.0.0 through 8.10.2; users should upgrade to undici 7.29.1 or 8.10.2. The CVSS score is 5.9 (High availability impact, medium attack complexity, no privileges or user interaction required).

Technical Analysis

Vulnerability Class

CVE-2026-85014 is categorized under CWE-248 — Uncaught Exception. The vulnerable mechanism resides in undici's experimental WebSocketStream client, a Node.js API that exposes WebSocket connections through the WHATWG Streams interface.

Root Cause Mechanism

Per the NVD description, the vulnerability is triggered when a remote peer closes the TCP connection without a proper WebSocket close handshake — described as an "unclean close." When this occurs, undici's internal socket-close handler executes an abort operation on the writable component of the WebSocketStream.

The core flaw involves a specification compliance issue with the WHATWG Streams standard. Under the WHATWG Streams specification, aborting a locked writable stream returns a promise that rejects with a TypeError, because the stream cannot be aborted while a writer is active. However, undici's socket-close handler calls the abort unconditionally and discards the returned promise without handling its rejection.

Why the Rejection Becomes Fatal

The attack chain inside the runtime operates as follows:

1. The application creates a WebSocketStream and obtains a writer for the writable stream — per the streams API, this lock is mandatory to perform write operations.
2. The remote server terminates the TCP connection abrutly, without a WebSocket close frame sequence.
3. undici's socket-close event handler invokes the abort operation on the writable stream.
4. Under WHATWG Streams semantics, because the writable is locked by the writer, the abort returns a rejected promise (TypeError).
5. Undici discards this promise without attaching a rejection handler.
6. From the application's perspective, the writer on the writable stream is the only means of consuming or observing the abort. Since the application is not itself invoking the abort, it never receives or handles the rejection.
7. Node.js's default unhandled-rejection policy terminates the process.

The dependency on Node.js's unhandled-rejection behavior is critical — if the host had a custom process.on('unhandledRejection') handler installed, the process would not crash. However, the default behavior in Node.js is to terminate the process, and the NVD description explicitly states the rejection is "never observed" and that "Node's default unhandled-rejection behavior terminates the process." Reliance on application-level mitigation is therefore not guaranteed and no application error or misconfiguration is required for the crash.

Attack Surface and Requirements

• Attack Vector: Network (remote).
• Attack Complexity: High. The remote server must negotiate a WebSocketStream connection with the client (which requires the client application to initiate a WebSocket connection through the experimental API), then perform an unclean TCP teardown.
• Authentication Requirement: None. No credentials or pre-existing trust required beyond successfully establishing the WebSocket connection.
• User Interaction: None. A fully automated server-side action causes the crash.
• Privileges Required: None for the attacker; the victim process must be running a vulnerable undici version and actively using WebSocketStream against an attacker-controlled (or attacker-compromised) server.

Scope of Impact

The impact is limited to the client process — it causes a full process crash (availability impact), with no confidentiality or integrity impact. Because the TCP teardown originates from the server side, the attack requires the client to connect to a malicious or compromised endpoint. The experimental nature of the WebSocketStream API means adoption is likely limited, but any production deployment using this API is exposed.

Exploitation Scenarios

Attack Chain Step 1 — Reconnaissance / Target Identification: The attacker operates a malicious WebSocket server. The attacker must identify Node.js applications that (a) use undici version 7.x (7.0.0–7.29.1) or 8.x (8.0.0–8.10.2), and (b) use the experimental WebSocketStream client API to connect to remote servers. This can be determined through application fingerprinting (e.g., observing client connection patterns, User-Agent headers in HTTP handshakes, or service banners in a controlled environment). Because the API is experimental, direct Internet-wide scanning is not practical; the attacker more likely compromises a legitimate WebSocket server that known applications connect to, or lures connections through social engineering or service advertisement.

Attack Chain Step 2 — Triggering the Flaw Class: Once a vulnerable client establishes a WebSocketStream connection to the attacker-controlled server, the attacker closes the underlying TCP connection without issuing a WebSocket close frame. This constitutes an unclean close — a single abrupt TCP FIN or RST packet suffices. No authentication bypass, no multi-step exploit, and no payload delivery have been involved to this point.

Attack Chain Step 3 — Payload / Execution Method: The exploit is a single TCP connection teardown. The attacker does not send any malicious payload — the deterministic crash is triggered by (a) the TCP disconnect event, (b) undici's internal socket-close handler aborting the locked writable stream, and (c) the unobserved rejected promise invoking Node.js's default unhandled-rejection termination. No public PoC available; attack chain is inferred from vulnerability class and NVD description. The complete reproducibility of this crash is dependent only on the aforementioned deterministic conditions, not on memory corruption or probabilistic heap state.

Attack Chain Step 4 — Post-Exploitation Impact: The Node.js process crashes completely, terminating all in-flight requests and connections handled by that process. For multi-process deployments (e.g., Node.js cluster mode, PM2 clusters), only the worker process handling the connection is terminated — the master or other workers may restart it. For single-process deployments — common for small services or internal microservices — the full application is unavailable until manual or supervisor-driven restart. Repeated disconnects can create an application-level DoS loop: each new connection is crashed again by the same technique, preventing the service from ever reaching steady state. This yields persistent service unavailability with only trivial efforts from the attacker.

Impact Assessment

CVSS Subscore Analysis

The CVSS:3.1 vector (AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:H) yields a base score of 5.9 (Medium severity). Key observations:

• Availability Impact: High. A single unclean disconnect crashes the entire Node.js process.
• Attack Complexity: High. The attacker must induce the victim to connect to a malicious WebSocket server (or achieve control over a server the client trusts), then orchestrate an unclean teardown. The requirement for client initiation of a WebSocketStream connection reduces the practical reach.
• No Confidentiality or Integrity Impact. The crash is non-corruptive and provides no data disclosure.
• Scope: Unchanged. The compromised component is the same as the vulnerable component.

Business Impact

• Service Availability: Applications using the experimental WebSocketStream API are subject to deterministic remote crash. Any business-critical service relying on undici WebSocketStream becomes targetable by any server it connects to, or by any attacker who can compromise one of those servers.
• Operational Resilience: Distributed architectures with per-worker process isolation will experience only transient worker restarts, but single-process architectures face full-downtime events.
• Compliance & SLAs: If the affected component supports customer-facing functionality, availability SLA breaches are possible. No regulatory data-breach obligations arise since no data exposure occurs.

Affected Systems and Blast Radius

• Directly affected: Node.js applications using undici ≥ 7.0.0 and < 7.29.1, or ≥ 8.0.0 and < 8.10.2, specifically through the experimental WebSocketStream client API.
• Indirectly affected: Any package transitively depending on an affected undici version while using WebSocketStream. Because the vulnerability is confined to a client-side API, server-side undici deployments (as HTTP servers) are not exposed.
• Not affected: Applications not using WebSocketStream; undici versions outside the specified ranges; WebSocket implementations using the standard ws module or undici's non-streams WebSocket client.

Detection Guidance

Detection of this specific vulnerability is challenging because the triggering event (an unclean TCP close) is indistinguishable across the network from normal connection resets. Detection is therefore most viable at the application/process level by monitoring for process termination patterns correlated with WebSocket activity. The following detection artifacts reflect that reality; none are network-based detections of a malicious payload, because no payload exists.

Sigma Rule

title: Node.js Process Crash Following WebSocketStream Unclean Disconnect
id: 0c9a3f2e-6b4d-4e2c-9d2f-7a0c8d1e9f3a
status: experimental
description: Detects Node.js process termination events correlated with WebSocketStream usage and TCP disconnects, potentially indicating CVE-2026-85014 exploitation.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-85014
author: Valtersit Threat Intelligence
date: 2026/06/15
logsource:
    category: process_creation
    product: linux
detection:
    selection_node:
        Image|endswith: '/node'
    selection_signal:
        # Signal 15 (SIGTERM) or 9 (SIGKILL) or exit codes typically seen on Node crashes
        ExitCode:
            - '1'
            - '134' # SIGABRT
        # NOTE: Node default unhandledRejection exit code was observed; adjust per runtime logs
    condition: selection_node and selection_signal
level: medium
falsepositives:
    - Legitimate unhandled promise rejections in applications without custom handlers
    - Normal Node.js runtime crashes unrelated to WebSocketStream
fields:
    - ParentImage
    - CommandLine
    - User

YARA Rule

rule CVE_2026_85014_Node_Undici_WebSocketStream_Crash
{
    meta:
        author = "Valtersit Threat Intelligence"
        description = "Detects source code or static artifacts referencing undici WebSocketStream abort patterns described in CVE-2026-85014"
        cve = "CVE-2026-85014"
        date = "2026-06-15"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-85014"

    strings:
        $s1 = "WebSocketStream" ascii wide nocase
        $s2 = "abort" ascii wide nocase
        $s3 = "unhandledRejection" ascii wide nocase
        $s4 = "unclean" ascii wide nocase
        $s5 = "writable" ascii wide nocase

    condition:
        // Heuristic: WebSocketStream combined with abort/writable references in source or bundled JS
        ($s1 and $s3) or
        ($s1 and $s2 and $s5)
}

Suricata IDS Rule

Suricata network detection is severely limited for this vulnerability — the triggering element is a normal TCP RST/FIN teardown that carries no unique payload. A rule attempting to flag all WebSocket teardowns would produce extreme false positives. The following rule is therefore written to flag anomalous TCP reset behavior immediately following an HTTP WebSocket upgrade handshake, which may correlate with the exploit pattern:

alert tcp any any -> any any (msg:"CVE-2026-85014 Possible Unclean WebSocket Teardown After Upgrade"; flow:established,to_server; content:"|0d 0a|Upgrade: websocket|0d 0a|"; nocase; flowbits:set,websocket_upgrade; flowbits:noalert; sid:85014001; rev:1;)

alert tcp any any -> any any (msg:"CVE-2026-85014 WebSocket Connection Immediately Reset Following Upgrade"; flow:established; flowbits:isset,websocket_upgrade; flags:R; flowbits:unset,websocket_upgrade; classtype:attempted-dos; sid:85014002; rev:1; threshold: type both, track by_dst, count 5, seconds 60;)

Note: The first rule sets a flowbit on the HTTP upgrade request. The second rule alerts when a TCP RST is observed within the same flow, but uses a threshold to reduce false-positive noise from legitimate resets.

Elastic Detection

EQL detection for this vulnerability must focus on process termination events from Node.js processes where abnormal exit codes coincide with WebSocket-related command-line arguments.

process where event.type == "end" and process.name == "node" and (
    (process.exit_code == 1 or process.exit_code == 134)
    and process.args : ("*WebSocket*", "*undici*", "*websocketstream*")
)

Splunk SPL Query

index=process OR index=winprocess
| where Image="*node*" OR process_name="node"
| search (exit_code=1 OR exit_code=134 OR exit_code=139)
    AND (CommandLine="*WebSocket*" OR CommandLine="*ws*" OR CommandLine="*undici*")
| eval crash_time = _time
| stats count by host, Image, CommandLine, exit_code, parent_process
| sort - count

For network-side detection in Splunk, correlate TCP connection teardown with WebSocket upgrade:

index=streams OR index=netflow
| search event_type="tcp" AND (flags="R" OR flag="FIN")
| lookup websocket_sessions.csv session_id as session_id OUTPUT websocket_yes
| where websocket_yes == "true"
| stats dc(dest_ip) as impacted_hosts by src_ip, _time

Wazuh OSSEC Rule

<group name="nodejs, dos,">
    <!-- Detect abnormal Node.js process termination -->
    <rule id="850140" level="10">
        <if_sid>510</if_sid>  <!-- Parent rule for process termination in Wazuh's default set -->
        <field name="process_name">^node$</field>
        <field name="exit_code">^(1|134|139)$</field>
        <description>CVE-2026-85014: Node.js process crashed with abnormal exit code, possible WebSocketStream unclean disconnect DoS</description>
        <group>availability,process_termination,</group>
    </rule>

    <!-- Add correlation rule for repeated crashes indicating active exploitation -->
    <rule id="850141" level="12" frequency="3" timeframe="300">
        <if_matched_sid>850140</if_matched_sid>
        <same_source_ip/>
        <description>CVE-2026-85014: Repeated Node.js crashes from source — likely active exploitation attempt</description>
        <group>dos,availability,</group>
    </rule>
</group>

Mitigation & Patch Guidance

Patch Confidence: 0/4 — UNPATCHED. No independent patch evidence was observed from any tracked source at the time of this report. However, the NVD advisory itself directs users to upgrade to undici 7.29.1 or 8.10.2, indicating the advisory was issued with version-specific remediation guidance. Contrast between advisory language and absence of third-party patch confirmation means organizations should verify the fix in their environment.

Immediate Mitigations (No Patch Available or Until Verified)

1. Disable or remove WebSocketStream usage: Identify any application code using the WebSocketStream API (experimental in undici). If this feature is not essential, replace it with undici's standard WebSocket client (non-streams based), which is not affected.
2. Install a global unhandledRejection handler: As a temporary hardening measure before upgrading, add process.on('unhandledRejection', (err) => { /* log and persist; do not exit */ }) at the application entry point. This prevents the default process-termination behavior but does not address the underlying stream-abort bug. This is a stopgap only — it can mask genuine programming errors.
3. Process-level isolation: Ensure Node.js services run under cluster mode, PM2, or an orchestrator that automatically restarts crashed workers with minimal downtime.
4. Connection policy: Restrict outbound WebSocket connections to trusted endpoints via application-level allow-lists; do not allow arbitrary server connections through WebSocketStream.

Patch / Upgrade Steps

1. Confirm the exact undici version in use: npm list undici or check your package-lock.json / yarn.lock.
2. If undici is a direct dependency, upgrade: npm install undici@7.29.1 (for 7.x tracks) or npm install undici@8.10.2 (for 8.x tracks).
3. If undici is a transitive dependency, identify the parent package that depends on it and upgrade that package. If no upstream release is available, use npm overrides (npm ≥ 8.3) or resolution (Yarn) to force the patched undici version.
4. Re-run the application's test suite, especially WebSocketStream integration tests, to confirm the upgrade does not introduce regressions.
5. Verify the fixed version is active: npm ls undici.

Long-Term Hardening

1. Vulnerability management cadence: Monitor the undici GitHub release notes and Node.js security announcements for all vulnerabilities affecting transitive packages.
2. Dependency pinning: Use lockfiles committing exact undici versions; enable automated dependency update tooling (Dependabot, Renovate) with security-focused alerting.
3. Runtime controls: Deploy Node.js applications using supervisor/orchestration tooling that restarts crashed processes and alerts on abnormal termination frequency.
4. Audit WebSocket API usage: Review whether experimental APIs are appropriate for production use; prefer stable, actively maintained libraries for critical functions.
5. Network egress filtering: Limit outbound connections to required WebSocket endpoints by destination IP/port at the firewall — reduces the likelihood of malicious server contact.
6. Logging: Enable unhandled rejection logging during development (e.g., --unhandled-rejections=warn flag) to surface similar issues before production deployment.

References

1. NVD Entry: https://nvd.nist.gov/vuln/detail/CVE-2026-85014
2. undici GitHub Repository (version history and advisories): https://github.com/nodejs/undici
3. WHATWG Streams Standard (abort semantics for locked streams): https://streams.spec.whatwg.org/#writable-stream-abort
4. Node.js Documentation — process unhandledRejection event (default termination behavior): https://nodejs.org/api/process.html#event-unhandledrejection
5. CVE-2026-85014 at CWE-248 (Uncaught Exception) — Mitre: https://cwe.mitre.org/data/definitions/248.html

Known exploit-in-the-wild evidence: None reported as of the publication date. CISA KEV does not list this CVE. No public PoC, Nuclei template, or exploit code has been observed. No known threat actor campaigns associated with this CVE have been disclosed.