GHSA-2hxp-x833-73f7: Hickory DNS Recursor Ghost Domain Attack via Child-Side NS RRset Caching

Published Nov 8, 2026

Updated

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.

Remediation

Recommended actions to resolve this vulnerability, in priority order.

Upgrade
Upgrade hickory-resolver to a version that resolves this vulnerability.
Fixed in 0.26.2

Event History

Nov 8, 2026

CVE Published

via OSV·01:38 AM

Data Sourced

via OSV·01:38 AM

DescriptionSeverityWeakness

Frequently Asked Questions

Which deployments are affected?

All versions of hickory-recursor are affected. Deployments using hickory-resolver with the recursor feature are affected from 0.26.0-beta.1 through versions before 0.26.2.

What does an attacker need to do to exploit this?

The attacker must repeatedly query a zone's NS records. This keeps a stale child-side apex NS RRset in cache after the parent has revoked the delegation, allowing the previously delegated name servers to continue answering for the zone.

How can I determine whether a resolver is currently affected by the stale cache condition?

Check whether the resolver continues to use or accept answers from name servers for a zone after that zone's parent delegation has been revoked. The condition is sustained by repeated queries for the zone's NS records, which keep the stale RRset cached indefinitely.

GHSA-2hxp-x833-73f7: Hickory DNS Recursor Ghost Domain Attack via Child-Side NS RRset Caching

Remediation

Event History

Frequently Asked Questions

Which deployments are affected?

What does an attacker need to do to exploit this?

How can I determine whether a resolver is currently affected by the stale cache condition?

Company

Resources

Contact

Frequently Asked Questions

Which deployments are affected?

What does an attacker need to do to exploit this?

How can I determine whether a resolver is currently affected by the stale cache condition?