CVE-2026-73561 in hub
Summary
by MITRE • 08/13/2026
Hub is a Node.js WebSocket server and client with added features. Prior to 0.2.16, every incoming unauthenticated WebSocket connection triggers loadDefaultConnectionEventListeners to call requestClientId, which calls rpc.send for the get-client-id action and pushes a request into RPC.requests. The RPC.waitForReply function starts a setInterval polling loop every 10 milliseconds that is cleared only after a matching reply; if the client remains silent and closes, the timer and pending request stay allocated because the socket close path does not cancel them. Repeated connections therefore cause unbounded timers and heap entries, exhausting CPU and memory and making the server unavailable. This issue is fixed in version 0.2.16.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 08/13/2026
This vulnerability exists within the Hub Node.js WebSocket implementation where improper handling of unauthenticated connections creates a persistent resource leak scenario. The flaw stems from the loadDefaultConnectionEventListeners function which automatically invokes requestClientId for every incoming connection regardless of authentication status. This process initiates an RPC communication sequence by calling rpc.send with the get-client-id action, subsequently adding entries to the RPC.requests collection. The system employs a polling mechanism through RPC.waitForReply that establishes a setInterval loop executing every ten milliseconds to monitor for response replies. Critical design failure occurs when the socket close event handler fails to properly terminate these active timers and clear pending requests from memory. This omission creates a memory leak where each disconnected client leaves behind allocated timer objects and request entries in the RPC.requests queue. The vulnerability represents a classic resource exhaustion attack vector that can be exploited through repeated connection and disconnection cycles, with each iteration consuming additional CPU cycles and heap memory without proper cleanup.
The technical implementation flaw aligns with CWE-404, which addresses improper resource release or reclamation, specifically manifesting as an uncontrolled resource consumption vulnerability. The issue demonstrates characteristics of CWE-674, where an application performs operations on resources without proper termination mechanisms, leading to accumulation of orphaned objects. From an ATT&CK framework perspective, this vulnerability maps to T1499.004, which covers resource exhaustion attacks targeting network services through connection flooding or resource consumption manipulation. The polling mechanism creates a persistent loop that continuously consumes system resources even when no active communication is occurring, effectively creating a denial of service condition. The vulnerability's impact escalates with repeated exploitation attempts, as each new connection adds to the growing memory footprint and CPU overhead.
The operational consequences of this vulnerability are severe and directly impact system availability and stability. As attackers repeatedly establish and terminate WebSocket connections, the server experiences progressive degradation in performance due to accumulating timers and request entries. Memory consumption grows unbounded until system resources are exhausted, leading to application crashes or complete service unavailability. The continuous polling loops consume CPU cycles unnecessarily, potentially affecting other services running on the same system. Network bandwidth utilization increases through constant timer operations without corresponding data transmission, creating network congestion issues. The vulnerability is particularly dangerous in high-traffic environments where multiple clients connect simultaneously, as the resource consumption grows exponentially with concurrent connection attempts.
The remediation strategy requires implementing proper cleanup mechanisms within the socket close event handler to ensure all associated timers and request entries are properly terminated. Version 0.2.16 addresses this by ensuring that RPC.waitForReply does not leave dangling timers when connections close without response. The fix should include explicit cancellation of setInterval loops through clearTimeout calls and removal of entries from RPC.requests collections during connection termination. Security best practices recommend implementing proper resource management patterns including try-finally blocks or event listener cleanup mechanisms to prevent resource leaks. Additionally, implementing connection rate limiting and authentication checks can reduce the attack surface by preventing unauthorized connections from triggering the vulnerable code path. Regular monitoring and alerting systems should be deployed to detect unusual memory consumption patterns that may indicate exploitation attempts. Implementing proper timeout mechanisms for RPC requests and ensuring timely cleanup of all allocated resources during connection lifecycle events will effectively mitigate this vulnerability and prevent future occurrences.