CVE-2026-63382 in Libevent
Summary
by MITRE • 08/20/2026
Libevent is an event notification library. Prior to 2.1.13 and 2.2.2-alpha, the libevent evhttp parser in http.c inconsistently handles duplicate Transfer-Encoding headers, comma-separated Transfer-Encoding values, and bare line feeds in chunked framing. evhttp_find_header can select only the first header, evhttp_check_transfer_encoding_ was absent so the previous whole-string comparison fails to recognize valid lists ending in chunked, and evhttp_handle_chunked_read uses EVBUFFER_EOL_CRLF rather than EVBUFFER_EOL_CRLF_STRICT, accepting bare LF chunk terminators. When libevent is deployed behind a proxy that frames the same request differently, an unauthenticated remote attacker can desynchronize request boundaries and smuggle a second request, potentially bypassing access controls or poisoning caches. This issue is fixed in versions 2.1.13 and 2.2.2-alpha.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 08/20/2026
The vulnerability identified within the libevent library stems from inconsistent parsing logic in its HTTP server component, specifically affecting how duplicate headers and chunked transfer encoding are processed. Libevent serves as a widely used event notification library for network applications, and when deployed to handle incoming HTTP traffic via evhttp, it relies on specific parsers to interpret request structures correctly. The core technical flaw involves three distinct parsing deficiencies: the handling of multiple Transfer-Encoding headers with identical names, the interpretation of comma-separated values within those headers, and the validation of line endings in chunked framing mechanisms. These inconsistencies create a discrepancy between how libevent interprets an HTTP request locally versus how intermediate network devices such as reverse proxies or load balancers might interpret the same traffic based on different RFC compliance standards.
A primary issue lies in the evhttp_find_header function, which is designed to retrieve header values from incoming requests. This function operates by selecting only the first occurrence of a specified header name when duplicates are present. In standard HTTP/1.1 semantics defined by RFC 7230 and subsequent updates like RFC 9110, multiple headers with the same field-name can be combined into a single comma-separated list or treated as distinct entries depending on context. By arbitrarily selecting only the first header value, libevent fails to account for scenarios where security-critical information resides in later instances of duplicate headers. This behavior deviates from expected parsing norms and creates an ambiguity that attackers can exploit when requests traverse multiple layers of network infrastructure with varying interpretation rules.
The second critical flaw involves the validation of Transfer-Encoding values through a function intended to check if chunked encoding is present. Prior to the fix, this logic relied on whole-string comparisons rather than proper list parsing. Consequently, it failed to recognize valid lists that ended in chunked but contained other preceding encodings or formatting variations. This oversight means that requests employing complex or non-standard Transfer-Encoding sequences might be misclassified as not using chunked encoding when they actually do. This misclassification is particularly dangerous because many security controls and proxy configurations rely on accurate detection of transfer encoding to apply specific parsing rules, such as ignoring Content-Length headers in favor of chunk boundaries.
Furthermore, the handling of line endings in chunked framing exhibits a lack of strictness that violates RFC 7230 requirements for HTTP/1.1 message formatting. The function evhttp_handle_chunked_read utilizes EVBUFFER_EOL_CRLF instead of EVBUFFER_EOL_CRLF_STRICT. This distinction is crucial because RFC 7230 mandates that line breaks in HTTP messages must be represented as a carriage return followed by a line feed (CRLF). By accepting bare line feeds (LF) as valid terminators for chunk sizes, libevent becomes susceptible to request smuggling attacks where an attacker can inject raw LF characters to manipulate how the parser delineates message boundaries. This leniency allows for the creation of malformed requests that appear valid to libevent but are interpreted differently by downstream proxies or caches.
The operational impact of these vulnerabilities is severe, primarily enabling HTTP Request Smuggling when libevent is deployed behind a proxy. An unauthenticated remote attacker can craft malicious payloads that exploit the desynchronization between how libevent parses headers and line endings versus how an intermediate proxy processes them. By sending requests with duplicate Transfer-Encoding headers or bare LF characters in chunked frames, an attacker can trick the front-end server into believing one request has ended while the back-end proxy interprets it as part of a subsequent request. This desynchronization allows for cache poisoning attacks where malicious responses are injected and cached under legitimate URLs, potentially leading to cross-site scripting or data leakage. Additionally, access controls may be bypassed if the attacker can smuggle requests that appear to target internal resources while being routed through public-facing endpoints, effectively circumventing firewall rules or authentication mechanisms designed to protect specific paths or methods.
This vulnerability aligns with CWE-20 Improper Input Validation and CWE-436 Interpretation Conflict, as it involves both inadequate sanitization of input data and divergent interpretations between different components in the request path. In terms of offensive security frameworks, this flaw facilitates techniques described under MITRE ATT&CK T1190 Exploit Public-Facing Application and specifically supports HTTP Request Smuggling tactics often categorized within lateral movement or privilege escalation contexts depending on the target environment. The ability to smuggle requests can lead to unauthorized access to internal services, bypassing network-level security controls that rely on accurate request boundary detection.
Mitigation strategies focus primarily on upgrading the libevent library to version 2.1.13 or later for the stable branch and version 2.2.2-alpha or later for development branches. These updates address the parsing inconsistencies by implementing stricter header selection logic, improving Transfer-Encoding validation to handle comma-separated lists correctly, and enforcing strict CRLF line ending requirements in chunked framing. Organizations relying on libevent should verify their dependency versions immediately. Additionally, defensive measures include configuring web application firewalls to detect and block known request smuggling patterns, such as duplicate headers or unusual line breaks, although this is a secondary control since the root cause lies within the library itself. Regular security audits of network infrastructure configurations can also help identify environments where libevent might be exposed to these specific attack vectors, ensuring that any deployed instances are patched before they can be exploited by malicious actors seeking to desynchronize request boundaries or poison caches.