CVE-2026-19534

Executive Summary

CVE-2026-19534 is an unauthenticated, remotely triggerable denial-of-service vulnerability in the undici HTTP/1.1 and WebSocket client library used by Node.js applications. A malicious or compromised WebSocket server — or a network attacker capable of modifying plaintext WebSocket traffic — can crash the entire Node.js process by sending a Sec-WebSocket-Protocol response header during the opening handshake when the client never requested any subprotocol. The flaw affects undici versions 6.7.0 through 6.28.1, 7.0.0 through 7.29.1, and 8.0.0 through 8.10.2, and is fixed in 6.28.1, 7.29.1, and 8.10.2. Any Node.js application that opens outbound WebSocket connections to untrusted endpoints is vulnerable to complete process termination, leading to service outage, dropped in-flight requests, and cascading availability failures.

Technical Analysis

Vulnerability Class and CWE Mapping. CVE-2026-19534 is classified under CWE-248 (Uncaught Exception). The root cause is a null-pointer dereference that occurs inside an asynchronous microtask not guarded by error-handling logic. In Node.js, an uncaught exception propagating out of a microtask triggers the process-level uncaughtException path, which by default terminates the process with a non-zero exit code. The vulnerability is therefore a classic and severe availability flaw: a single malformed (but protocol-tolerable) server response is sufficient to kill the entire Node.js runtime, not merely the individual WebSocket connection.

Affected Functionality. The vulnerable code path is inside undici's WebSocket client during the opening handshake. When undici initiates a WebSocket connection, the default Sec-WebSocket-Protocol request header is absent — the client sends no subprotocol preference unless the application explicitly configures one. Per RFC 6455, a server that receives no subprotocol request must not select any subprotocol and should omit the Sec-WebSocket-Protocol header from its 101 Switching Protocols response. However, if a misbehaving or malicious server nevertheless includes a Sec-WebSocket-Protocol header in the 101 response, undici dereferences a null value while checking the server-selected protocol against the client's (empty) requested list. The resulting TypeError is thrown inside a microtask with no surrounding error handling, and the exception escapes to the process level, terminating Node.js.

Attack Mechanism and Conditions. The trigger requires only that: (1) the victim application uses undici's WebSocket client to connect to a server; and (2) the server's 101 response includes a Sec-WebSocket-Protocol header despite the client having requested no subprotocol. There is no requirement for application code to be misconfigured — the vulnerable scenario is the default connection behavior of the undici WebSocket client. An attacker can exploit this in one of two ways:

• Direct server control: If the victim connects to a WebSocket endpoint the attacker controls (e.g., a compromised upstream service, a malicious third-party API, or a phishing-driven connection), the attacker simply includes the offending header in the handshake response.
• Man-in-the-middle (MITM): Because the WebSocket opening handshake can traverse plaintext HTTP (ws:// scheme), a network-level attacker who can intercept and modify traffic can inject a synthetic 101 response or modify an existing one to include the Sec-WebSocket-Protocol header. No TLS is required for this attack path when the client uses ws://.

No authentication required; no user interaction required. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H) confirms the attack requires network adjacency, no special privileges, and no user interaction. Impact is confined to availability (A:H), with no confidentiality or integrity impact.

Confidence Note. The NVD description provides the precise failure mechanism (null dereference verifying the subprotocol against an empty requested list, causing an uncaught TypeError in a microtask) but does not name the specific internal function, file, or line where the defect occurs. Public exploit code and PoCs are not available at the time of writing. The technical mechanism described above is drawn strictly from the NVD description and RFC 6455 semantics; no implementation detail beyond the description has been fabricated.

Exploitation Scenarios

Scenario 1 — Malicious WebSocket Server (Primary). An application using undici's WebSocket client connects to an external service. This is common in Node.js applications that consume real-time feeds, chat APIs, financial data streams, IoT telemetry, or WebSocket-based push notifications from third-party vendors.

