CVE-2026-73565

Executive Summary

CVE-2026-73565 is a remotely triggerable, unauthenticated memory-exhaustion denial-of-service (DoS) vulnerability in @hono/node-server, the adapter used to run Hono applications on Node.js. All versions from 2.0.0 up to but excluding 2.0.10 are affected when the application exposes an upgradeWebSocket route to untrusted clients. An attacker who sends WebSocket upgrade requests with a missing or malformed Sec-WebSocket-Key header triggers an aborted handshake with no cleanup path, causing unbounded memory growth in the Node.js process and eventual service unavailability. The fix is released in version 2.0.10; as of writing, there is no public exploit code, no CISA KEV listing, and no confirmed exploitation in the wild.

Technical Analysis

This flaw resides in the Hono Node.js server adapter's WebSocket handshake implementation, specifically in src/websocket.ts as described in the NVD entry. The adapter is responsible for bridging incoming HTTP requests to Hono's routing engine and, for upgradeWebSocket routes, for completing the RFC 6455 WebSocket handshake using the underlying ws library.

The mechanism is as follows:

1. Registration without cleanup: When an HTTP GET request carrying an Upgrade: websocket header arrives at an upgradeWebSocket route, the adapter stores the request's IncomingMessage object in an internal structure referred to in the description as waiterMap, and a synchronous flow (waitForWebSocket) blocks pending handshake completion.

2. Handshake abort with no continuation: The actual handshake is delegated to the ws library's ws.handleUpgrade routine. Per RFC 6455, the server must validate the Sec-WebSocket-Key header (base64-encoded, 16-byte random value). When that header is missing or malformed, ws.handleUpgrade aborts the handshake and, critically, does not emit the connection event that the adapter is waiting on.

3. Permanent leak: Because the connection event never fires, the blocked waitForWebSocket continuation never resolves, and the IncomingMessage retained in waiterMap is never removed. There is no error-handling or timeout branch described that would release these references. Each malformed upgrade request therefore leaks one request object (including socket/buffer references) for the lifetime of the process.

The vulnerability class is CWE-401 — Missing Release of Memory after Effective Lifetime: the object is functionally dead once the handshake is aborted, but the code path that should release it is unreachable under the malformed-input condition.

Attack surface: any Node.js process running @hono/node-server 2.0.0 – 2.0.9 with a publicly reachable upgradeWebSocket route. The attack requires no authentication, no prior session, and no special preconditions — only the ability to send HTTP requests to the service. The CVSS vector (AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L) reflects low attack complexity and no privilege requirement, with impact limited to availability.

Limitations of technical detail: The NVD description provides the key function names and file path (src/websocket.ts, waiterMap, waitForWebSocket, ws.handleUpgrade, upgradeWebSocket, Sec-WebSocket-Key, IncomingMessage) but does not disclose the complete surrounding code, so we do not speculate on additional helper functions, timeout configurations, or logging. The attacker-controlled condition described (missing/malformed Sec-WebSocket-Key) is sufficient to reproduce the leak at the protocol level.

Exploitation Scenarios

No public proof-of-concept or exploit code is available for CVE-2026-73565 (exploit status: UNKNOWN at the time of writing). The attack chain below is inferred strictly from the NVD description and the documented vulnerability mechanics.

1. Reconnaissance / target identification: The attacker identifies a public-facing Hono application running on Node.js that exposes a WebSocket endpoint (e.g., real-time dashboards, chat services, collaboration tools, live notification feeds). Fingerprinting may be performed by observing upgrade-capable endpoints, HTTP response characteristics, or simply probing common WebSocket paths. Shodan-style dorks such as "Sec-WebSocket-Accept" or HTTP title searches for Hono can locate candidate services.

