CVE-2026-45736

What it actually does

The flaw is an information disclosure issue in the Node.js `ws` WebSocket library before version 8.20.1. When application code calls `websocket.close()` and supplies a `TypedArray` as the close `reason`, the library can include uninitialized memory in the WebSocket close frame. If an attacker can influence that close reason or trigger vulnerable server-side/client-side code paths, bytes from process memory may be sent over the network. The impact is limited to confidentiality; there is no known direct integrity or availability impact.

Why it matters to the business

Applications using vulnerable versions of `ws` may unintentionally leak sensitive data from Node.js process memory to a connected WebSocket peer. Depending on what the process handles, leaked memory could contain fragments of tokens, session data, application messages, credentials, or other confidential information. The CVSS score is moderate and EPSS is currently low, with no known KEV listing or public exploit maturity reported, but exposure should still be addressed because `ws` is a widely used dependency in Node.js applications and may be present transitively through frameworks or real-time communication components.

How an attack unfolds

An attacker first needs access to a WebSocket endpoint implemented with a vulnerable version of `ws`. Exploitation is application-dependent: the attacker must be able to influence a code path where the application calls `websocket.close()` with a `TypedArray` value as the `reason` argument, or otherwise interact with functionality that causes the vulnerable close operation to occur. When that close frame is generated, the vulnerable implementation may serialize memory that was not initialized for that close reason. The attacker receives the close frame and inspects the reason payload for unintended memory contents. Practical exploitation is constrained by the need for a specific vulnerable code path and by the limited size/content of leaked memory, but repeated triggering may increase the chance of capturing useful fragments.

How to fix it

Upgrade the `ws` package to version 8.20.1 or later. Because `ws` is often included as a transitive dependency, review lockfiles and dependency trees, not only direct dependencies. Use package-manager overrides or resolutions where necessary to force vulnerable transitive versions to a fixed release. If immediate upgrade is not possible, audit application code and dependent packages for calls to `websocket.close()` or `close()` that pass `TypedArray`, `Uint8Array`, `Buffer` views, or other non-string close reasons, and change them to pass a safe string reason or omit the reason entirely. Restrict access to WebSocket endpoints where feasible and avoid exposing unauthenticated or broadly reachable WebSocket services until patched.

How to confirm the fix worked

Confirm that all deployed applications resolve `ws` to version 8.20.1 or later by checking package manifests, lockfiles, container images, and runtime dependency output such as `npm ls ws`, `pnpm why ws`, or `yarn why ws`. Rebuild and redeploy artifacts after updating dependencies to ensure the fixed package is actually present in production images. Review source and bundled code for `close()` calls that pass typed arrays or derived binary views as the reason argument. Where practical, perform a controlled WebSocket test against representative endpoints and verify that close frames do not contain unexpected binary data or memory fragments. Software composition analysis and CI dependency checks should be updated to fail builds that include `ws` versions below 8.20.1.

Typical attack path

1. Identify a WebSocket service or client component using the Node.js `ws` library before 8.20.1.
2. Establish a WebSocket connection to the affected endpoint or interact with a feature that uses WebSockets internally.
3. Trigger application behavior that closes the WebSocket connection and passes a `TypedArray` as the close reason.
4. Capture the WebSocket close frame returned by the vulnerable implementation.
5. Inspect the close reason payload for unintended bytes from Node.js process memory.
6. Repeat the interaction, where possible, to collect additional leaked fragments.

How to detect it

There are no reliable universal host-based indicators that prove exploitation, because the vulnerability leaks data through normal WebSocket close frames and may not create errors or files. Detection should focus on historical WebSocket telemetry, application logs, reverse-proxy logs, and packet captures where available. Look for repeated WebSocket connections from the same source that quickly close, abnormal close behavior, unusual close reason payloads, binary-looking close reasons, or spikes in close frames around features that can influence connection termination. If full packet capture or WebSocket-aware proxy logs exist, inspect close frames from affected services for reason payloads containing unexpected binary data, fragments of application messages, credentials, tokens, JSON snippets, HTTP headers, or other memory-like content. Review application logs for exceptions or debug output around `websocket.close()` calls with non-string reason values. Because EPSS is low and no known KEV exploitation is reported, absence of such evidence reduces concern but does not conclusively rule out exploitation.

What your security team should do

• Inventory applications, services, containers, and serverless functions that use the Node.js `ws` package directly or transitively.
• Prioritize externally reachable WebSocket services and applications that process sensitive data in the same Node.js process.
• Upgrade `ws` to 8.20.1 or later and redeploy affected artifacts.
• Use dependency overrides/resolutions if a parent package has not yet updated its `ws` dependency.
• Search source code for `websocket.close()` or similar close calls that pass `TypedArray`, `Uint8Array`, `Buffer`, or array-buffer-derived values as the reason.
• Add software composition analysis rules to detect `ws` versions before 8.20.1 in CI/CD and container registries.
• Review WebSocket access logs and packet captures, if available, for unusual repeated connection closures that may indicate probing.
• Treat any confirmed memory disclosure as a potential secret exposure event and rotate exposed credentials or tokens if sensitive data is found.