CVE-2026-63385: Libevent: HTTP header handling bugs create risk of access control bypass.
Last updated 2 September 2026
Other sources
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. evhttpdecodeuriinternal 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. evhttpheaderisvalidvalue 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.
— MITRE
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/libeventto a version that resolves this vulnerability.Fixed in 2.1.13-stable-1 - Upgrade
Upgrade
libeventto a version that resolves this vulnerability.Fixed in 2.1.13 - Upgrade
Upgrade
libeventto a version that resolves this vulnerability.Fixed in 2.2.2-alpha
Event History
Frequently Asked Questions
Which deployments are most exposed to the URI parsing issue?
Deployments that decode request URIs with libevent and then pass the decoded path to downstream C string-based validation or authorization logic are exposed. A percent-encoded %00 can become a literal NUL, causing downstream operations to see only the path prefix while another component validated a different representation.
What does an attacker need to send to exploit these weaknesses?
For the URI issue, an attacker needs to supply a request URI containing a percent-encoded NUL byte (%00) in a location where differing path representations affect validation or access control. For the header issue, the attacker needs to submit header values containing carriage return or line feed characters so that a proxy and libevent can parse the headers differently.
Are fixed versions available for both issues?
Versions 2.1.13 and 2.2.2-alpha fix the CRLF header-value acceptance issue. The reviewed patches do not clearly remediate the URI NUL-truncation condition, so upgrading to those versions should not be assumed to address the %00 URI handling risk.
What can be done if patching is not immediately possible?
Reject request URIs containing percent-encoded NUL bytes before they reach libevent-dependent routing or authorization logic. Also reject header values containing carriage return or line feed characters and avoid relying on inconsistent proxy/backend header parsing for access-control decisions.