CVE-2026-63385 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 two HTTP parsing weaknesses in http.c. evhttp_decode_uri_internal decodes percent-encoded %00 bytes into literal NUL characters, which can cause downstream C string operations to truncate a path and bypass validation performed on a different representation. evhttp_header_is_valid_value also accepts obsolete line folding in header values containing carriage return or line feed characters, allowing a proxy and libevent to interpret headers differently and enabling header injection or access control bypass. The CRLF header acceptance is fixed in versions 2.1.13 and 2.2.2-alpha, but the reviewed patches do not clearly remediate the URI NUL-truncation condition.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 08/20/2026
Libevent serves as a widely adopted event notification library for network applications, yet vulnerabilities within its HTTP parsing components can introduce significant security risks to dependent services. Specifically, weaknesses identified in versions prior to 2.1.13 and 2.2.2-alpha involve critical flaws in the http.c module that affect how Uniform Resource Identifiers are decoded and how HTTP headers are validated. These issues stem from improper handling of encoded data and legacy protocol features, creating opportunities for attackers to manipulate request processing logic within applications relying on this library.
The first vulnerability involves the evhttp_decode_uri_internal function which processes percent-encoded URIs. This component incorrectly decodes percent-encoded null bytes represented as %00 into literal NUL characters. In C-based programming environments, strings are typically terminated by a NUL character. When such a byte is introduced into a path string during decoding, it causes premature truncation of the string at that point. Consequently, any validation logic or access control checks performed on the original encoded representation may be bypassed because the application processes only the truncated portion of the URI. This behavior aligns with CWE-627, which describes issues related to null byte injection in path strings, and can lead to unauthorized access to restricted resources if the server fails to validate the full intended path before processing.
The second vulnerability pertains to header validation within evhttp_header_is_valid_value. This function accepts obsolete line folding techniques that involve carriage return or line feed characters embedded within HTTP header values. While modern HTTP standards generally discourage such practices, legacy support for them allows a malicious proxy or client to inject additional headers into the request stream. By exploiting this behavior, an attacker can perform HTTP response splitting or header injection attacks. This flaw enables the manipulation of downstream processing logic and can facilitate access control bypasses if security policies rely on specific header values that are obscured or altered through these injected characters. This issue is closely related to CWE-113, which covers Improper Neutralization of CRLF Sequences in HTTP Headers, a common vector for cache poisoning and session hijacking attacks as documented in the MITRE ATT&CK framework under techniques like T1071 Application Layer Protocol: Web Protocols.
Although updates released in versions 2.1.13 and 2.2.2-alpha address the CRLF header acceptance issue, they do not clearly remediate the URI NUL-truncation condition. This incomplete fix leaves applications still vulnerable to path traversal or access control bypass attacks via null byte injection. Organizations utilizing libevent must therefore ensure that their deployments are updated beyond these versions and verify that specific patches addressing the URI decoding flaw have been applied. Mitigation strategies should include upgrading to a version where both vulnerabilities are fully resolved, implementing strict input validation at the application layer independent of library defaults, and configuring web servers or reverse proxies to reject requests containing null bytes in URIs before they reach the libevent handler.