Skip to content
cve.newCreate a CVE report

hickory-resolver

Follow this package

Get the evidence behind this dependency. Browse imported advisories below, or check an exact version against OSV now. View source coverage.

Check the version you ship.

Get a fresh OSV lookup for an exact release. We send the package name and version to OSV without storing a report.

Advisories & recorded fixes

medium6.9
CVE-2026-123603

Hickory DNS Missing IPv4-Mapped IPv6 Canonicalization Access Control Bypass

hickory-proto and hickory-resolver 0.26.0 before 0.26.2, hickory-server 0.25.0-alpha.1 before 0.26.2, and hickory-recursor 0.25.0-alpha.3 through 0.26.0-alpha.1 fail to canonicalize IPv4-mapped IPv6 addresses when checking deny_answers, deny_server, or AccessControlSet rules. Attackers can use IPv4-mapped addresses to evade answer filtering, trigger queries to denied nameservers, or reach hickory-server library deployments on dual-stack IPv6 sockets from denied clients.

No structured fix or guidance is available here. Check the latest publisher advisory.

Exploitation not established

hickory-dns · hickory-dns / hickory-dns · hickory-dns
high8.2
CVE-2026-123602

Hickory DNS Recursor Ghost Domain Attack via Child-Side NS RRset Caching

The Hickory DNS recursor in all versions of hickory-recursor and in hickory-resolver 0.26.0-beta.1 before 0.26.2 (recursor feature) is vulnerable to ghost domain names attacks because it reuses child-side apex NS RRsets cached from zone NS queries for iterative resolution. By repeatedly querying a zone's NS records, an attacker keeps the stale RRset cached indefinitely, letting name servers whose delegation the parent revoked keep answering for the zone.

No structured fix or guidance is available here. Check the latest publisher advisory.

Exploitation not established

hickory-dns · hickory-dns / hickory-dns · hickory-dns
medium6.3
CVE-2026-123598

Hickory DNS 0.25.0 through 0.26.0-alpha.1 DNSSEC Bogus Answer Cache Poisoning

The validating recursor in Hickory DNS hickory-recursor 0.25.0 through 0.26.0-alpha.1, hickory-resolver 0.26.0-alpha.1 before 0.26.2, and hickory-net 0.26.0-beta.1 before 0.26.2 caches DNSSEC-bogus answers using the untrusted, attacker-supplied record TTL (capped at 24 hours) instead of a short validation-failure TTL. A remote attacker who spoofs a single authoritative response with an invalid signature and a long TTL can keep the bogus result cached for up to 24 hours.

No structured fix or guidance is available here. Check the latest publisher advisory.

Exploitation not established

hickory-dns · hickory-dns / hickory-dns · hickory-dns
high8.7
CVE-2026-123588

Hickory DNS Recursive Resolver Denial of Service via Cached Empty Connection Pool

The recursive resolver in Hickory DNS (all versions of the hickory-recursor crate, and hickory-resolver 0.26.0 before 0.26.2) caches an empty connection pool when it follows a referral with no glue records and all queries for the name servers' IP addresses fail. An attacker able to spoof DNS responses can make these lookups fail, causing all subsequent queries for the affected zone to fail until the cache entry expires or is evicted.

No structured fix or guidance is available here. Check the latest publisher advisory.

Exploitation not established

hickory-dns · hickory-dns / hickory-dns · hickory-dns
medium6.3
CVE-2026-123583

Hickory DNS 0.25.0 through 0.25.2 Missing Bailiwick Filtering on Negative Responses

The recursive resolver in Hickory DNS hickory-recursor 0.25.0 through 0.25.2 and hickory-resolver 0.26.0 before 0.26.2 does not apply out-of-bailiwick filtering to negative responses. Attackers able to supply crafted negative responses can include out-of-bailiwick records to facilitate cache poisoning and more easily exploit other DNSSEC verification flaws.

No structured fix or guidance is available here. Check the latest publisher advisory.

Exploitation not established

hickory-dns · hickory-dns / hickory-dns · hickory-dns
medium6.9
CVE-2026-123585Package fixes recorded

hickory-resolver follows irrelevant CNAME records

When the Hickory DNS resolver follows CNAME records, it sends queries that are not necessary to answer the original recursive query. If there are any CNAME records in the authority section or additional section of the response, queries will be sent for those names. If there are any CNAME records that are not part of a CNAME chain starting from the original recursive query name, queries will be sent for those names. This increases query amplification beyond what is necessary to answer the recursive query.

Recorded fixes — hickory-resolver: 0.26.2. Check your release branch.

Exploitation not established

crates.io / hickory-resolver
hickory-resolver crates.io
Affected range Recorded fix
From 0.25.0 before 0.26.2Semantic versions0.26.2

Version evidence: OSV · GHSA-6f2x-v7q7-m7m5

View original version evidence
{
  "ranges": [
    {
      "events": [
        {
          "introduced": "0.25.0"
        },
        {
          "fixed": "0.26.2"
        }
      ],
      "type": "SEMVER"
    }
  ],
  "versions": []
}
high7.5
GHSA-5j98-2g5x-46v6Package fixes recorded

