libevent CVE-2026-63495

The vulnerable code path is active whenever an application uses libevent's evws WebSocket server API from versions 2.2.0-alpha-dev to 2.2.2-alpha (pre-fix). No authentication is required (CVSS PR:N) and no non-default configuration is needed beyond exposing a WebSocket endpoint via the evws API - the default frame-reassembly behavior is vulnerable. Exploitation is constrained to the 2.2.x alpha release series, as the evws API does not exist in the widely-deployed 2.1.x stable branch. A limiting factor is that the attacker must be able to establish a TCP connection to the WebSocket port; network-level access controls blocking untrusted WebSocket connections would prevent exploitation. No user interaction is required, and exploitation is repeatable by any WebSocket-capable client.

The CVSS 3.1 vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H (score 7.5) accurately characterizes the attack surface: no authentication, no complexity, no user interaction, fully network-reachable. Impact is exclusively availability - a complete service crash via OOM. EPSS data was not supplied in the intelligence set; KEV status is absent, meaning CISA has not confirmed active exploitation at time of analysis. The primary risk-reducing factor is deployment footprint: the evws WebSocket API exists only in the 2.2.x alpha series, a pre-release track with very limited production adoption. This makes the effective blast radius considerably smaller than a comparable flaw in a stable libevent release would be. The vulnerability is easy to trigger (low attack complexity, no authentication), but the narrow affected version range and alpha-release status collectively mean the real-world priority is lower than the raw CVSS score implies for most organizations. Teams running 2.2.x alpha builds that expose evws WebSocket endpoints should treat this as high urgency; all others are unaffected.

An attacker opens a WebSocket connection to any libevent 2.2.x alpha evws endpoint and continuously sends continuation frames (FIN=0) each sized just below WS_MAX_RECV_FRAME_SZ, never sending a final frame to complete the message. The server's evbuffer in evws->incomplete_frames grows with each frame, consuming heap memory without bound until the process is terminated by the OS OOM killer or the host's available memory is exhausted, denying service to all other connected clients.