CVE-2026-63382 carries a CVSS 9.2 but the EPSS score sits at 0.00586—a two-order-of-magnitude gap that tells you something fundamental about this vulnerability that CVSS cannot: the actual exploitation surface is architecturally bounded in ways the vector string cannot express.
The vulnerability is a parsing differential in libevent's evhttp implementation. An unauthenticated attacker needs a specific topology to exploit it: libevent must sit behind a proxy that parses Transfer-Encoding or chunk boundaries differently than libevent's evhttp parser. The attacker must control how a request is framed differently at each hop. This is not a pre-auth RCE in libevent itself—it is a desync primitive that only becomes exploitable when those specific conditions align.
Resist the 9.2 reflex. Before escalating this as critical across all libevent consumers, ask two questions. First: what percentage of your libevent deployments actually route through HTTP proxies that could create the parsing discrepancy this CVE exploits? If your architecture does not chain libevent behind a non-compliant proxy, this vulnerability likely does not apply to you. Second: the fix in versions 2.1.13 and 2.2.2-alpha changes evhttp_handle_chunked_read to use EVBUFFER_EOL_CRLF_STRICT instead of the previous lenient bare-LF acceptor. This behavioral change may break applications that were functionally relying on libevent's leniency—even in topologies that had nothing to do with the original attack path. Test the patch in staging before deploying to production.
The CVSS score is technically correct about impact potential: if an attacker achieves the specific topology, the consequences are severe. But the score is strategically misleading for prioritization because it cannot price in architectural preconditions. EPSS captures the reality that this vulnerability sits in a narrow exploitation corridor. Use EPSS, architectural analysis, and your specific deployment context—not just the 9.2—as the inputs to your triage decision.