2. Triggering the flaw: The attacker sends an HTTP GET request to the upgradeWebSocket route with the WebSocket upgrade headers (Upgrade: websocket, Connection: Upgrade) but with the Sec-WebSocket-Key header omitted or populated with a malformed value (e.g., empty string, non-base64 data, incorrect length). This is a vulnerability-class-level trigger: the server validates the header and aborts the handshake without firing the completion callback.

3. Execution / flooding: The attacker repeats the malformed upgrade request at scale from one or more source IPs. Each request permanently pins an IncomingMessage object and its associated Node.js resources (waiterMap growth, pending waitForWebSocket promises) in memory. Because there is no cleanup path, the leak is cumulative — every request adds to the total retained memory, regardless of the server responding or timing out.

4. Post-exploitation impact: With sufficient request volume, heap usage grows unboundedly until the Node.js process exhausts available memory, triggering out-of-memory conditions, process crashes, garbage-collector thrashing, or operating-system-level OOM kills. The result is degradation or complete unavailability of the Hono service. There is no confidentiality or integrity impact; the attacker gains no code execution, data access, or privilege elevation. This is a pure availability attack (T1499 — Endpoint Denial of Service).

Impact Assessment

• Business impact: Service unavailability for any application relying on @hono/node-server WebSocket functionality. Real-time features (messaging, live updates, collaboration) are the most exposed; a successful flood degrades or halts these functions entirely. For organizations with public-facing real-time services, this can translate to SLA breaches, revenue loss, user churn, and reputational damage.

• Affected systems: All deployments of @hono/node-server from version 2.0.0 up to (but not including) 2.0.10 that expose upgradeWebSocket routes. Applications that do not use WebSocket upgrade routes are not reachable by this specific flaw, though the logic exists in the shared adapter code.

• CVSS context: Base score 5.3 (Medium) — AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:L. The availability subscore is Low rather than High because each request leaks a bounded amount of memory; sustained attacker effort is required to exhaust the host. Enterprise environments often mitigate the worst-case impact via container/OS memory limits and process restarts, but a determined attacker can still cause repeated outages.

• Exploitability context: EPSS score is 0.00388 (32.0th percentile of all CVEs), indicating a low current probability of exploitation in the wild. The vulnerability is not on the CISA Known Exploited Vulnerabilities (KEV) catalog, and no threat-actor campaigns or exploit-in-the-wild evidence are known. This status can change quickly once the flaw is analyzed publicly.

• Blast radius: Confined to the Node.js process serving the Hono application. Other services on the same host are affected only insofar as they share memory/CPU resources. If the Hono service runs behind a reverse proxy, the proxy may be able to absorb or filter the flood, shrinking the practical blast radius.

Detection Guidance

The following detection content targets (a) the network signature of WebSocket upgrade floods with missing Sec-WebSocket-Key, and (b) the presence of vulnerable @hono/node-server code in environments. Tune thresholds to your baseline; WebSocket clients performing legitimate reconnects may produce occasional malformed handshakes.

Sigma Rule

title: Hono WebSocket Upgrade Flood without Sec-WebSocket-Key (CVE-2026-73565)
id: 2f8a1b9c-3c24-4c56-8b66-1c9d4e5f0001
status: experimental
description: Detects a high volume of WebSocket upgrade requests from a single source IP with a missing Sec-WebSocket-Key header, a pattern consistent with CVE-2026-73565 memory-exhaustion attempts.
references:
    - https://nvd.nist.gov/vuln/detail/CVE-2026-73565
author: Valters IT Threat Intelligence
date: 2026/01/01
logsource:
    category: webserver
    product: generic
detection:
    selection:
        cs-method: GET
        cs-headers|contains|all:
            - 'Upgrade: websocket'
            - 'Connection: Upgrade'
    filter:
        cs-headers|contains: 'Sec-WebSocket-Key: '
    condition: selection and not filter | count() by c-ip > 50
fields:
    - c-ip
    - cs-uri-stem
    - cs-headers
falsepositives:
    - Legacy or non-conforming WebSocket clients that omit the header
