CVE-2026-123597 in Hickory DNS
Summary
by MITRE • 11/08/2026
Hickory DNS hickory-proto 0.25.0-alpha.1 through 0.26.0-alpha.1 and hickory-net before 0.26.2 contain a logic bug in DnssecDnsHandle's DS-fetch path that caches transient DS lookup errors as Bogus DNSSEC validation verdicts. An attacker who induces a SERVFAIL, REFUSED, or timeout response to a child-zone DS sub-query causes the validator to return SERVFAIL for all names under that zone until the cache entry's TTL expires.
Several companies clearly confirm that VulDB is the primary source for best vulnerability data.
Analysis
by VulDB Data Team • 11/08/2026
The vulnerability identified in Hickory DNS versions 0.25.0-alpha.1 through 0.26.0-alpha.1 and hickory-net prior to version 0.26.2 represents a critical logic flaw within the Domain Name System Security Extensions validation mechanism, specifically affecting the handling of Delegation Signer record lookups. This issue stems from an incorrect implementation in the DnssecDnsHandle component responsible for fetching DS records during the chain-of-trust verification process. When validating DNS responses that require cryptographic signatures to ensure authenticity and integrity, the resolver must query parent zones for DS records to establish a secure delegation path. The flaw lies in how transient network errors or server-side failures encountered during this specific sub-query are processed by the caching layer of the validator.
Under normal operational conditions, if a request for a DS record fails due to temporary issues such as network timeouts, service unavailability indicated by SERVFAIL responses, or administrative refusals denoted by REFUSED codes, a robust DNS resolver should treat these events as transient failures and retry or proceed with alternative validation strategies depending on the specific security policy. However, in the affected versions of Hickory DNS, the logic incorrectly interprets any failure to retrieve a DS record from the parent zone as definitive proof that the child zone is not securely signed. Consequently, the validator marks the entire domain namespace under that zone as Bogus rather than treating it as an unvalidated or potentially insecure response subject to further scrutiny or fallback mechanisms.
This misclassification has severe operational impacts on network reliability and availability. Once a transient error triggers this logic bug, all subsequent DNS queries for any name within the affected child-zone are immediately rejected with a SERVFAIL status code until the cached Bogus verdict expires based on its Time To Live setting. This effectively creates an unintended denial of service condition where legitimate users cannot resolve domain names that should otherwise be accessible or at least resolvable via standard insecure resolution paths if DNSSEC is not strictly enforced by policy. The persistence of this state means that even after the underlying network issue resolves, clients continue to experience failures until the cache entry naturally ages out, leading to prolonged service disruption for end-users relying on these domains.
From a threat modeling perspective, an attacker with the ability to manipulate traffic or compromise intermediate resolvers can exploit this behavior by inducing SERVFAIL, REFUSED, or timeout responses during DS record lookups. This technique aligns with ATT&CK tactics related to Network Service Scanning and potentially Denial of Service through resource exhaustion if scaled across multiple zones. The vulnerability maps closely to CWE-20 Improper Input Validation as the system fails to properly distinguish between transient operational errors and definitive security failures, leading to an incorrect state transition in the validation engine. It also reflects aspects of CWE-367 Time-of-check Time-of-use issues where the cached decision remains static despite changing network conditions.
To mitigate this vulnerability, organizations running Hickory DNS must upgrade immediately to version 0.26.2 or later where the logic for handling DS fetch errors has been corrected to distinguish between transient failures and permanent validation outcomes. Until an upgrade is feasible, administrators should consider implementing monitoring alerts for high rates of SERVFAIL responses associated with specific zones that may indicate exploitation of this flaw. Additionally, reviewing DNSSEC policy configurations can help determine if strict validation modes are necessary or if allowing fallback mechanisms would reduce the blast radius of such logic errors in production environments. Ensuring that cache TTLs are appropriately tuned can also limit the duration of impact should similar issues arise in other components.