Vulnerability-Lookup

GHSA-3V94-MW7P-V465

Vulnerability from github – Published: 2026-05-07 02:59 – Updated: 2026-05-07 02:59

Summary

hickory-proto: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses

Details

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

Severity

8.7 (High)


                  
                    CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N

Show details on source website

JSON

To clipboard

{
  "affected": [
    {
      "package": {
        "ecosystem": "crates.io",
        "name": "hickory-proto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.25.0-alpha.3"
            },
            {
              "last_affected": "0.25.2"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    },
    {
      "database_specific": {
        "last_known_affected_version_range": "\u003c= 0.26.0"
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "hickory-net"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.26.0-alpha.1"
            },
            {
              "fixed": "0.26.1"
            }
          ],
          "type": "ECOSYSTEM"
        }
      ]
    }
  ],
  "aliases": [],
  "database_specific": {
    "cwe_ids": [
      "CWE-835"
    ],
    "github_reviewed": true,
    "github_reviewed_at": "2026-05-07T02:59:20Z",
    "nvd_published_at": null,
    "severity": "HIGH"
  },
  "details": "The NSEC3 closest-encloser proof validation in `hickory-proto`\u0027s (0.25.0-alpha.3 ... 0.25.2) and `hickory-net`\u0027s (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\u0027s 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`.\n\nThe 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.\n\nA `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.\n\nThe 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.\n\n### Reporter\n\nDavid Cook, ISRG",
  "id": "GHSA-3v94-mw7p-v465",
  "modified": "2026-05-07T02:59:20Z",
  "published": "2026-05-07T02:59:20Z",
  "references": [
    {
      "type": "WEB",
      "url": "https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465"
    },
    {
      "type": "PACKAGE",
      "url": "https://github.com/hickory-dns/hickory-dns"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0118.html"
    },
    {
      "type": "WEB",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0120.html"
    }
  ],
  "schema_version": "1.4.0",
  "severity": [
    {
      "score": "CVSS:4.0/AV:N/AC:L/AT:N/PR:N/UI:N/VC:N/VI:N/VA:H/SC:N/SI:N/SA:N",
      "type": "CVSS_V4"
    }
  ],
  "summary": "hickory-proto: NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses"
}

rustsec-2026-0118

Vulnerability from osv_rustsec

Published

2026-05-01 12:00

Modified

2026-05-07 08:56

Summary

NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses

Details

The NSEC3 closest-encloser proof validation in hickory-proto's 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 (OOM). A reachable upstream attacker who can return such a response can therefore crash a debug-built validator or exhaust memory on a release-built one.

The affected code was migrated from hickory-proto to hickory-net as part of the 0.26.0 release. The hickory-proto 0.26.x release no longer offers DnssecDnsHandle and so we recommend all affected users update to hickory-net 0.26.1 when the implementation of that type is required.

References

URL

Type

	https://crates.io/crates/hickory-proto	PACKAGE
	https://rustsec.org/advisories/RUSTSEC-2026-0118.html	ADVISORY
	https://github.com/hickory-dns/hickory-dns/securi…	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "categories": [
          "denial-of-service"
        ],
        "cvss": null,
        "informational": null
      },
      "ecosystem_specific": {
        "affected_functions": null,
        "affects": {
          "arch": [],
          "functions": [],
          "os": []
        }
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "hickory-proto",
        "purl": "pkg:cargo/hickory-proto"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.25.0-alpha.3"
            },
            {
              "fixed": "0.26.0-beta.1"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "versions": []
    }
  ],
  "aliases": [
    "GHSA-3v94-mw7p-v465"
  ],
  "database_specific": {
    "license": "CC-BY-4.0"
  },
  "details": "The NSEC3 closest-encloser proof validation in `hickory-proto`\u0027s\n`DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a\nlist of candidate encloser names. The iterator used assumes the\nQNAME is a descendant of the SOA owner, terminating only when the current\ncandidate equals the SOA name. When the SOA in a response\u0027s authority section\nis not an ancestor of the QNAME, the loop stalls at the DNS root and never\nterminates, repeatedly calling `Name::base_name()` and pushing newly allocated\n`Name` and hashed-name entries into the candidate `Vec`.\n\nThe bug is reachable by any caller of `DnssecDnsHandle` \u2014 including the\nresolver, recursor, and client \u2014 when built with the `dnssec-ring` or\n`dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is\ntriggered while validating a NoData or NXDomain response whose authority\nsection contains an SOA record from a zone other than an ancestor of the\nQNAME, on a code path that requires NSEC3 closest-encloser proof. In practice\nthis can be reached through an insecure CNAME chain that crosses zone\nboundaries into a DNSSEC-signed zone returning NoData, but the minimum\ncondition is just a mismatched SOA owner on a response requiring NSEC3\nvalidation.\n\nA `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds\nabort with a panic on the first iteration past the root. Release builds\ncompile the assertion out and run the loop unbounded, allocating until the\nprocess exhausts available memory (OOM). A reachable upstream attacker who\ncan return such a response can therefore crash a debug-built validator or\nexhaust memory on a release-built one.\n\nThe affected code was migrated from `hickory-proto` to `hickory-net` as part of\nthe 0.26.0 release. The `hickory-proto` 0.26.x release no longer offers\n`DnssecDnsHandle` and so we recommend all affected users update to `hickory-net`\n0.26.1 when the implementation of that type is required.",
  "id": "RUSTSEC-2026-0118",
  "modified": "2026-05-07T08:56:41Z",
  "published": "2026-05-01T12:00:00Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://crates.io/crates/hickory-proto"
    },
    {
      "type": "ADVISORY",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0118.html"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465"
    }
  ],
  "related": [],
  "severity": [],
  "summary": "NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses"
}

