CVE-2026-63388 in Libevent
Summary
by MITRE • 08/20/2026
Libevent is an event notification library. Prior to 2.1.13 and 2.2.2-alpha, libevent has a heap out-of-bounds write in bufferevent_sock.c when bufferevent_socket_set_conn_address_ copies a kernel-supplied AF_UNIX peer address into bufferevent_private.conn_address. Release builds compiled with NDEBUG disable the EVUTIL_ASSERT length guard, and the evhttp accept path can pass a 110-byte sockaddr from accept() into the 28-byte field. An unauthenticated local peer able to connect to an AF_UNIX listener can overwrite the adjacent dns_request pointer and heap data, causing memory corruption with confidentiality, integrity, and availability impact. This issue is fixed in versions 2.1.13 and 2.2.2-alpha.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 08/20/2026
Libevent serves as a widely adopted event notification library used to manage asynchronous I/O operations across various network protocols. A critical vulnerability exists within the bufferevent_sock.c module, specifically involving the function bufferevent_socket_set_conn_address_. This component is responsible for copying kernel-supplied peer addresses into the internal structure of a bufferevent object. The flaw manifests as a heap out-of-bounds write when handling AF_UNIX socket connections. Under normal circumstances, length checks are intended to prevent buffer overflows; however, in release builds compiled with NDEBUG, these EVUTIL_ASSERT guards are disabled. This configuration oversight removes critical boundary validation during the address copying process.
The technical root cause lies in a significant size mismatch between the source and destination buffers. The function attempts to copy an AF_UNIX peer address obtained from the accept() system call into the bufferevent_private.conn_address field, which is allocated with only twenty-eight bytes of space. However, kernel-supplied sockaddr structures for Unix domain sockets can be significantly larger, potentially reaching one hundred ten bytes in certain configurations or when extended socket options are utilized. Because the length guard is disabled in optimized builds, this oversized data is written directly into memory adjacent to the conn_address buffer without truncation or validation.
This heap corruption allows an unauthenticated local peer that has established a connection to an AF_UNIX listener to overwrite critical pointers and heap metadata located immediately after the bufferevent_private structure. Specifically, the attacker can corrupt the dns_request pointer and other adjacent heap data structures. Such memory corruption leads to undefined behavior within the application using Libevent. The impact is severe, affecting confidentiality through potential information disclosure via read-what-where primitives or crash-based leaks, integrity by allowing arbitrary code execution if control flow hijacking is achieved, and availability through immediate process termination due to segmentation faults or heap allocator errors.
From a classification perspective, this vulnerability aligns with CWE-120 Buffer Copy without Checking Size of Input in C/C++ as it involves writing more data than the destination buffer can hold. It also relates to CWE-787 Out-of-bounds Write and potentially CWE-416 Use After Free if the corrupted dns_request pointer is later dereferenced by the event loop logic. In terms of adversary tactics, this flaw supports ATT&CK technique T1059 Command and Scripting Interpreter or T1203 Exploitation for Client Execution if leveraged to achieve remote code execution on a local system through privilege escalation vectors available in multi-user environments where Unix sockets are commonly used for inter-process communication.
Mitigation strategies primarily involve upgrading Libevent to version 2.1.13 or later, which includes the necessary bounds checking and fixes for this specific heap overflow condition. For applications that cannot immediately upgrade, developers should ensure that builds do not disable assertion checks in production environments if possible, although relying on NDEBUG is common practice for performance optimization. Additionally, implementing strict input validation at the application layer before passing socket addresses to Libevent functions can provide a secondary defense-in-depth measure. Monitoring system logs for abnormal process terminations or heap corruption errors may also aid in detecting exploitation attempts against unpatched systems.