1. Reconnaissance / target identification: The attacker identifies a target application that connects to WebSocket endpoints outside its trust boundary. This is achievable by analyzing public documentation, observing the application's outbound traffic, or simply because the attacker is the WebSocket server operator (e.g., a malicious SaaS provider, a compromised upstream). No precise knowledge of the internal undici version is required; the attacker can send the malicious response to all WebSocket handshakes and it will crash vulnerable undici clients while being harmlessly ignored by clients that correctly implement RFC 6455.
2. Trigger: When the victim application initiates the WebSocket opening handshake (HTTP GET with Upgrade: websocket and Connection: Upgrade), the attacker — acting as the server — responds with HTTP 101 Switching Protocols and includes a Sec-WebSocket-Protocol: whatever header in the response. The victim's undici client had sent no Sec-WebSocket-Protocol request header.
3. Execution: The client's handshake-completion code in undici dereferences a null value while validating the server-chosen subprotocol against the empty requested list. A TypeError is thrown inside a microtask. No try/catch or promise rejection handler surrounds this code path, so the exception propagates to the Node.js event loop and triggers unhandled exception termination of the entire process.
4. Post-exploitation impact: The Node.js process exits immediately. All in-flight HTTP requests, other WebSocket connections, scheduled timers, and the main application loop are terminated. If the process runs under a supervisor (PM2, systemd, Docker restart policy, Kubernetes), it may restart — but a restart loop is easily achieved if the application reconnects to the same malicious server upon boot. If the application is a single-instance service, the outage is total until manual intervention or a redeployment.

Scenario 2 — Network Man-in-the-Middle (Plaintext WebSocket). A victim application connects to a WebSocket server over ws:// (unencrypted) — still common in development, internal tooling, or misconfigured production systems.

1. Reconnaissance: The attacker positions themselves on the network path between the victim and the WebSocket server (shared LAN, compromised router, rogue access point, ARP spoofing on internal segments). The attacker passively observes traffic to identify WebSocket upgrade requests (HTTP GET containing Upgrade: websocket).
2. Trigger: When the victim sends a normal WebSocket upgrade request with no Sec-WebSocket-Protocol header, the attacker injects or modifies the server's 101 response to include a Sec-WebSocket-Protocol header (e.g., by transparent proxy interception and header injection, or by fully spoofing the server response if the legitimate server is slow to respond).
3. Execution: Identical to Scenario 1 — the null dereference and uncaught TypeError terminate the client process.
4. Post-exploitation impact: Full denial of service against the victim node. If the MITM attacker can repeat this against every WebSocket connection the application opens (e.g., an application that periodically reconnects for heartbeats), the application will be unable to stay up at all.

Scenario 3 — Availability-by-Amplification in a Microservice Architecture. In a distributed Node.js deployment, a single crashed instance may cause downstream clients to fail over or retry, effectively amplifying the outage. If the vulnerable Node.js service is itself a gateway to other services, its crash disconnects all dependent clients, broadening the blast radius beyond the single process.

Impact Assessment

Scope and Reach. The vulnerability affects any Node.js application using undici's WebSocket client within the affected version ranges (6.7.0–6.28.1, 7.0.0–7.29.1, 8.0.0–8.10.2). Undici is included as the default HTTP client in Node.js (starting from Node.js 18) and is broadly adopted as a standalone npm dependency. Notably, many applications depend on undici transitively — a direct dependency on undici is not required for exposure. Teams should inspect lock files (package-lock.json, yarn.lock, pnpm-lock.yaml) for undici within the affected ranges.

Availability Impact (A:H). The CVSS impact score is driven entirely by availability. A single offending handshake response terminates the Node.js process — there is no graceful connection failure, no connection-specific error callback, and no partial degradation. This is not a resource-exhaustion or CPU-bound DoS; it is an instantaneous, deterministic process crash.

Confidentiality and Integrity (C:N, I:N). No data exfiltration, data modification, or privilege escalation is possible through this vulnerability. The attack is strictly a denial-of-service primitive.

Blast Radius. The blast radius is a function of what the vulnerable Node.js process was doing. In single-service deployments this means total service unavailability; in microservice orchestrations it triggers restart loops, cascading timeouts, and potential thundering-herd failures when dependent services retry en masse. Applications that open many outbound WebSocket connections (chat bots, payment gateways, trading platforms, server-to-server real-time integration) have the largest attack surface.

Authentication / User Interaction: None. The CVSS PR:N and UI:N confirm this is an unauthenticated, zero-interaction attack. The only precondition is that the application attempts a WebSocket connection that the attacker can influence. Note that even when connecting to a legitimate server, a compromised or hijacked upstream server becomes an instant DoS vector against all its downstream undici clients — making this an attractive pivot for supply-chain-style attacks.

Detection Guidance