level: medium

Note: This rule assumes the reverse proxy or web server logs request headers (e.g., cs-headers). If headers are truncated, rely on volume-of-aborted-upgrades heuristics instead.

YARA Rule

rule CVE_2026_73565_Hono_WebSocket_Memory_Leak
{
    meta:
        author      = "Valters IT SOC"
        description = "Matches vulnerable @hono/node-server code (src/websocket.ts or compiled dist/websocket.js) containing the un-cleaned waiterMap/waitForWebSocket handshake logic for CVE-2026-73565"
        cve         = "CVE-2026-73565"
        reference   = "https://nvd.nist.gov/vuln/detail/CVE-2026-73565"
        date        = "2026-01-01"

    strings:
        $s1 = "waiterMap" ascii wide
        $s2 = "waitForWebSocket" ascii wide
        $s3 = "handleUpgrade" ascii wide
        $s4 = "Sec-WebSocket-Key" ascii wide

    condition:
        filesize < 2MB and all of ($s1, $s2, $s3) and $s4
}

Note: This YARA rule is designed for scanning source repositories and node_modules installs to identify vulnerable @hono/node-server copies (version < 2.0.10). It is not effective for network traffic.

Suricata IDS Rule

alert http any any -> any any (msg:"CVE-2026-73565 - Hono WebSocket upgrade flood with missing Sec-WebSocket-Key"; flow:established,to_server; http.method; content:"GET"; http.uri; content:"/"; http.header; content:"Upgrade: websocket"; nocase; http.header; content:"Connection: Upgrade"; nocase; http.header; content:"Sec-WebSocket-Key"; nocase; negated; threshold:type both, track by_src, count 50, seconds 60; classtype:attempted-dos; reference:cve,2026-73565; sid:10000001; rev:1;)

Note: The negated keyword on the http.header buffer matches requests where the Sec-WebSocket-Key header is absent. This requires Suricata's HTTP parser and does not catch the malformed-but-present header variant; add a second rule matching Sec-WebSocket-Key: with zero-length value if your HTTP normalization supports it.

Elastic Detection

sequence by source.ip with maxspan=1m
  [ network where network.protocol == "http"
     and http.request.method == "GET"
     and startsWith(http.request.headers.upgrade, "websocket") ]
  [ network where network.protocol == "http"
     and http.request.method == "GET"
     and startsWith(http.request.headers.upgrade, "websocket") ]
  [ network where network.protocol == "http"
     and http.request.method == "GET"
     and startsWith(http.request.headers.upgrade, "websocket") ]

Note: In ECS, request header names are normalized to lowercase (http.request.headers.upgrade). This EQL sequence flags rapid-fire WebSocket upgrade attempts from one source. It should be paired with an Elastic threshold/correlation rule (> 50 events/min from a single source.ip) and, where possible, an additional condition that http.request.headers.sec-websocket-key is missing or empty. Ensure HTTP/ECS field mapping is enabled on your ingest pipeline.

Splunk SPL Query

index=web sourcetype=access_combined
| where method="GET" AND match(request,"(?i)upgrade:\\s*websocket")
| rex field=headers "(?i)sec-websocket-key:\\s*(\\S+)" as ws_key
| where isnull(ws_key) OR len(ws_key)==0
| bucket _time span=5m
| stats count as attempts, dc(uri_path) as target_urls by src_ip, _time
| where attempts > 50
| sort - attempts

Note: This query depends on the web server/proxy log including request headers (e.g., a headers field or cs_headers). If headers are not logged, replace the rex/where lines with a filter on HTTP 400 response codes for WebSocket paths — aborted handshakes typically yield an HTTP 400 per RFC 6455.

Wazuh OSSEC Rule

