CVE-2026-42254: Cross-Zone DNS Cache Poisoning in Hickory DNS Recursor

The hickory-recursor crate, an experimental recursive DNS resolver within the Hickory DNS project, contains a fundamental flaw in its caching architecture. All versions from 0.1 through 0.25.2 are affected by this issue. The vulnerability allows an external attacker to perform cross-zone DNS cache poisoning, compromising the integrity of DNS resolutions for specific target domains.

The vulnerability manifests as a combination of two distinct weakness classes: Use of Incorrectly-Resolved Name or Reference (CWE-706) and Unintended Proxy or Intermediary (CWE-441). The root cause lies in how the recursor validates and caches records found in the AUTHORITY section of a DNS response. The validation logic fails to adequately restrict records to the specific zone queried, allowing lateral pollution of the cache.

An attacker who controls a nameserver for a given zone can exploit this mechanism to inject unauthorized NS records into the recursor's cache for sibling zones under the same parent. Once poisoned, any subsequent DNS queries originating from downstream clients targeting the victim sibling zone are automatically routed to the attacker's infrastructure. This enables traffic interception and facilitates active machine-in-the-middle attacks.

This vulnerability was discovered during an independent security audit of Hickory DNS conducted by X41 D-Sec, sponsored by OSTIF. The maintainers have discontinued the standalone hickory-recursor crate following this disclosure. The vulnerability is tracked publicly as CVE-2026-42254, GHSA-83HF-93M4-RGWQ, and RUSTSEC-2026-0106.

The vulnerability stems from two critical implementation flaws within the cache_response() function located in crates/recursor/src/lib.rs. The primary flaw involves improper cache keying logic. The recursor utilized a DnsLru record cache that stored individual entries using the record's own (name, type) tuple as the primary key. It failed to associate the cached record with the originating query context that prompted the resolution.

The secondary flaw involves weak bailiwick validation during response processing. To prevent out-of-bailiwick cache poisoning, a DNS recursor must ensure that a responding nameserver only provides records for zones it is strictly authorized to serve. However, when evaluating records within the AUTHORITY section, the hickory-recursor implementation evaluated the zone context based on the nameserver pool (NS pool) servicing the lookup, rather than the explicit zone originally queried.

These two logic errors create an exploitable synergy. Because the bailiwick filter evaluates against the broader parent zone pool, an injected record for a sibling zone incorrectly passes the internal is_subzone() boundary check. The recursor accepts the unauthorized record as valid. Due to the improper cache keying flaw, this record is subsequently inserted into the global cache keyed by its own identity, completely divorced from the malicious query that introduced it.

The core issue resides in the validation and caching pipeline of hickory-recursor prior to version 0.26.0. The code responsible for parsing the AUTHORITY section applied bailiwick checks using the elevated context of the NS pool. This context elevation meant that any subzone of the shared parent zone was treated as valid by the recursor.

// Abstracted representation of the vulnerable logic
fn process_authority_section(response: &DnsResponse, ns_pool_zone: &Name, cache: &mut DnsLru) {
    for record in response.authority() {
        // Vulnerability: Validates against the NS pool zone (e.g., "poc.")
        // instead of the explicitly queried zone (e.g., "attacker.poc.")
        if is_subzone(ns_pool_zone, record.name()) {
            // Vulnerability: Caches directly by the record's (name, type)
            cache.insert(record.name(), record.record_type(), record.data());
        }
    }
}

The architectural fix implemented in hickory-resolver 0.26.0 resolves this by entirely abandoning record-level caching in favor of strict response-level caching. Rather than extracting and caching individual records from a response, the system now caches the entire response object.

// Abstracted representation of the patched logic
fn cache_response(query_name: &Name, query_type: RecordType, response: &DnsResponse, cache: &mut ResponseCache) {
    // Fix: The cache entry is strictly tied to the exact query tuple.
    // A query for attacker.poc. can only populate the cache entry for attacker.poc.
    cache.insert(query_name, query_type, response);
}

This shift guarantees query isolation. A response generated from a query for a malicious domain is securely compartmentalized to that specific query context. It becomes structurally impossible for the response to overwrite or pollute the cache entries for an unrelated victim domain, regardless of the records supplied by the attacker in the AUTHORITY section.

Exploitation requires specific preconditions regarding authoritative control and network positioning. The attacker must operate an authoritative nameserver for a specific zone, such as poc.. Additionally, the attacker must induce the vulnerable recursor to initiate a DNS query for a subdomain within this controlled zone, such as attacker.poc..

When the vulnerable recursor queries attacker.poc., the attacker's nameserver receives the request and crafts a malicious response. Alongside the expected answer, the attacker populates the AUTHORITY section with an NS record targeting a sibling zone, formatted as victim.poc. NS ns.evil.poc.. The recursor receives this response and begins processing the records.

The recursor applies its bailiwick validation logic by executing is_subzone("poc.", "victim.poc."). Because victim.poc. is a legitimate subzone of the poc. parent, the validation check succeeds. The recursor then inserts the malicious NS record into its global cache, mapping victim.poc. to the attacker-controlled nameserver ns.evil.poc..

Once the cache is poisoned, the exploit enters its operational phase. Any legitimate client relying on the recursor that subsequently queries for victim.poc. will trigger a cache hit. The recursor forwards the lookup directly to ns.evil.poc., granting the attacker absolute control over the DNS resolution path for the targeted sibling zone.

A successful exploit allows targeted hijacking of DNS traffic for sibling zones sharing a common parent namespace. By redirecting DNS queries to an attacker-controlled nameserver, adversaries can execute active machine-in-the-middle attacks against applications relying on the vulnerable recursor. This capability directly facilitates credential theft, session hijacking, and the interception of sensitive communications intended for the victim domain.

The vulnerability is classified with a CVSS v3.1 base score of 4.0, representing a Medium severity. The associated vector is CVSS:3.1/AV:N/AC:H/PR:N/UI:N/S:C/C:N/I:L/A:L. The High attack complexity (AC:H) correctly reflects the stringent prerequisites: the attacker must control an authoritative nameserver for a shared parent or sibling zone and must execute precise query timing to seed the cache prior to legitimate lookups.

Despite the significant operational impact of a successful hijack, the likelihood of widespread exploitation remains minimal. The Exploit Prediction Scoring System (EPSS) assigns this vulnerability a score of 0.00029, placing it in the 8.14th percentile. This low score suggests minimal probability of active exploitation in the wild, largely constrained by the specific architectural requirements and targeted nature of the attack vector.

Organizations utilizing Hickory DNS components must immediately audit their application dependency trees. Any deployment importing the hickory-recursor crate version 0.25.2 or earlier is inherently vulnerable to cross-zone cache poisoning. Because the vulnerability involves core caching architecture, there are no viable configuration workarounds for the deprecated crate.

The official remediation path requires migrating away from the standalone hickory-recursor crate entirely. The maintainers have integrated the recursive resolution functionality directly into the main hickory-resolver crate starting with version 0.26.0. Developers must update their project dependencies to utilize this modern package.

To restore recursive DNS resolution capabilities after the migration, developers must explicitly enable the necessary feature flags. The recursor feature within the hickory-resolver Cargo.toml configuration is required. The patched version implements response-level caching, permanently mitigating the cross-zone pollution vectors.