GHSA-83hf-93m4-rgwq: Hickory recursor Hickory DNS's Record Cache Accepts Vulnerability

{
  "schema_version" : "1.4.0",
  "id" : "GHSA-83hf-93m4-rgwq",
  "modified" : "2026-04-30T18:10:58Z",
  "published" : "2026-04-30T18:10:58Z",
  "aliases" : [ ],
  "summary" : "Hickory DNS's Record Cache Accepts AUTHORITY-Section NS from Sibling Zone via Parent-Pool Zone-Context Elevation",
  "details" : "# Summary\n\nThe 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.\n\nThis 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.\n\nSubsequently, 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.\n\nThis 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.\n\nHickory 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.\n\nUsers 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+.\n\n### Reporter \n\nQifan Zhang, Palo Alto Networks",
  "severity" : [ {
    "type" : "CVSS_V4",
    "score" : "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:H/VA:N/SC:N/SI:N/SA:N"
  } ],
  "affected" : [ {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "hickory-recursor"
    },
    "ranges" : [ {
      "type" : "ECOSYSTEM",
      "events" : [ {
        "introduced" : "0.24.0"
      }, {
        "fixed" : "0.26.0"
      } ]
    } ],
    "database_specific" : {
      "last_known_affected_version_range" : "<= 0.25.2"
    }
  }, {
    "package" : {
      "ecosystem" : "crates.io",
      "name" : "hickory-recursor"
    },
    "versions" : [ "0.1" ]
  } ],
  "references" : [ {
    "type" : "WEB",
    "url" : "https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-83hf-93m4-rgwq"
  }, {
    "type" : "PACKAGE",
    "url" : "https://github.com/hickory-dns/hickory-dns"
  } ],
  "database_specific" : {
    "cwe_ids" : [ "CWE-345", "CWE-706" ],
    "severity" : "HIGH",
    "github_reviewed" : true,
    "github_reviewed_at" : "2026-04-30T18:10:58Z",
    "nvd_published_at" : null
  }
}