hickory-resolver: Resolver::lookup() and Resolver::lookup_ip() APIs obscure DNSSEC validation failures

When calling Resolver::lookup() or Resolver::lookup_ip() on a resolver with DNSSEC validation enabled, both methods return Ok(...) if DNSSEC validation fails. It is possible but very inconvenient to check the validation status of individual records. These methods should instead return an error when DNSSEC validation determines a response is bogus.

Recorded fixes — hickory-resolver: 0.26.2. Check your release branch.

Exploitation not established

crates.io / hickory-resolver
hickory-resolver crates.io
Affected range Recorded fix
Earlier releases before 0.26.2Semantic versions0.26.2

Version evidence: OSV · GHSA-5j98-2g5x-46v6

View original version evidence
{
  "ranges": [
    {
      "events": [
        {
          "introduced": "0"
        },
        {
          "fixed": "0.26.2"
        }
      ],
      "type": "SEMVER"
    }
  ],
  "versions": []
}
hickory-resolver crates.io
Affected range Recorded fix
From 0.0.0-0 before 0.26.2Semantic versions0.26.2

Version evidence: OSV · RUSTSEC-2026-0514

View original version evidence
{
  "ranges": [
    {
      "events": [
        {
          "introduced": "0.0.0-0"
        },
        {
          "fixed": "0.26.2"
        }
      ],
      "type": "SEMVER"
    }
  ],
  "versions": []
}
high8.7
CVE-2026-123606Some package fixes recorded

Hickory-DNS Recursor 0.25.0-alpha.3 through 0.25.2 Glueless-NS Referral Amplification

When a referral listed name servers outside the delegated zone and gave no glue addresses, the recursor looked up A and AAAA records for every listed name server, recursing into each one. Only the chain-depth limits applied. There was no cap on how many name servers it chased per referral or on the total upstream work per client query.

Recorded fixes — hickory-resolver: 0.26.2. Check your release branch.

Exploitation not established

crates.io / hickory-resolvercrates.io / hickory-recursor
hickory-resolver crates.io
Affected range Recorded fix
From 0.26.0-beta.1 before 0.26.2Semantic versions0.26.2

Version evidence: OSV · RUSTSEC-2026-0515

View original version evidence
{
  "ranges": [
    {
      "events": [
        {
          "introduced": "0.26.0-beta.1"
        },
        {
          "fixed": "0.26.2"
        }
      ],
      "type": "SEMVER"
    }
  ],
  "versions": []
}
high8.7
CVE-2026-123604Package fixes recorded

hickory-resolver: Unbounded TC-retry loop in `NameServerPool::try_send` (resource-exhaustion DoS)

When the hickory-resolver name server pool implementation receives an upstream response with the TC (truncated) header bit set, it re-queues the request to the same nameserver to retry with UDP transport disabled. However, the retry arm never inspects the transport that just answered and carries no iteration counter. An authoritative server that sets TC=1 on every available transport keeps the resolver spinning on one persistent TCP connection until the 5s per-request wall-clock deadline expires.

Recorded fixes — hickory-resolver: 0.26.2. Check your release branch.

Exploitation not established

crates.io / hickory-resolver
hickory-resolver crates.io
Affected range Recorded fix
From 0.26.0-beta.1 before 0.26.2Semantic versions0.26.2

Version evidence: OSV · GHSA-6w6g-hm98-mhgm

View original version evidence
{
  "ranges": [
    {
      "events": [
        {
          "introduced": "0.26.0-beta.1"
        },
        {
          "fixed": "0.26.2"
        }
      ],
      "type": "SEMVER"
    }
  ],
  "versions": []
}
hickory-resolver crates.io
Affected range Recorded fix
From 0.26.0-beta.1 before 0.26.2Semantic versions0.26.2

Version evidence: OSV · RUSTSEC-2026-0513

View original version evidence
{
  "ranges": [
    {
      "events": [
        {
          "introduced": "0.26.0-beta.1"
        },
        {
          "fixed": "0.26.2"
        }
      ],
      "type": "SEMVER"
    }
  ],
  "versions": []
}
high8.7
CVE-2026-123586Some package fixes recorded

Hickory DNS 0.25.0-alpha.3 through 0.25.2 Query Amplification via Cyclic Referrals

Two zones can each delegate to name servers named only inside the other zone, with no glue records (the cyclic sibling case in RFC 9471 section 2.3). Such delegations can never be resolved, but the recursor did not stop when it came back to a zone it was already resolving. It kept sending queries until the per-request limits ran out, and zero TTLs on the referral NS records made this worse.

Recorded fixes — hickory-resolver: 0.26.2. Check your release branch.

Exploitation not established

crates.io / hickory-resolvercrates.io / hickory-recursor
hickory-resolver crates.io
Affected range Recorded fix
From 0.26.0-beta.1 before 0.26.2Semantic versions0.26.2

Version evidence: OSV · RUSTSEC-2026-0516

View original version evidence
{
  "ranges": [
    {
      "events": [
        {
          "introduced": "0.26.0-beta.1"
        },
        {
          "fixed": "0.26.2"
        }
      ],
      "type": "SEMVER"
    }
  ],
  "versions": []
}