Hickory DNS CVE-2026-123592

Exploitation requires the resolver to be running hickory-net DNSSEC validation (the hickory_net::dnssec path using ValidationCacheKey) in affected versions v0.26.0-beta.1 through v0.26.1. The attacker must control an unsigned (Insecure) delegation for a name that differs from the signed target name only in the position of dots/label boundaries, exploiting that Name::hash incorporates label contents but not label lengths; the attacker must prime the validation cache with the benign Proof::Insecure verdict before the victim queries the real target, so success depends on cache state/timing (reflected by AT:P). Limiting factors: only Hickory DNS resolvers performing DNSSEC validation in the vulnerable version range are affected; the attacker needs the ability to control a colliding delegation and to influence resolution order. The only complete fix stated by the vendor is upgrading to 0.26.2.

This is a genuine integrity-focused DNSSEC validation bypass with a credible, well-documented mechanism, but the aggregate signals point to a serious-but-not-emergency priority rather than a drop-everything fire. The CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:H/VA:N) correctly frames it: network-reachable and unauthenticated, but gated by an attack requirement (AT:P) - the attacker must control an unsigned delegation whose name collides with a signed target under Hickory's length-ignoring Name hash, and must win a cache-priming race before the victim resolves the target. Impact is integrity-only (VI:H): forged DNS answers returned as NOERROR/AD=0 instead of SERVFAIL; there is no confidentiality or availability impact in the primary vector, though the advisory notes a secondary HashDoS avenue. The vuln.today decision label is 'this_week', consistent with a real but conditional threat. No EPSS score, no CISA KEV listing, and no confirmed working exploit code were supplied - only vendor/VulnCheck advisories describing the flaw. The signals are internally consistent (no CVSS-vs-description conflict), so the main caveat is simply that exploitation probability data (EPSS) and in-the-wild telemetry are absent, so real-world exploitation frequency cannot be quantified from the provided data.

An attacker who operates (or can inject responses for) an unsigned delegation registers or crafts a name that differs from a victim's signed target only in dot/label-boundary positions, so that Hickory's Name::hash collides with the signed target's hash. The attacker gets the resolver to resolve the attacker's Insecure name first, priming ValidationCacheKey with a Proof::Insecure verdict, then forges an answer for the real signed target - which reuses the colliding cache entry, skips signature verification entirely, and is returned as NOERROR. No public exploit code is identified at time of analysis, though the GHSA advisory describes the technique in detail; the AT:P requirement means the attacker needs control of a colliding unsigned delegation and favorable cache timing.