https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Sat, 03 Oct 2026 14:56:53 +0000 https://vulnerability.circl.lu/vuln/ghsa-37wc-h8xc-5hc4 <p><strong>Affected:</strong> crates.io: hickory-proto</p> <p>### Summary The DNSSEC validation routines treat entire RRsets of DNSKEY records as trusted once they have established trust in only one of the DNSKEYs. As a result, if a zone includes a DNSKEY with a public key that matches a configured trust anchor, all keys in that zone will be trusted to authenticate other records in the zone. There is a second variant of this vulnerability involving DS records, where an authenticated DS record covering one DNSKEY leads to trust in signatures made by an unrelated DNSKEY in the same zone.</p> <p>### Details `verify_dnskey_rrset()` will return `Ok(true)` if any record&#39;s public key matches a trust anchor. This results in `verify_rrset()` returning a `Secure` proof. This ultimately results in successfully verifying a response containing DNSKEY records. `verify_default_rrset()` looks up DNSKEY records by calling `handle.lookup()`, which takes the above code path. There&#39;s a comment following this that says &#34;DNSKEYs were already validated by the inner query in the above lookup&#34;, but this is not the case. To fully verify the whole RRset of DNSKEYs, it would be necessary to check self-signatures by the trusted key over the other keys. Later in `verify_default_rrset()`, `verify_rrset_with_dnskey()` is called multiple times with different keys and signatures, and if any call succeeds, then its `Proof` is returned.</p> <p>Similarly, `verify_dnskey_rrset()` returns `Ok(false)` if any DNSKEY record is covered by a DS record. A comment says &#34;If all the keys are va…</p> <p><strong>Affected:</strong> crates.io: hickory-proto</p> <p>### Summary The DNSSEC validation routines treat entire RRsets of DNSKEY records as trusted once they have established trust in only one of the DNSKEYs. As a result, if a zone includes a DNSKEY with a public key that matches a configured trust anchor, all keys in that zone will be trusted to authenticate other records in the zone. There is a second variant of this vulnerability involving DS records, where an authenticated DS record covering one DNSKEY leads to trust in signatures made by an unrelated DNSKEY in the same zone.</p> <p>### Details `verify_dnskey_rrset()` will return `Ok(true)` if any record&#39;s public key matches a trust anchor. This results in `verify_rrset()` returning a `Secure` proof. This ultimately results in successfully verifying a response containing DNSKEY records. `verify_default_rrset()` looks up DNSKEY records by calling `handle.lookup()`, which takes the above code path. There&#39;s a comment following this that says &#34;DNSKEYs were already validated by the inner query in the above lookup&#34;, but this is not the case. To fully verify the whole RRset of DNSKEYs, it would be necessary to check self-signatures by the trusted key over the other keys. Later in `verify_default_rrset()`, `verify_rrset_with_dnskey()` is called multiple times with different keys and signatures, and if any call succeeds, then its `Proof` is returned.</p> <p>Similarly, `verify_dnskey_rrset()` returns `Ok(false)` if any DNSKEY record is covered by a DS record. A comment says &#34;If all the keys are va…</p> https://vulnerability.circl.lu/vuln/ghsa-37wc-h8xc-5hc4