https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sun, 04 Oct 2026 17:07:36 +0000 https://vulnerability.circl.lu/vuln/cleanstart-2026-il48239 <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: ztunnel-fips</p> <p>Package ztunnel-fips version 1.30.0-r0 fixes 3 vulnerabilities: ghsa-3v94-mw7p-v465, ghsa-q2qq-hmj6-3wpp, ghsa-cq8v-f236-94qc</p> <p><strong>Withdrawn by the publisher.</strong></p> <p><strong>Affected:</strong> CleanStart: ztunnel-fips</p> <p>Package ztunnel-fips version 1.30.0-r0 fixes 3 vulnerabilities: ghsa-3v94-mw7p-v465, ghsa-q2qq-hmj6-3wpp, ghsa-cq8v-f236-94qc</p> https://vulnerability.circl.lu/vuln/cleanstart-2026-il48239 https://vulnerability.circl.lu/vuln/rustsec-2026-0118 <p><strong>Affected:</strong> crates.io: hickory-proto</p> <p>The NSEC3 closest-encloser proof validation in `hickory-proto`&#39;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&#39;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`.</p> <p>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.</p> <p>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 (…</p> <p><strong>Affected:</strong> crates.io: hickory-proto</p> <p>The NSEC3 closest-encloser proof validation in `hickory-proto`&#39;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&#39;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`.</p> <p>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.</p> <p>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 (…</p> https://vulnerability.circl.lu/vuln/rustsec-2026-0118