CVE-2026-73561

CVE-2026-73561 is a resource exhaustion vulnerability in a Node.js WebSocket library where the server initiates an RPC request with a 10ms polling loop immediately upon WebSocket connection — before any authentication occurs — with no cleanup handler when the socket closes. The result is orphaned timers that accumulate indefinitely, eventually consuming CPU and memory under normal connection churn. The core problem is that the library models RPC request-response semantics (synchronous, bounded exchange) onto WebSocket connections (asynchronous, bidirectional, terminable at any moment). Every time a client opens a socket and drops it — which is normal client behavior during network instability, probing, or simple application startup — the server starts a polling loop that never terminates. With no close handler registered, those timers persist until process restart. What makes this severe is the pre-authentication placement. The RPC call happens during the connection handshake, before the server has any evidence the client is legitimate. This means any client that can reach port 8080 can trigger the leak with zero credentials or special conditions. It's a maximum-reach DoS vector at your perimeter. The fix in version 0.2.16 adds a socket close handler that cleans up pending RPC state. This is correct but reveals a deeper architectural concern: the original code never modeled connection termination as a first-class concern. The polling interval choice (10ms) was likely set for responsiveness without considering what orphaned instances would cost under load. The pre-authentication placement remains unchanged — the library still trusts unauthenticated connections with blocking synchronous work. For defenders: upgrade to 0.2.16 immediately. Verify the close handler exists in your deployed version by checking for 'removeListener("close", ...)' or equivalent cleanup in the RPC module. More importantly, audit any WebSocket libraries in your stack for the same pattern — polling or stateful operations initiated before authentication without registered teardown. This exact pattern has appeared in Java RMI, .NET Remoting, early Comet implementations, and now Node.js WebSocket libraries. The recurrence suggests it should be treated as a known anti-pattern class rather than a one-off vulnerability.

Reviewed through automated stages and approved by a human before publication.