A version string is useful, but it is not proof that CVE-2026-63385 is resolved. Distributions and vendors often backport a security change without changing the major or minor version. Organizations need to verify the code behavior that matters: rejection of obsolete folded headers and consistent handling of a decoded NUL in a URI.

What the advisory fixes

The libevent advisory describes two HTTP header handling bugs. The parser accepts obsolete folded headers containing CRLF followed by whitespace. It also decodes %00 into a literal NUL without rejecting the URI. The public fix commits 758be0c0f69c1934ef9a84ab39e9f9e5fde2e6d0 and 9170dd35e64714613e8d13b290587cfc28e258e2 show evhttp_header_is_valid_value rejecting any CR or LF in a header value.

Patched releases are 2.1.13 and 2.2.2-alpha. The affected ranges are through 2.1.12 and through 2.2.1-alpha. The CVE record also notes CVSS 4.0 9.2 Critical, while the upstream advisory uses a High label. The discrepancy is a reason to read the vector and deployment requirements, not a reason to ignore the patch.

Why a package version can mislead

Linux distributions may patch 2.1.12 rather than shipping 2.1.13. A product vendor may bundle a custom copy and publish only the parent application version. A container base image may retain an older package in a layer even after the visible application is updated. Conversely, a package named libevent may be present but unused by the exposed HTTP service.

Build an evidence chain for every relevant binary:

  • package or library identity

  • exact build or backport revision

  • source of the binary, including static and container layers

  • vendor statement or patch reference

  • test result showing correct parser behavior

Do not accept a version comparison alone when a vendor has a documented backport. Do not accept a claim of a backport without the patch identity or behavior test.

Testing the header rule

Send a request whose header value contains CRLF followed by a space or tab. Record the frontend decision and the origin decision. The safe result is rejection at every security boundary before routing. If a frontend rejects the header but an internal service accepts it, the deployment still has the mismatch described by the advisory.

Inspect logs carefully. Many web servers normalize folded headers before application logging, which can hide the bytes that triggered the disagreement. Use a controlled proxy and raw capture in a test environment. Compare the bytes on ingress and egress, and verify that the backend does not receive a different header field.

Testing the URI rule

Send a percent-encoded NUL in a non-production protected path, for example /admin/secret%00.jpg. The safe result is a defined client error or a consistent path representation that never opens the protected resource. A 404 after an authorization decision is not enough, because the request may still have crossed the vulnerable boundary.

Repeat the test with case variations and with a front proxy that decodes before forwarding. Verify that the authorization layer and the file-serving layer use the same length-aware path representation. If the product cannot reject the NUL, an application-level normalization step or a vendor fix is required.

Monitoring after deployment

Track the deployed version, the vendor patch identifier and the test artifact together. Add a parser behavior test to integration tests and container image checks. A package scanner can detect a known version, but only the behavior test shows that a backport actually works in the shipping binary.

The two upstream commits shown with the advisory clearly support the CRLF rejection change. The URI NUL behavior should be verified against the actual vendor build and release notes. Do not infer complete remediation from a commit that only changes header validation.

Exposure context

ZoomEye Search app="libevent" returned 130 product-fingerprint matches; the CVE Filter returned 0. These results do not establish whether any particular product has the patch. Treat the count as a candidate-discovery signal, then verify the deployed binary and parser behavior.

References