Detection of this vulnerability is challenging because the malicious event is a single HTTP response header. The attack produces minimal network footprint (a 101 response with one extra header) and is indistinguishable from a misconfigured — but non-malicious — server. Detection should therefore focus on: (1) identifying Node.js processes crashing with a subprotocol-related TypeError, (2) monitoring outbound WebSocket traffic for unexpected Sec-WebSocket-Protocol response headers, and (3) correlating WebSocket connection attempts against server crashes.

Sigma Rule

The following Sigma rule detects the application-level signature of this crash — a Node.js exception message referencing the subprotocol null dereference — as captured in logs by unhandled-exception handlers, process supervisors, or container orchestration systems.

title: Node.js Undici WebSocket Subprotocol Null Dereference Crash
id: 4f6b2e8a-77c1-4f2d-9a3e-bd5a9c8f2e17
status: experimental
description: >
  Detects Node.js process crash logs referencing an uncaught TypeError
  in undici WebSocket handshake subprotocol validation. CVE-2026-19534.
references:
  - "https://nvd.nist.gov/vuln/detail/CVE-2026-19534"
author: "Valter Sit Threat Intelligence"
date: "2026/04/15"
tags:
  - attack.t1499
  - cve.2026.19534
logsource:
  category: application
  product: nodejs
detection:
  selection_errortype:
    - "TypeError: Cannot read properties of null"
    - "TypeError: Cannot read property 'find' of null"
    - "Cannot read properties of null (reading 'find')"
    - "TypeError: Cannot read properties of undefined"
  selection_module:
    - "undici"
    - "websocket"
    - "fetch"
  selection_phase:
    - "handshake"
    - "opening"
  condition: selection_errortype and selection_module
fields:
  - process.name
  - process.executable
  - node.version
  - error.stack
falsepositives:
  - Other Node.js null-dereference bugs in undici
  - Hand-rolled WebSocket clients with similar unchecked null logic
level: high

YARA Rule

The following YARA rule scans for the crash signature in log files, crash dumps, or console output captured by supervisor processes. It targets the distinctive error text combining the TypeError with undici WebSocket identifiers.

