Hickory DNS implements DNSSEC trust‑anchor validation but inadvertently skips checking the DNSKEY record name during validation. Because of this, a resolver can accept a DNSKEY RRset that consists only of trusted keys without verifying the associated RRSIGs. Attackers who can spoof or influence DNS server responses can therefore replace a zone’s legitimate DNSKEY RRset with that of the root zone, which is trusted by the resolver. The forged record can be cached with a long TTL, allowing the attacker to redirect clients to malicious sites, facilitate phishing, or distribute malware. This flaw matches CWE‑1023 and is classified as a DNS spoofing vulnerability.

The vulnerability affects the hickory-net component of the hickory-dns project from version 0.26.0‑beta.1 through 0.26.2, as well as the hickory‑proto library from version 0.24.0 up to 0.26.0‑alpha.1. Any instance of these libraries used to resolve DNS queries with DNSSEC validation enabled is susceptible. The vulnerability is present in both the ‟hickory‑net” DNS resolver and the underlying protocol implementation, and must be remedied in any deployment that relies on these components.

The CVSS score of 6.3 indicates a moderate severity vulnerability. Since EPSS data is not available, the likelihood of exploitation is uncertain, and the flaw is not yet listed in the CISA KEV catalog. An attacker must have the ability to forge DNSKEY records or otherwise intercept DNS traffic between the resolver and authoritative servers. By delivering a forged DNSKEY RRset containing trusted root keys, the attacker can bypass DNSSEC validation and propagate the false data for an extended period using long TTLs. The exploitation requires the resolver to enable DNSSEC validation, so disabling validation or applying the patch mitigates the risk.