GHSA-5v72-xg48-5rpm

What it actually does

This issue is a denial-of-service vulnerability in WebSocket handling. A remote peer can send specially crafted WebSocket data that triggers excessive resource consumption or inefficient processing in vulnerable implementations. Successful exploitation can cause the affected process to become slow, consume disproportionate CPU or memory, stop responding, or crash, interrupting WebSocket-based services. The vulnerability does not inherently provide code execution, privilege escalation, or data disclosure, but it can degrade or disable application availability.

Why it matters to the business

Applications that expose WebSocket endpoints using vulnerable versions of ws or affected Go crypto-related dependencies may be disrupted by unauthenticated network traffic. Business impact can include service outages, degraded real-time features, failed customer sessions, increased infrastructure cost from resource exhaustion, and operational load during incident response. Although this issue is older, its CVSS 7.5 severity and availability impact make it relevant where legacy dependencies remain in production, especially for internet-facing applications or high-traffic real-time services.

How an attack unfolds

An attacker first identifies an application that accepts WebSocket connections and is built with a vulnerable version of the affected package. The attacker then establishes one or more WebSocket connections and sends malformed or resource-intensive frames designed to trigger the vulnerable parsing or processing behavior. The vulnerable service spends excessive resources handling those frames or reaches an error condition that affects process stability. By repeating the traffic or opening multiple concurrent connections, the attacker can amplify the effect until the service becomes degraded or unavailable to legitimate users. No authentication or application-level access is typically required if the WebSocket endpoint is publicly reachable.

How to fix it

Upgrade affected dependencies to fixed versions or later. For npm ws, upgrade to version 1.1.5 or later for the 1.x line, or 3.3.1 or later for the 3.x line; preferably upgrade to a currently supported modern release if compatible. For golang.org/x/crypto, upgrade to 0.0.0-20220525230936-793ad666bf5e or later. Rebuild and redeploy all applications that statically bundle or vendor these dependencies. If immediate patching is not possible, reduce exposure by restricting WebSocket endpoints to trusted networks where feasible, enforce request and connection rate limits, cap frame/message sizes, configure idle and read timeouts, limit concurrent connections per source, and place protective controls such as a reverse proxy or WebSocket-aware gateway in front of the service.

How to confirm the fix worked

Confirm that software composition analysis, package lockfiles, vendored modules, and built artifacts no longer contain vulnerable versions of ws or golang.org/x/crypto. For Node.js applications, inspect package-lock.json, yarn.lock, pnpm-lock.yaml, npm ls ws, or equivalent dependency manifests to verify resolved versions are fixed. For Go applications, inspect go.mod, go.sum, vendor directories, and build SBOMs to verify golang.org/x/crypto is at or beyond the fixed pseudo-version. After deployment, run dependency scans against the deployed artifact, not only the source repository. Validate operational controls by testing connection limits, frame/message size limits, idle timeouts, and WebSocket error handling in a controlled environment. Monitor service health during benign WebSocket fuzzing or load testing to ensure malformed frames do not cause crashes or disproportionate resource consumption.

Typical attack path

1. Discover an internet-facing application or API that exposes WebSocket functionality.
2. Fingerprint the service or infer use of vulnerable WebSocket libraries from application behavior, dependency metadata, or version disclosure.
3. Open one or more WebSocket connections to the vulnerable endpoint.
4. Send crafted WebSocket frames or traffic patterns that trigger excessive processing or failure in the vulnerable implementation.
5. Repeat or parallelize the requests to increase CPU, memory, connection, or process pressure.
6. Cause service degradation, crashes, restarts, failed user sessions, or temporary unavailability.

How to detect it

Look for evidence of abnormal WebSocket activity followed by service degradation. Relevant log sources include reverse proxy and load balancer logs, application access logs, WebSocket gateway logs, application error logs, process supervisor logs, container orchestration events, host resource telemetry, and crash/restart records. Investigate spikes in HTTP Upgrade requests, unusually high counts of connections to WebSocket paths, repeated 400/500-series responses during WebSocket handshakes or frame processing, malformed frame or protocol errors, abrupt connection resets, and increases in CPU, memory, file descriptor, or event-loop latency. Correlate these events with application restarts, out-of-memory kills, health-check failures, autoscaling events, or user-facing availability incidents. Because there are no universally unique payload indicators for this advisory, detection should focus on behavioral patterns: many WebSocket connections or malformed frames from the same source or subnet, repeated connection churn, and resource exhaustion shortly after WebSocket traffic bursts.

• HTTP header: Upgrade: websocket
• HTTP header: Connection: Upgrade
• Sec-WebSocket-Key
• Sec-WebSocket-Version
• WebSocket error
• websocket error
• invalid WebSocket frame
• invalid websocket frame
• malformed WebSocket frame
• malformed websocket frame
• WebSocket protocol error
• websocket protocol error
• unexpected RSV
• invalid opcode
• invalid close code
• frame too large
• message too large
• ECONNRESET
• socket hang up
• out of memory
• OOMKilled
• JavaScript heap out of memory
• fatal error: runtime: out of memory

What your security team should do

• Prioritize remediation for internet-facing services, APIs, collaboration tools, streaming features, dashboards, and other applications that maintain WebSocket connections.
• Inventory applications using ws or golang.org/x/crypto, including transitive dependencies and vendored copies.
• Upgrade ws to 1.1.5, 3.3.1, or later as appropriate, and upgrade golang.org/x/crypto to 0.0.0-20220525230936-793ad666bf5e or later.
• Rebuild and redeploy affected applications after dependency updates because vulnerable code may be bundled into compiled or packaged artifacts.
• Add or verify WebSocket-specific rate limits, message size limits, connection limits, and idle/read timeouts at the application and reverse-proxy layers.
• Review historical availability incidents, crashes, and traffic spikes against WebSocket endpoints for signs of attempted exploitation.
• Add monitoring and alerting for abnormal WebSocket connection volume, repeated malformed-frame errors, high CPU or memory use, and process restarts.
• Document compensating controls for any legacy application that cannot be immediately upgraded and track it as an availability risk.