libevent CVE-2026-63380

The attacker must have local, low-privilege access to the target system (AV:L, PR:L per CVSS 4.0 vector). The application must be using libevent's WebSocket API - specifically, evws_new_session must be reachable in the code path. The attacker must induce a specific partial-failure sequence: evhttp_start_ws_ must succeed (completing the WebSocket HTTP upgrade) while the subsequent bufferevent_enable_locking_ call fails, which requires either a race condition or resource-exhaustion condition affecting threading primitives (AT:P). Multi-threaded applications using BEV_OPT_THREADSAFE bufferevents, as shown in the regression test's ws_threadsafe_bevcb callback, are the specific deployment scenario. Exploitation is strictly limited to denial of service via process crash; no memory disclosure or code execution is possible from this primitive. Deployments that do not use libevent's WebSocket layer are entirely unaffected.

The CVSS 4.0 vector (AV:L/AC:H/AT:P/PR:L/UI:N/VA:H) accurately reflects a constrained local denial-of-service with no code execution potential. Attack complexity is high because exploitation requires engineering a race condition or resource exhaustion event that causes bufferevent_enable_locking_ to fail at precisely the right moment in the WebSocket handshake sequence - a difficult prerequisite in practice. No EPSS data was supplied in the input, so probability of exploitation cannot be quantified; however, the absence of a KEV listing and any public proof-of-concept, combined with the local-only attack vector and impact limited to a process crash, places this firmly in the lower-priority tier for most organizations. The impact ceiling is availability loss - confidentiality and integrity are unaffected. The vulnerability is only reachable when the application actively uses libevent's WebSocket API (evws_new_session), which further reduces the realistic attack surface beyond what the CPE scope alone implies. Overall this is a legitimate defect warranting patching on normal maintenance cycles rather than emergency response.

A local attacker with low-privilege access on a host running a libevent-based WebSocket server sends a valid WebSocket upgrade request while simultaneously exhausting system threading or memory resources, causing bufferevent_enable_locking_ to fail immediately after evhttp_start_ws_ has already freed the connection and request objects. The invalid TAILQ_REMOVE call in evws_connection_free then dereferences an uninitialized list pointer, crashing the server process. The regression test added in the fix (http_ws_early_free_test in regress_ws.c) demonstrates the exact triggering sequence and illustrates how it can be replicated.