CVE-2026-63387 is a single-character off-by-one in libevent's DNS handling code (evdns.c). The bug allows a null terminator write to position buf_len when it should stop at buf_len-1, creating a one-byte overflow in the dnsname_to_labels function during DNS response formatting. Versions 2.1.12 and 2.2.1-alpha are affected. The fix is a one-line comparison operator change — the kind of trivial correction that, once found, takes seconds to apply.
But the persistence of this bug across multiple releases is the real story. Libevent powers critical infrastructure: curl, redis, memcached, tor, and the name resolution path for major Linux distributions. The DNS formatting code path in evdns.c has been in production for years, handling every DNS reply processed by anyone using the library. Yet it slipped through. The EPSS score of 0.00349 suggests automated exploitation is unlikely — this is at worst a crash-denial-of-service in practice. But that low exploitability is precisely why the deeper failure gets obscured.
This bug is not an isolated developer mistake. It exemplifies a recurring pattern: critical code paths that become "orphan" to the project's active maintenance attention while remaining in the critical path of production systems. The tooling to catch this — ASAN, UBSAN, targeted fuzzing for DNS boundary conditions — exists and is widely available. What doesn't exist is the systematic application of that tooling to peripheral subsystems like DNS record formatting. The same pattern appeared in OpenSSL's heartbeat extension (Heartbleed) and Bash's parsing edge cases (Shellshock): tooling infrastructure exists but gets systematically bypassed for legacy or peripheral code paths. The DNS name formatting code handles length-prefixed wire-format data with constant boundary-condition pressure — exactly the structural trap that generates these bugs across different codebases, regardless of team quality.
The organizational blind spot is this: low EPSS scores produce precisely the conditions for these bugs to survive longer. When exploitation probability is deemed negligible, post-mortems focus on the specific line and function rather than on systemic tooling gaps. Each patch resets organizational attention without triggering the systematic prevention investment — compile-time hardening, mandatory fuzzing, targeted boundary testing — that would catch the next instance. The result is accumulated remediation debt across hundreds of similar boundary-condition bugs, all patched individually without addressing the underlying pattern.
The question is whether the next off-by-one in DNS formatting code will receive better treatment. That depends on whether organizations treat these low-EPSS boundary bugs as isolated fixes or as symptoms of a systematic tooling deployment failure that demands structural investment rather than one-line patches.