<group name="hono,websocket,cve-2026-73565,">

  <rule id="100735" level="12" frequency="40" timeframe="60" ignore="5">
    <match>Upgrade: websocket|websocket</match>
    <regex>GET\s+\S+\s+HTTP/1\.[01]</regex>
    <description>Possible CVE-2026-73565 WebSocket upgrade flood (missing Sec-WebSocket-Key)</description>
    <mitre>
      <id>T1499</id>
    </mitre>
    <group>websocket_abuse,</group>
  </rule>

</group>

Note: OSSEC/Wazuh rules match on log content, not raw packet headers. This rule fires when access logs or application logs record a sustained volume of WebSocket upgrade requests (with frequency/timeframe acting as a threshold). Adjust the regex and match patterns — and the log source decoder — to match your web server's access-log format. For the strongest signal, extend the rule to require HTTP 400 status codes alongside the upgrade pattern.

Mitigation & Patch Guidance

Patch confidence: 2/4 — CLAIMED. The fix in @hono/node-server 2.0.10 is asserted by a single source (OSV) and has not been independently confirmed. Note that the NVD description explicitly states the issue "is fixed in version 2.0.10," but the OSV package record metadata still shows an "unfixed" commit reference; verify the fix in your own environment before considering the issue closed.

1. Immediate mitigations (no vendor workaround is documented):

   • Upgrade @hono/node-server to version 2.0.10 or later as soon as the patch is verified.
   • If an immediate upgrade is not possible, remove or restrict public access to upgradeWebSocket routes — e.g., place them behind authentication, a VPN, or an allow-listed reverse proxy.
   • Deploy a reverse proxy / WAF rule that rejects HTTP requests with Upgrade: websocket when the Sec-WebSocket-Key header is missing, empty, or not valid base64 (RFC 6455 validation at the edge).
   • Apply rate limiting per source IP on WebSocket upgrade endpoints (e.g., < 10 requests/second per IP) and cap the number of concurrent pending handshakes.

2. Patch / upgrade steps:

   • Audit all deployments: npm ls @hono/node-server.
   • Upgrade to >= 2.0.10, then re-run the audit: npm install @hono/node-server@latest.
   • Independently validate the claimed fix: after upgrade, replay malformed upgrade requests against a staging instance and confirm that retained memory (resident set size / heap used) stabilizes instead of growing monotonically. Given the 2/4 patch confidence, this validation is mandatory.
   • Rebuild and re-deploy container images; ensure the updated version is pinned in your lockfile.

3. Long-term hardening:

   • Set Node.js heap limits (--max-old-space-size) and run Hono services inside containers with hard memory limits and automatic restart policies (orchestrator-level OOM kill/restart).
   • Add a watchdog that monitors process memory growth and alerts on monotonic increase without stabilization.
   • Treat RFC 6455 handshake validation as a central concern: any WebSocket server code should include timeouts and error paths that release pending handshake state, regardless of which header is malformed.
   • Maintain a detection baseline for WebSocket traffic so threshold rules (Sigma/Suricata/EQL/SPL) can distinguish protocol noise from floods.
   • Re-check CISA KEV and EPSS feeds periodically; this CVE is not currently exploited, but a public PoC could change that posture quickly.

References

1. NVD Entry — CVE-2026-73565: https://nvd.nist.gov/vuln/detail/CVE-2026-73565
2. OSV Advisory — CVE-2026-73565 (patch source per input data): https://osv.dev/vulnerability/CVE-2026-73565
3. Hono project / @hono/node-server repository (upstream source): https://github.com/honojs/node-server
4. Hono official documentation (framework and middleware reference): https://hono.dev/
5. CISA Known Exploited Vulnerabilities Catalog — this CVE is not listed as of writing: https://www.cisa.gov/known-exploited-vulnerabilities-catalog

Threat-actor activity: No known campaigns, exploit-in-the-wild usage, or threat-actor references are associated with CVE-2026-73565 at the time of writing. Public exploit code is unknown; Nuclei coverage and third-party exploit template availability are both reported as none.