GHSA-9MQV-5HH9-4CGG: Unauthenticated Memory-Leak Denial of Service in @hono/node-server WebSocket Handshake Parser

The Hono Node.js adapter, @hono/node-server, facilitates hosting Hono applications within a Node.js runtime environment. A key component of this adapter is its WebSocket support, which handles the handshaking and upgrading of HTTP connections to WebSocket connections. This implementation exposes a public attack surface through any route configured to upgrade connections via the upgradeWebSocket utility.

The vulnerability identified under GHSA-9MQV-5HH9-4CGG is a memory leak occurring during the WebSocket handshake process. If a client initiates a handshake that subsequently fails or is aborted before completion, the server fails to clean up internal state structures. This results in uncontrolled resource consumption (CWE-400), potentially leading to process termination due to heap exhaustion.

An unauthenticated remote attacker can exploit this condition by sending a flood of invalid or aborted WebSocket upgrade requests. Each failed handshake permanently leaks the associated request objects, pending Promise contexts, and network socket descriptors. Over time, this cumulative resource leak exhausts the available V8 heap memory, resulting in a Denial of Service (DoS).

The root cause of GHSA-9MQV-5HH9-4CGG lies in how the @hono/node-server adapter tracks and processes pending WebSocket handshakes. The application utilizes a module-level Map named waiterMap to associate incoming HTTP upgrade requests with their corresponding pending Promise resolution callbacks. The keys in this Map are the strong references to the request's IncomingMessage objects.

When an upgrade request is received, the adapter initializes a new Promise using the waitForWebSocket function and inserts the request and its resolve callback into waiterMap. Under a successful handshake scenario, the underlying WebSocket server (utilizing the ws library) completes the connection and fires a connection event. The event handler retrieves the corresponding entry from waiterMap, invokes resolve, and deletes the key-value pair to free the resources.

If the handshake is aborted, such as when a client provides an invalid Sec-WebSocket-Key or drops the connection abruptly, the connection event is never triggered. Because the vulnerable implementation does not register any listeners for failed or aborted connections, the entry is never removed from waiterMap. Consequently, the Promise remains permanently in a pending state, and the strongly-referenced IncomingMessage and associated V8 lexical scopes are shielded from garbage collection.

To understand the precise code-level flaw, we examine the vulnerable design in src/websocket.ts. In the original implementation, the waiterMap only tracked the success resolver:

const waiterMap = new Map<
  IncomingMessage,
  { resolve: (ws: WebSocketLike) => void; connectionSymbol: symbol }
>()

The corresponding helper function registered the pending state without any mechanism to handle errors or abort signals:

const waitForWebSocket: WaitForWebSocket = (request, connectionSymbol) => {
  return new Promise<WebSocketLike>((resolve) => {
    waiterMap.set(request, { resolve, connectionSymbol })
  })
}

The patch implemented in commit 3a21938c418340e980cb7ffa88e78369f78392d1 corrects this by introducing active rejection capabilities and tying the promise lifetime to the physical socket's close event.

First, the waiterMap is modified to include a reject handler:

const waiterMap = new Map<
  IncomingMessage,
  {
    resolve: (ws: WebSocketLike) => void
    reject: (reason: Error) => void
    connectionSymbol: symbol
  }
>()

Second, a reclamation routine rejectWaiter is introduced to safely delete and reject the outstanding waiter:

const rejectWaiter = (request: IncomingMessage) => {
  const waiter = waiterMap.get(request)
  if (waiter) {
    waiterMap.delete(request)
    waiter.reject(new Error('WebSocket handshake aborted'))
  }
}

Third, the socket lifecycle is actively monitored during the upgrade process. A listener is attached to the socket's close event to ensure cleanup happens if the handshake fails:

const reclaimWaiterOnClose = () => rejectWaiter(request)
socket.once('close', reclaimWaiterOnClose)
 
wss.on('headers', addResponseHeaders)
try {
  wss.handleUpgrade(request, socket, head, (ws) => {
    socket.off('close', reclaimWaiterOnClose)
    wss.emit('connection', ws, request)
  })
} finally {
  // Ensure synchronous exceptions do not bypass standard execution flow
}

Exploitation of this memory-leak vulnerability requires no authentication and can be executed via a low-bandwidth, unauthenticated attack path. The attacker targets any endpoint on the Hono server configured to support WebSocket upgrades.

The attack begins by establishing a standard TCP connection to the target port. Once connected, the attacker transmits a malformed HTTP GET request mimicking a WebSocket upgrade. By omitting or corrupting a mandatory header, such as sending Sec-WebSocket-Key: not-a-valid-key, the attacker forces the underlying ws engine to terminate the upgrade process and respond with an HTTP 400 Bad Request status code.

Following the receipt of the error response, or immediately after transmitting the payload, the attacker closes the TCP connection. On vulnerable servers, this pattern leaves a dangling entry in the waiterMap and a pending Promise in memory. Because each aborted request leaks a block of heap memory, automating this request sequence leads directly to an Out of Memory (OOM) crash.

The security impact of GHSA-9MQV-5HH9-4CGG is a complete loss of availability for the affected Hono server. Because the memory leak is triggered prior to authentication, any remote user can perform the exploitation steps, making the complexity low.

The leaked resources include not only the small waiterMap entry but also the entire context of the IncomingMessage object, which contains request headers, socket references, and associated buffer allocations. As these objects accumulate in the V8 heap, garbage collection cycles become increasingly frequent and CPU-intensive, degrading server performance before ultimate termination.

When heap limits are exceeded, the Node.js runtime throws an unhandled Out of Memory error and exits. In environments lacking automated process supervisors or container orchestrators, this results in persistent downtime. Even with automatic restarts, continuous execution of the attack pattern can prevent legitimate users from establishing reliable connections.

The primary remediation strategy is upgrading the @hono/node-server package to version 2.0.10 or later. This release incorporates the socket-lifetime listener that guarantees cleanup on connection closure.

npm install @hono/node-server@2.0.10

For environments where upgrading is not immediately possible, deploying a reverse proxy such as Nginx or HAProxy in front of the Node.js application can mitigate the issue. The reverse proxy should be configured to validate incoming WebSocket headers strictly, blocking or rejecting malformed handshake requests before they reach the Node.js adapter.

Detection of active exploitation can be achieved by monitoring V8 heap metrics and tracking socket state transitions. A steady, linear rise in resident set size (RSS) or heap usage coupled with a high count of aborted TCP connections or HTTP 400 responses on upgrade routes suggests exploitation or persistent configuration issues.