CVE-2026-73561

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.

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.

Summary

@anephenix/hub starts a setInterval polling loop for every incoming WebSocket connection to request a client ID via RPC. If the remote client never replies — which requires no authentication or special configuration — the interval and the pending request object are never cleaned up, even after the socket is closed. An unauthenticated attacker who opens many WebSocket connections and ignores all server RPC messages will therefore cause the server to accumulate unbounded timers and heap entries, leading to CPU and memory exhaustion (DoS).

Details

When a client connects, loadDefaultConnectionEventListeners (registered in src/lib/index.ts:128) adds a connection listener that calls requestClientId({ ws, rpc }) for every new WebSocket (src/lib/index.ts:262). requestClientId issues an RPC send for the get-client-id action (src/lib/clientId.ts:112), which internally calls rpc.send.

Inside rpc.send, the payload is pushed onto this.requests (src/lib/rpc.ts:282) and waitForReply is invoked. waitForReply starts a setInterval that polls responses[] every 10 ms for a matching reply (src/lib/rpc.ts:250):

// src/lib/rpc.ts:250–267
interval = setInterval(() => {
    const response = responses.find(
        (r) => r.id === id && r.action === action,
    );
    if (response) {
        if (interval) clearInterval(interval);
        // ... resolve and cleanup
        this.cleanupRPCCall(response);
    }
}, 10);

clearInterval is only called when a matching response arrives. There is no timeout path and no socket-close handler that clears either the interval or the this.requests entry. The close handler registered in loadDefaultConnectionEventListeners (src/lib/index.ts:128–134) only calls pubsub.unsubscribeClientFromAllChannels; it does not cancel pending RPC requests for that socket.

Data flow (source → sink):

1. src/lib/index.ts:269 — wss.on("connection") accepts any remote WebSocket (no authentication).
2. src/lib/index.ts:272 — connection listeners are iterated and invoked.
3. src/lib/index.ts:262 — requestClientId({ ws, rpc: this.rpc }) is called for every connection by default.
4. src/lib/clientId.ts:112 — rpc.send({ ws, action: 'get-client-id' }) creates an RPC request.
5. src/lib/rpc.ts:282 — this.requests.push(payload) registers the pending request.
6. src/lib/rpc.ts:250 — setInterval(..., 10) begins infinite polling; cleanup only happens on a matching response. Socket close does not trigger cleanup.

PoC

Prerequisites: Docker must be available on the host.

Step 1 — Build the verification image:

docker build --no-cache \
  -f vuln-001/Dockerfile \
  -t hub-vuln-001:latest \
  reports/npm_web_272_anephenix__hub

Step 2 — Run the container:

docker run --rm --network none hub-vuln-001:latest

The container runs verify.mjs, which:

1. Starts a Hub server on a local port.
2. Opens a WebSocket and waits for the server's get-client-id RPC message without replying.
3. Closes the socket and waits 300 ms.
4. Inspects hub.rpc.requests.length — it must remain 1 even though hub.wss.clients.size is 0.
5. Opens five more sockets the same way (batch), then verifies that pendingRpcRequests equals 6.

Step 3 — Alternatively, run the Python orchestrator directly:

python3 vuln-001/poc.py

Expected output (confirmed):

{
  "snapshotAfterClose":  {"clientState": 3, "serverClients": 0, "pendingRpcRequests": 1},
  "snapshotAfterBatch":  {"serverClients": 0, "pendingRpcRequests": 6, "expectedPendingRpcRequests": 6}
}

pendingRpcRequests grows linearly with the number of unanswered connections and never decreases, confirming the unbounded resource leak.

Minimal inline reproduction (without Docker, inside the repository after npm ci && npm run build):

node --input-type=module - <<'EOF'
import Hub from…

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.

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.

Summary

@anephenix/hub starts a setInterval polling loop for every incoming WebSocket connection to request a client ID via RPC. If the remote client never replies — which requires no authentication or special configuration — the interval and the pending request object are never cleaned up, even after the socket is closed. An unauthenticated attacker who opens many WebSocket connections and ignores all server RPC messages will therefore cause the server to accumulate unbounded timers and heap entries, leading to CPU and memory exhaustion (DoS).

Details

When a client connects, loadDefaultConnectionEventListeners (registered in src/lib/index.ts:128) adds a connection listener that calls requestClientId({ ws, rpc }) for every new WebSocket (src/lib/index.ts:262). requestClientId issues an RPC send for the get-client-id action (src/lib/clientId.ts:112), which internally calls rpc.send.

Inside rpc.send, the payload is pushed onto this.requests (src/lib/rpc.ts:282) and waitForReply is invoked. waitForReply starts a setInterval that polls responses[] every 10 ms for a matching reply (src/lib/rpc.ts:250):

// src/lib/rpc.ts:250–267
interval = setInterval(() => {
    const response = responses.find(
        (r) => r.id === id && r.action === action,
    );
    if (response) {
        if (interval) clearInterval(interval);
        // ... resolve and cleanup
        this.cleanupRPCCall(response);
    }
}, 10);

clearInterval is only called when a matching response arrives. There is no timeout path and no socket-close handler that clears either the interval or the this.requests entry. The close handler registered in loadDefaultConnectionEventListeners (src/lib/index.ts:128–134) only calls pubsub.unsubscribeClientFromAllChannels; it does not cancel pending RPC requests for that socket.

Data flow (source → sink):

1. src/lib/index.ts:269 — wss.on("connection") accepts any remote WebSocket (no authentication).
2. src/lib/index.ts:272 — connection listeners are iterated and invoked.
3. src/lib/index.ts:262 — requestClientId({ ws, rpc: this.rpc }) is called for every connection by default.
4. src/lib/clientId.ts:112 — rpc.send({ ws, action: 'get-client-id' }) creates an RPC request.
5. src/lib/rpc.ts:282 — this.requests.push(payload) registers the pending request.
6. src/lib/rpc.ts:250 — setInterval(..., 10) begins infinite polling; cleanup only happens on a matching response. Socket close does not trigger cleanup.

PoC

Prerequisites: Docker must be available on the host.

Step 1 — Build the verification image:

docker build --no-cache \
  -f vuln-001/Dockerfile \
  -t hub-vuln-001:latest \
  reports/npm_web_272_anephenix__hub

Step 2 — Run the container:

docker run --rm --network none hub-vuln-001:latest

The container runs verify.mjs, which:

1. Starts a Hub server on a local port.
2. Opens a WebSocket and waits for the server's get-client-id RPC message without replying.
3. Closes the socket and waits 300 ms.
4. Inspects hub.rpc.requests.length — it must remain 1 even though hub.wss.clients.size is 0.
5. Opens five more sockets the same way (batch), then verifies that pendingRpcRequests equals 6.

Step 3 — Alternatively, run the Python orchestrator directly:

python3 vuln-001/poc.py

Expected output (confirmed):

{
  "snapshotAfterClose":  {"clientState": 3, "serverClients": 0, "pendingRpcRequests": 1},
  "snapshotAfterBatch":  {"serverClients": 0, "pendingRpcRequests": 6, "expectedPendingRpcRequests": 6}
}

pendingRpcRequests grows linearly with the number of unanswered connections and never decreases, confirming the unbounded resource leak.

Minimal inline reproduction (without Docker, inside the repository after npm ci && npm run build):

node --input-type=module - <<'EOF'
import Hub from…