rustsec-2026-0120

Vulnerability from osv_rustsec

Published

2026-05-01 12:00

Modified

2026-05-07 08:56

Summary

NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses

Details

The NSEC3 closest-encloser proof validation in hickory-net's 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.

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 (OOM). A reachable upstream attacker who can return such a response can therefore crash a debug-built validator or exhaust memory on a release-built one.

We recommend all affected users update to hickory-net 0.26.1 for the fix.

References

URL

Type

	https://crates.io/crates/hickory-net	PACKAGE
	https://rustsec.org/advisories/RUSTSEC-2026-0120.html	ADVISORY
	https://github.com/hickory-dns/hickory-dns/securi…	ADVISORY

JSON

To clipboard

{
  "affected": [
    {
      "database_specific": {
        "categories": [
          "denial-of-service"
        ],
        "cvss": null,
        "informational": null
      },
      "ecosystem_specific": {
        "affected_functions": null,
        "affects": {
          "arch": [],
          "functions": [],
          "os": []
        }
      },
      "package": {
        "ecosystem": "crates.io",
        "name": "hickory-net",
        "purl": "pkg:cargo/hickory-net"
      },
      "ranges": [
        {
          "events": [
            {
              "introduced": "0.0.0-0"
            },
            {
              "fixed": "0.26.1"
            }
          ],
          "type": "SEMVER"
        }
      ],
      "versions": []
    }
  ],
  "aliases": [
    "GHSA-3v94-mw7p-v465"
  ],
  "database_specific": {
    "license": "CC-BY-4.0"
  },
  "details": "The NSEC3 closest-encloser proof validation in `hickory-net`\u0027s\n`DnssecDnsHandle` walks from the QNAME up to the SOA owner name, building a\nlist of candidate encloser names. The iterator used assumes the\nQNAME is a descendant of the SOA owner, terminating only when the current\ncandidate equals the SOA name. When the SOA in a response\u0027s authority section\nis not an ancestor of the QNAME, the loop stalls at the DNS root and never\nterminates, repeatedly calling `Name::base_name()` and pushing newly allocated\n`Name` and hashed-name entries into the candidate `Vec`.\n\nThe bug is reachable by any caller of `DnssecDnsHandle` \u2014 including the\nresolver, recursor, and client \u2014 when built with the `dnssec-ring` or\n`dnssec-aws-lc-rs` feature and configured to perform DNSSEC validation. It is\ntriggered while validating a NoData or NXDomain response whose authority\nsection contains an SOA record from a zone other than an ancestor of the\nQNAME, on a code path that requires NSEC3 closest-encloser proof. In practice\nthis can be reached through an insecure CNAME chain that crosses zone\nboundaries into a DNSSEC-signed zone returning NoData, but the minimum\ncondition is just a mismatched SOA owner on a response requiring NSEC3\nvalidation.\n\nA `debug_assert_ne!(name, Name::root())` guards the loop body, so debug builds\nabort with a panic on the first iteration past the root. Release builds\ncompile the assertion out and run the loop unbounded, allocating until the\nprocess exhausts available memory (OOM). A reachable upstream attacker who\ncan return such a response can therefore crash a debug-built validator or\nexhaust memory on a release-built one.\n\nWe recommend all affected users update to `hickory-net` 0.26.1 for the fix.",
  "id": "RUSTSEC-2026-0120",
  "modified": "2026-05-07T08:56:41Z",
  "published": "2026-05-01T12:00:00Z",
  "references": [
    {
      "type": "PACKAGE",
      "url": "https://crates.io/crates/hickory-net"
    },
    {
      "type": "ADVISORY",
      "url": "https://rustsec.org/advisories/RUSTSEC-2026-0120.html"
    },
    {
      "type": "ADVISORY",
      "url": "https://github.com/hickory-dns/hickory-dns/security/advisories/GHSA-3v94-mw7p-v465"
    }
  ],
  "related": [],
  "severity": [],
  "summary": "NSEC3 closest-encloser proof validation enters unbounded loop on cross-zone responses"
}

Sightings

Author	Source	Type	Date	Other

Nomenclature

Seen: The vulnerability was mentioned, discussed, or observed by the user.
Confirmed: The vulnerability has been validated from an analyst's perspective.
Published Proof of Concept: A public proof of concept is available for this vulnerability.
Exploited: The vulnerability was observed as exploited by the user who reported the sighting.
Patched: The vulnerability was observed as successfully patched by the user who reported the sighting.
Not exploited: The vulnerability was not observed as exploited by the user who reported the sighting.
Not confirmed: The user expressed doubt about the validity of the vulnerability.
Not patched: The vulnerability was not observed as successfully patched by the user who reported the sighting.

Detection rules are retrieved from Rulezet.

Action not permitted

GHSA-3V94-MW7P-V465

Reporter

rustsec-2026-0118

Vulnerability from osv_rustsec

rustsec-2026-0120

Vulnerability from osv_rustsec

Tags

Sightings

Nomenclature