---
id: CVE-2026-42254
aliases:
  - GHSA-83hf-93m4-rgwq
title: >-
  Hickory DNS's Record Cache Accepts AUTHORITY-Section NS from Sibling Zone via
  Parent-Pool Zone-Context Elevation
summary: >-
  Hickory DNS's Record Cache Accepts AUTHORITY-Section NS from Sibling Zone via
  Parent-Pool Zone-Context Elevation
severity: high
vendor: hickory-recursor
product: hickory-recursor
ecosystem: rust
affected:
  - 'hickory-recursor >= 0.24.0, < 0.26.0'
  - hickory-recursor
patched:
  - hickory-recursor 0.26.0
published: '2026-04-30'
updated: '2026-07-08'
source: OSV
sourceUrl: 'https://osv.dev/vulnerability/GHSA-83hf-93m4-rgwq'
references:
  - url: >-
      https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-83hf-93m4-rgwq
  - url: 'https://github.com/hickory-dns/hickory-dns'
tags:
  - osv
  - rust
epss: 0.00256
epssPercentile: 0.15338
ingestedAt: '2026-07-09T18:56:37.291Z'
---

## Overview

# Summary

The Hickory DNS project's experimental `hickory-recursor` crate's record cache (`DnsLru`) stores records from DNS responses keyed by each record's own (name, type), not by the query that triggered the response. `cache_response()` in `crates/recursor/src/lib.rs` chains `ANSWER`, `AUTHORITY`, and `ADDITIONAL` sections into one record iterator before insertion. The bailiwick filter it applies uses the zone context of the NS pool that serviced the lookup, not the zone being queried.

This creates a cross-zone poisoning path. When Hickory builds the NS pool for `attacker.poc.` it uses the parent `poc.` `NS` pool (`ns.zone() = "poc."`). If the `poc.` nameserver under the attacker's control includes in its response's `AUTHORITY` section a record for a sibling zone like `victim.poc. NS ns.evil.poc.`, the bailiwick check `is_subzone("poc.", "victim.poc.")` passes (`victim.poc.` is a subdomain of `poc.`). The record is stored under `(victim.poc., NS)` in the shared cache.

Subsequently, any client querying a name in `victim.poc`. causes Hickory to build its NS pool from the poisoned cache entry, routing queries to the attacker's nameserver (`ns.evil.poc.`) rather than to the legitimate nameserver for `victim.poc.`. The legitimate `NS` for that zone receives zero queries.

This issue is fixed in `hickory-resolver` 0.26.0 with the `recursor` feature through an architectural change to response-level caching: responses are stored keyed by the originating query `(name, type)`. A response to `(attacker.poc. NS)` is stored only under that key and cannot affect the `(victim.poc., NS)` cache entry.

Hickory DNS believes this issue has been present in all published versions of the experimental `hickory-recursor` crate, which has now been folded into the `hickory-resolver` crate under the non-default `recursor` feature flag. The `hickory-recursor` crate will not receive any updates going forward and all users should migrate to `hickory-resolver` with the `recursor` feature.

Users of the `hickory-dns` binary configured with the opt-in `recursor` feature and a configuration acting as a recursive resolver should update to 0.26.0+.

### Reporter 

Qifan Zhang, Palo Alto Networks

## Affected packages

- `hickory-recursor >= 0.24.0, < 0.26.0`
- `hickory-recursor`

## Remediation

Upgrade to a patched release:

- `hickory-recursor 0.26.0`