rule CVE_2026_19534_Undici_WebSocket_Null_Deref {
    meta:
        author = "Valter Sit Threat Intelligence"
        description = "Detects log/crash-dump signature of undici WebSocket subprotocol null dereference (CVE-2026-19534)"
        date = "2026-04-15"
        reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-19534"
        cve = "CVE-2026-19534"
        score = 70
    strings:
        $s1 = "TypeError: Cannot read properties of null" ascii wide nocase
        $s2 = "Cannot read properties of null (reading" ascii wide nocase
        $s3 = "undici" ascii wide nocase
        $s4 = "WebSocket" ascii wide nocase
        $s5 = "Sec-WebSocket-Protocol" ascii wide nocase
        $s6 = "101" ascii wide
        $s7 = "uncaughtException" ascii wide nocase
        $s8 = "at processTicksAndRejections" ascii wide nocase   // typical microtask stack marker
    condition:
        uint16(0) == 0x0A0D or uint16(0) == 0x0D0A or filesize < 10MB
        and 1 of ($s1, $s2)
        and $s3 and $s4
        and (1 of ($s5, $s6) or #s3 > 3)
}

Suricata IDS Rule

This Suricata rule detects outbound HTTP/1.1 WebSocket upgrade responses carrying a Sec-WebSocket-Protocol header when the corresponding request did not include one. It is a protocol-anomaly detection rule suitable for deployment on egress SPAN/network taps monitoring outbound client traffic.

alert http any any -> $HOME_NET any (msg:"CVE-2026-19534 Undici WebSocket Unrequested Subprotocol Response (Possible DoS)"; flow:established,to_client; http.response_body; content:"101"; http.protocol; content:"HTTP/1.1"; http.response_line; content:"101"; http.response_line; content:"Sec-WebSocket-Protocol"; http.response_headers; http.request_header; content:"Upgrade"; http.request_header; content:"websocket"; http.request_header; nocase; reference:cve,CVE-2026-19534; reference:url,https://nvd.nist.gov/vuln/detail/CVE-2026-19534; classtype:attempted-dos; sid:202619534; rev:1; metadata:created_at 2026_04_15, updated_at 2026_04_15, cve CVE-2026-19534;)

Detection rationale and limitation. This rule looks for a server's 101 response containing Sec-WebSocket-Protocol. To reduce false positives, correlate with whether the client sent a Sec-WebSocket-Protocol request header — however, Suricata HTTP rules tracking bidirectional header correlation are complex. The rule above therefore errs toward alerting on any 101 response containing Sec-WebSocket-Protocol; SOC analysts must review and filter legitimate subprotocol negotiations before enabling at scale. Analysts can optionally augment with http.request_header checks or a Lua script to match the request/response pair.

Elastic Detection

This EQL query detects Node.js process termination events or application error logs matching the crash signature of this vulnerability in auditbeat/winlogbeat/sysmon-style process lifecycle data and filebeat-collected application logs.

// EQL query for Elastic Security
// Targeted at application crash logs from Node.js processes
sequence by host.name, process.name with maxspan=10s
  [ any where event.code == "application.error" and
    (message like "*Cannot read properties of null*" or message like "*TypeError*") and
    message like "*undici*" ]
  [ any where event.code == "process.terminated" or event.code == "process.exit" ]

For environments where application error logs are ingested as logs-* indices with structured fields:

sequence by host.name, process.name with maxspan=15s
  [ any where message like "*Cannot read properties of null (reading*" ]
  [ any where process.exit_code != 0 and process.name like "*node*" ]

Splunk SPL Query

This Splunk query correlates process crash events (Splunk Universal Forwarder with scripted input or auditd data) with application error signatures referencing the subprotocol dereference.

index=* (sourcetype="*node*" OR sourcetype=stderr OR sourcetype=syslog)
  ("Cannot read properties of null" OR "TypeError")
  "undici"
  OR
  (process=node* AND exit_code!=0)
| stats count by host, process, _time, command
| where count > 0
| eval severity = case(
    searchmatch("Cannot read properties of null (reading*"), "HIGH",
    searchmatch("undici"), "HIGH",
    1=1, "MEDIUM"
  )
| table _time, host, process, count, severity, _raw
| sort - _time

Alternative query for environments capturing HTTP proxy or application-layer access logs with response header telemetry (requires custom log parser to extract response headers):

index=proxy_logs OR index=http_logs
  status=101
  response_header="Sec-WebSocket-Protocol:*"
| stats count by src_ip, dest_ip, url, response_header

Wazuh OSSEC Rule

This Wazuh decoder/rule detects the crash signature in Node.js application logs, syslog, or container output.

<group name="cve-2026-19534,nodejs,denial-of-service,">
  <!-- Decoder for Node.js uncaught exception stack traces referencing undici -->
  <decoder name="nodejs_uncaught_exception">
    <prematch>TypeError: Cannot read properties of null</prematch>
    <regex>TypeError: Cannot read properties of null</regex>
    <order>error_message</order>
  </decoder>

  <rule id="520755" level="12">
    <decoded_as>nodejs_uncaught_exception</decoded_as>
    <field name="error_message">TypeError</field>
    <match>undici</match>
    <description>CVE-2026-19534: Node.js undici WebSocket subprotocol null dereference causing process crash</description>
    <group>cve-2026-19534,nodejs,denial-of-service,</group>
    <mitre>
      <id>T1499</id>
    </mitre>
    <info>Possible unauthenticated remote DoS via malformed WebSocket handshake. Check Node.js version and undici package version.</info>
  </rule>

  <rule id="520756" level="8">
    <decoded_as>nodejs_uncaught_exception</decoded_as>
    <field name="error_message">TypeError</field>
    <match>Sec-WebSocket-Protocol</match>
    <description>CVE-2026-19534 (possible): Node.js WebSocket handshake subprotocol validation failure detected</description>
    <group>cve-2026-19534,nodejs,</group>
  </rule>
</group>

Operational note on detection efficacy. Because this vulnerability produces no distinctive malicious payload and is triggered by a single HTTP header that legitimate servers may also send (for clients that do request subprotocols), network-based detection carries inherent false-positive risk. The highest-fidelity detection signals are: (1) Node.js process crash logs exhibiting the TypeError/undici signature — these are unambiguous when correlated with recent WebSocket activity; and (2) outbound WebSocket handshake correlation showing a 101 response with Sec-WebSocket-Protocol where the request had no such header.

Mitigation & Patch Guidance

Patch confidence: 0/4 — UNPATCHED (no patch evidence from any tracked source). While the NVD description lists fixed versions (6.28.1, 7.29.1, 8.10.2), our tracked independent sources have not yet confirmed the availability of these releases. Treat these version numbers as the vendor's intended fixes and verify their existence and integrity before deploying.

Risk posture: No public exploit code or PoC is available (POC_STATUS: None), and the CVE is not on the CISA KEV catalog. However, the attack is trivially reproducible by any competent developer or penetration tester — a 101 response with a single header line — meaning weaponized exploits are likely to appear quickly once the vulnerability is publicly understood.

1) Immediate Mitigations (until patch verification and deployment)

• Upgrade undici to the newest available version in your dependency tree immediately. Verify that the fix version exists (npm view undici versions) and confirm the version resolves CVE-2026-19534.
• If upgrade is impossible, audit and restrict all outbound WebSocket connections to trusted, verified servers:
  • Review every ws:// (plaintext) connection and migrate to wss:// (TLS) — TLS eliminates the MITM trigger vector.
  • For wss:// connections, pin certificates or at minimum validate certificates strictly; do not disable certificate verification.
  • Restrict outbound network egress via firewall/security groups so Node.js processes can only reach approved WebSocket endpoints.
• Add defensive error handling in application code: register a process-level process.on('uncaughtException', handler) that logs and gracefully shuts down instead of crashing outright — this converts a hard crash into a controlled degrade. Note this does not fix the vulnerability; it merely changes the failure mode from abrupt termination to shutdown-with-logging, and may mask the issue during incident triage.
• Run Node.js under a supervisor (systemd, PM2, Docker restart policy) with crash-loop backoff limits to prevent rapid restart churn in the event of attack.
• Monitor for crash signatures immediately after deploying the detection rules above; treat any Node.js crash containing "undici" plus "null" as a potential exploitation event.

2) Patch / Upgrade Steps

