npm ws Security: Fixing the CVE-2024-37890 WebSocket DoS

The npm ws package is safe once you upgrade to a patched release — 8.17.1, 7.5.10, 6.2.3, or 5.2.4 depending on your major version — which closes CVE-2024-37890, a denial-of-service flaw where a request with too many headers could crash the WebSocket server. If you run real-time features on Node, ws is almost certainly in your tree, so this one is worth confirming rather than assuming.

ws is the de facto WebSocket implementation for Node.js. It is the transport under Socket.IO, under many GraphQL subscription servers, under live-reload dev tooling, and under countless bespoke real-time backends. Because it sits so deep in the stack, most teams pull it in transitively without ever adding it to package.json directly.

What CVE-2024-37890 actually does

CVE-2024-37890 is a denial-of-service vulnerability in ws. The trigger is simple: a client sends an HTTP request whose number of headers exceeds the server's maxHeadersCount threshold. Handling that request could crash the ws server process.

The mechanics matter because they explain why this is easy to exploit and hard to notice. When Node's HTTP parser receives more headers than allowed, ws mishandled the resulting condition during the upgrade handshake. An attacker does not need authentication, a valid WebSocket session, or any application-level access. They only need to open a connection and send a bloated header set. One unauthenticated request can take down the process, and a script can repeat it.

Because the crash happens during connection setup, request logging and application-level rate limits that key off completed requests may not even record the attack cleanly.

Which versions are affected and fixed

The fix was released in ws@8.17.1 and backported to the older supported lines. The patched versions are:

• v8.x: 8.17.1 or later
• v7.x: 7.5.10 or later
• v6.x: 6.2.3 or later
• v5.x: 5.2.4 or later

Anything below the relevant line for your major version is vulnerable. Note the backports: you do not have to jump to v8 if you are on an older major, because the maintainers patched v5, v6, and v7 as well.

Finding ws in your dependency tree

The first practical step is discovering which version you actually resolved, which is rarely the version anyone chose on purpose:

npm ls ws

You will often see several copies at different versions because different parents pin different ranges. Every one of them needs to satisfy the patched threshold. If a copy is stuck below the fix because a parent package pins an old range, you have three options: upgrade the parent, use an overrides block, or (as a stopgap) apply the runtime mitigation described below.

{
  "overrides": {
    "ws": "^8.17.1"
  }
}

Use overrides deliberately — forcing a major version bump on a transitive dependency can break the parent that expected the old API, so test after applying it.

The runtime mitigation when you cannot upgrade immediately

If an upgrade is blocked, CVE-2024-37890 can be mitigated at the Node layer by limiting how many headers a request is allowed to carry, so a client cannot exceed server.maxHeadersCount. Two levers:

• Reduce the maximum request header size with the --max-http-header-size flag or the maxHeaderSize option, so no client can pack in more headers than the limit permits.
• Alternatively, set server.maxHeadersCount to 0, which removes the count limit that the crash keyed on.

node --max-http-header-size=16384 server.js

Treat this as a bridge, not a destination. The clean fix is the version bump; the flag buys you time to schedule it.

Hardening a WebSocket endpoint beyond this CVE

A single patched dependency is not a WebSocket security posture. A few controls pay off repeatedly:

• Validate Origin on the upgrade. Reject cross-origin handshakes you do not expect to blunt cross-site WebSocket hijacking.
• Cap connections and message size. ws supports maxPayload; set it so a client cannot send an unbounded frame.
• Rate-limit handshakes per IP at the load balancer or reverse proxy, which also dampens the header-flood pattern.
• Authenticate before upgrade. Verify a token during the HTTP handshake rather than trusting the first WebSocket message.

These are generic, but CVE-2024-37890 is a reminder that the handshake path — before any of your application code runs — is attacker-reachable and needs its own limits.

Keeping ws patched automatically

WebSocket libraries handle raw, untrusted network input, so they are a natural place for periodic vulnerabilities. The durable answer is automation: run dependency scanning in CI so a new ws advisory opens a pull request quickly, and keep an eye on transitive pins that lag behind. Our writeup on software composition analysis explains how a lockfile decides your real exposure, which is the crux for a package as deeply transitive as ws.

FAQ

What is the fixed version for CVE-2024-37890 in ws?

Upgrade to 8.17.1 on the v8 line, 7.5.10 on v7, 6.2.3 on v6, or 5.2.4 on v5. Any of these closes the DoS.

Can I exploit CVE-2024-37890 without authentication?

Yes, which is what makes it serious. The crash happens during the connection handshake, so an unauthenticated client sending enough request headers can take down the server.

I do not use ws directly. Am I still affected?

Probably still relevant. ws is pulled in transitively by Socket.IO, GraphQL subscription servers, and dev tooling. Run npm ls ws to see every resolved copy.

Is there a fix that does not require upgrading?

You can mitigate by limiting request header size with --max-http-header-size or maxHeaderSize, or by setting server.maxHeadersCount to 0. Treat these as temporary measures until you can upgrade.