GHSA-3v94-mw7p-v465
hickory-proto: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses
Blast Radius
hickory-proto🦀hickory-netReal-time download stats are indexed for npm and PyPI packages. This vulnerability affects crates.io packages — download data is not available via public APIs for these ecosystems.
Description
The NSEC3 closest-encloser proof validation in hickory-proto's (0.25.0-alpha.3 ... 0.25.2) and hickory-net's (0.26.0-alpha.1 .. 0.26.0) DnssecDnsHandle walks from the QNAME up to the SOA owner name, building a list of candidate encloser names. The iterator used assumes the QNAME is a descendant of the SOA owner, terminating only when the current candidate equals the SOA name. When the SOA in a response's authority section is not an ancestor of the QNAME, the loop stalls at the DNS root and never terminates, repeatedly calling Name::base_name() and pushing newly allocated Name and hashed-name entries into the candidate Vec.
The bug is reachable by any caller of DnssecDnsHandle, including the resolver, recursor, and client, when built with the dnssec-ring or dnssec-aws-lc-rs feature and configured to perform DNSSEC validation. It is triggered while validating a NoData or NXDomain response whose authority section contains an SOA record from a zone other than an ancestor of the QNAME, on a code path that requires NSEC3 closest-encloser proof. In practice this can be reached through an insecure CNAME chain that crosses zone boundaries into a DNSSEC-signed zone returning NoData, but the minimum condition is just a mismatched SOA owner on a response requiring NSEC3 validation.
A debug_assert_ne!(name, Name::root()) guards the loop body, so debug builds abort with a panic on the first iteration past the root. Release builds compile the assertion out and run the loop unbounded, allocating until the process exhausts available memory. A reachable upstream attacker who can return such a response can therefore crash a debug build or exhaust memory on a release build, for the affected configurations.
The affected code was migrated from hickory-proto to hickory-net as part of the 0.26.0 release. Hickory DNS recommends that all affected users update to hickory-net 0.26.1 for the fix.
Reporter
David Cook, ISRG
Affected Packages
| Ecosystem | Package | Vulnerable range | Fix |
|---|---|---|---|
| 🦀crates.io | hickory-proto | ≥ 0.25.0-alpha.3 | No fix |
| 🦀crates.io | hickory-net | ≥ 0.26.0-alpha.1&&< 0.26.1 | 0.26.1 |
Detection & mitigation playbook
Open-source dependencyDetect
Scan your dependency tree (package-lock.json, pnpm-lock.yaml, requirements.txt, go.sum, etc.) for hickory-proto. O3's reachability analysis confirms whether the vulnerable code path is actually invoked in your application, so you act on real exposure instead of every transitive match.
Fix
No patched version of hickory-proto has shipped for GHSA-3v94-mw7p-v465 yet. Where your build allows, override or pin the dependency away from the vulnerable range, and apply any maintainer-recommended mitigation.
Workarounds
If you can't upgrade right away: gate or disable the affected feature, validate untrusted input at the boundary, and avoid passing attacker-controlled data into the vulnerable path. O3's runtime protection blocks exploitation in production as an interim safeguard until the upgrade lands.
How O3 protects you
O3 pinpoints whether GHSA-3v94-mw7p-v465 is reachable in your code and exactly where to fix it, then blocks exploitation in production at runtime until the patched version is deployed.
Tailored to GHSA-3v94-mw7p-v465. Runtime protection reduces exposure until a permanent patch is applied and verified — it complements patching, it doesn't replace it.
Frequently Asked Questions
Is GHSA-3v94-mw7p-v465 in your dependencies?
O3 detects GHSA-3v94-mw7p-v465 across crates.io dependencies and uses function-level reachability to confirm whether the vulnerable code path is actually reachable — not just present. No false positives.