Assuming the fixed releases are verified available:

# For projects depending on undici directly:
npm install undici@^8.10.2    # or ^7.29.1 / ^6.28.1 per your major version
# Then update lockfile and commit:
npm audit fix

For projects depending on undici transitively:

1. Run npm ls undici to identify the dependency chain.
2. Use npm overrides (npm ≥ 8.3) to force undici to a patched version:

{
  "overrides": {
    "undici": "^8.10.2"
  }
}

3. For Yarn Berry: use resolutions in package.json.
4. Re-run the full test suite with particular attention to WebSocket connections and error paths.
5. Deployment sequence: stage → integration test → production rollout. Roll out to a canary group first.

3) Long-Term Hardening

• Eliminate plaintext WebSocket (ws://) usage across the enterprise. Mandate wss:// in code review and CI linting.
• Adopt network policies that restrict server-side egress from application containers/pods to an allowlist of destinations (Kubernetes NetworkPolicy, AWS Security Groups, calico network policies).
• Embed dependency vulnerability scanning into CI/CD (e.g., npm audit, Snyk, Dependabot, or Trivy in the build pipeline) with a fail-on-high-vulnerability gate.
• Standardize on a graceful-degradation pattern for uncaught exceptions in Node.js microservices: log with full stack, attempt in-flight request draining, and exit cleanly so orchestrators can restart without data corruption.
• Consider runtime hardening: run Node.js under --abort-on-uncaught-exception is not recommended (it creates core dumps that may contain sensitive data). Instead, consistently capture and forward crash logs to a SIEM for correlation with the detection rules above.
• For security teams: subscribe to NVD and GitHub Advisory Database notifications for undici; this vulnerability class (uncaught exception from malformed protocol input) may appear in sibling code paths.

References

1. NVD Entry for CVE-2026-19534 — https://nvd.nist.gov/vuln/detail/CVE-2026-19534
2. undici GitHub Repository (release history / fix commits for 6.28.1, 7.29.1, 8.10.2) — https://github.com/nodejs/undici/releases
3. undici npm Package Registry (verify fixed versions and dependency provenance) — https://www.npmjs.com/package/undici
4. RFC 6455 — The WebSocket Protocol (subprotocol negotiation semantics §4.2.2, §11.3.4) — https://datatracker.ietf.org/doc/html/rfc6455
5. FIRST.org CVSS v3.1 Calculator (for CVSS vector validation) — https://www.first.org/cvss/calculator/3.1

Threat actor activity: No known threat actor campaigns or exploit-in-the-wild evidence exist at the time of writing. POC_STATUS: None; the CVE is not listed on the CISA Known Exploited Vulnerabilities (KEV) catalog. This is likely a pre-disclosure or early-publication state; given the trivial nature of the trigger condition, security teams should assume weaponization is imminent once the fixed versions and diff are publicly studied.