Hickory DNS EUVD-2026-119359

Exploitation requires all of: (1) a Hickory deployment (resolver, recursor, or client via DnssecDnsHandle) built with the dnssec-ring or dnssec-aws-lc-rs feature and configured to perform DNSSEC validation - this is a non-default, opt-in validating configuration; (2) attacker positioned on-path between the resolver and the authoritative, or control of a malicious/compromised authoritative server for the victim zone (the AT:P attack requirement); and (3) a client query for an RRtype at the zone apex, which the attacker answers by replaying any validly-signed non-apex NSEC3 record from that zone together with the zone's signed SOA. Limiting factors that reduce realistic risk: deployments that do not enable DNSSEC validation are unaffected; the attacker must already hold the on-path or authoritative position; impact is confined to a forged negative (NODATA) answer for apex RRtypes and persists only for the negative-cache TTL, with no confidentiality exposure and no code execution. Affected versions: hickory-proto 0.25.0-alpha.3 through 0.25.2 (not yet patched) and hickory-net 0.26.0-alpha.1 before 0.26.2 (fixed in 0.26.2); per the advisory, updating is the remediation.

The input CVSS 4.0 vector (AV:N/AC:L/AT:P/PR:N/UI:N/VC:N/VI:L/VA:L) scores 6.3 (medium): network-reachable and needing no privileges or user interaction, but gated by AT:P - a specific attack requirement, here the on-path position or malicious/compromised authoritative server the description names. Impact is bounded to integrity-low (a forged, authenticated AD=1 denial) and availability-low (suppression of apex RRtypes for the negative-cache TTL); there is no confidentiality impact (VC:N). Exploitation status: no public exploit identified at time of analysis - the two references are the GHSA and VulnCheck advisories, not exploit code. No EPSS score and no KEV entry are provided in the input, and the vuln.today Decision label is 'this_month' (not act_now/emergency), so the aggregated signals point to a real but non-emergency, configuration-gated issue rather than mass exploitation. A genuine priority only for deployments that both enable DNSSEC validation (dnssec-ring or dnssec-aws-lc-rs feature) and sit in the attacker's on-path/authoritative reach. Signal conflict to note: the input Tags include 'Information Disclosure', but the CVSS vector sets VC:N and the described mechanism is a forged authenticated denial (spoofing/integrity), so the information-disclosure framing is not supported by the data. Also note hickory-proto is listed as not yet patched while hickory-net is fixed in 0.26.2.

When a client behind a DNSSEC-validating Hickory resolver queries an RRtype at a zone's apex (for example CAA, MX, or TXT), an on-path attacker or a malicious/compromised authoritative server replays any validly-signed non-apex NSEC3 record from that zone together with the zone's signed SOA. Hickory's DnssecDnsHandle returns Proof::Secure and sets AD=1 even though no NSEC3 record matches H(QNAME), so clients receive and cache an authenticated denial of the apex RRtype for the negative-cache TTL. No public exploit code is identified; the flaw requires the attacker's on-path/authoritative position (AT:P) rather than fully remote-at-will access.