Nanomsg CVE-2026-97152

Requires that the target application enable nanomsg's WebSocket (ws) transport and expose a listening socket reachable by the attacker; the overflow is triggered purely by the attacker-controlled Sec-WebSocket-Version header during the pre-authentication handshake, so no credentials or user interaction are needed against a default WS listener. Limiting factors: nanomsg must actually be compiled/deployed with the WS transport in use (TCP/IPC-only deployments are unaffected), the version must be 0.5-beta through 1.x below 1.2.3, and reliable code execution (as opposed to a crash) depends on heap layout and platform, which is not demonstrated by any provided POC.

This is a genuinely serious flaw. The CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:L/UI:N) plus CWE-122 heap overflow and confirmed source evidence (PR #1130 replacing an unbounded sprintf with snprintf) point to a remotely triggerable memory-corruption bug reachable during the WebSocket handshake, before any application-level authentication in nanomsg's WS transport. I question the vendor's PR:L: the overflow occurs in nn_ws_handshake_server_reply while reflecting a client-supplied header, so it is reachable by any peer that can open a WS connection - effectively PR:N - which raises real-world risk above the score's implication. Countervailing signals lower priority: no EPSS score is provided, there is NO CISA KEV listing, and NO public exploit was identified - the referenced GitHub artifact is the fix PR, not a weaponized POC. I also disagree with the vendor's SC:H/SI:H/SA:H subsequent-system (scope-change) ratings, which appear to inflate the score; a stack/heap corruption within the process does not clearly cross a security boundary to another component. Net: treat as high-priority patching for any exposed nanomsg WebSocket listener, but note exploitation is currently theoretical (no observed in-the-wild activity) and achieving reliable code execution from a heap overflow requires target-specific work.

An attacker who can reach a nanomsg service using the WebSocket (ws://) transport opens a connection and sends an HTTP handshake containing an oversized Sec-WebSocket-Version header; the server copies that value into a fixed-size response buffer via unbounded sprintf, overflowing the heap. This corrupts adjacent memory to crash the service (DoS) or, with careful crafting, steer execution toward code execution. No public exploit code was identified, and the low attack complexity (AC:L) means no special timing or race is needed once a WS listener is exposed.