CVE-2026-42254: 
Linux Debian vulnerability analysis and mitigation

CVE-2026-42254 is a cross-zone DNS cache poisoning vulnerability in Hickory DNS's hickory-recursor crate, affecting versions 0.1 through 0.25.2. The flaw allows an attacker-controlled nameserver to inject malicious NS records for sibling zones into the shared DNS record cache, causing subsequent queries for victim zones to be routed to the attacker's nameserver. It was published on April 26, 2026, and is associated with GitHub Security Advisory GHSA-83hf-93m4-rgwq (reported by Qifan Zhang of Palo Alto Networks). The vulnerability carries a CVSS v3.1 base score of 4.0 (Medium) (GitHub Advisory, GHSA-83hf).

The root cause is classified as CWE-706 (Use of Incorrectly-Resolved Name or Reference) and CWE-345 (Insufficient Verification of Data Authenticity). The DnsLru record cache in crates/recursor/src/lib.rs stores DNS records keyed by each record's own (name, type) tuple rather than by the originating query. The cache_response() function chains ANSWER, AUTHORITY, and ADDITIONAL sections into a single iterator before insertion, and the bailiwick filter uses the zone context of the NS pool that serviced the lookup — not the zone being queried. Concretely, when Hickory builds the NS pool for attacker.poc., it inherits the parent poc. NS pool context; a malicious poc. nameserver can include in its AUTHORITY section a record like victim.poc. NS ns.evil.poc., which passes the is_subzone("poc.", "victim.poc.") bailiwick check and is stored under (victim.poc., NS) in the shared cache, poisoning future lookups for that sibling zone (GHSA-83hf).

Successful exploitation allows an unauthenticated network attacker to redirect DNS queries for victim zones to an attacker-controlled nameserver, effectively hijacking DNS resolution for any zone sharing a common parent with the attacker's zone. This compromises the integrity of DNS resolution across all systems dependent on the poisoned Hickory recursor, potentially enabling man-in-the-middle attacks, credential harvesting, or service disruption. Confidentiality and availability are not directly impacted per the CVSS scoring, but the integrity impact extends beyond the vulnerable component itself (scope: Changed) (GitHub Advisory, GHSA-83hf).

There is no public proof-of-concept exploit and no evidence of in-the-wild exploitation at this time. The EPSS score is approximately 0.029–0.041%, placing it in the 13th percentile for exploitation likelihood within 30 days. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog. Exploitation requires high attack complexity — the attacker must control a nameserver within the same parent zone as the target — and no threat actor attribution has been reported (GitHub Advisory, Feedly).

1. Establish attacker-controlled zone: Register or control a domain (e.g., attacker.poc.) within the same parent zone (poc.) as the target victim zone (victim.poc.), and operate a malicious authoritative nameserver (e.g., ns.evil.poc.).
2. Trigger a query to the attacker's zone: Cause the Hickory recursor to resolve a name within attacker.poc., prompting it to build an NS pool using the parent poc. NS pool context.
3. Inject poisoned AUTHORITY record: When the Hickory recursor queries the poc. nameserver (which the attacker controls or has influenced), return a crafted DNS response whose AUTHORITY section includes a forged NS record: victim.poc. NS ns.evil.poc..
4. Bypass bailiwick check: The recursor's bailiwick filter evaluates is_subzone("poc.", "victim.poc."), which returns true since victim.poc. is a subdomain of poc., allowing the malicious record to pass validation.
5. Cache poisoning takes effect: The forged (victim.poc., NS) record is stored in the shared DnsLru cache, overwriting or preempting the legitimate NS entry.
6. Redirect victim zone queries: Any subsequent client query for a name under victim.poc. causes Hickory to use the poisoned cache entry, routing all resolution traffic to ns.evil.poc. instead of the legitimate nameserver (GHSA-83hf).

• Network: DNS queries for victim.poc. (or other sibling zones) being routed to unexpected or unknown nameserver IP addresses; outbound DNS traffic from the Hickory recursor to nameservers not listed in legitimate zone delegation records.
• Logs: Hickory recursor logs showing NS pool construction for a victim zone referencing nameservers associated with a sibling or attacker-controlled zone; unexpected cache hits for NS records of zones that were not directly queried.
• DNS Cache: Presence of NS records for zones (e.g., victim.poc.) pointing to nameservers outside the expected delegation chain (e.g., ns.evil.poc.) when inspecting the recursor's cache state.
• Resolution Behavior: Legitimate authoritative nameservers for victim.poc. receiving zero queries despite active client resolution attempts for names in that zone (GHSA-83hf).

The fix is implemented in hickory-resolver 0.26.0 via an architectural change: responses are now stored keyed by the originating query (name, type) rather than by each record's own name, preventing cross-zone cache contamination. The hickory-recursor crate has been folded into hickory-resolver under a non-default recursor feature flag and will receive no further updates. Users running hickory-dns with the opt-in recursor feature should upgrade to version 0.26.0 or later. As interim mitigations, consider implementing DNSSEC for cryptographic validation of DNS responses, enabling DNS response rate limiting, and monitoring for anomalous NS record changes in cache (GHSA-83hf, GitHub Advisory).

The vulnerability was reported by Qifan Zhang of Palo Alto Networks and disclosed via the Hickory DNS project's GitHub Security Advisories on April 22, 2026. The Hickory DNS maintainers responded by deprecating the standalone hickory-recursor crate entirely and integrating its functionality into hickory-resolver 0.26.0 with the architectural fix. No significant broader media coverage or notable community debate has been observed beyond standard vulnerability database aggregation (GHSA-83hf).