https://vulnerability.circl.lu Contains only the most 10 recent entries. http://www.rssboard.org/rss-specification python-feedgen en Fri, 02 Oct 2026 19:50:58 +0000 https://vulnerability.circl.lu/vuln/ghsa-v7pc-74h8-xq2h <p><strong>Affected:</strong> crates.io: hickory-proto</p> <p>Summary</p> <p>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</p> <p>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 valid, then we are secure&#34;, bu…</p> <p><strong>Affected:</strong> crates.io: hickory-proto</p> <p>Summary</p> <p>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</p> <p>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 valid, then we are secure&#34;, bu…</p> https://vulnerability.circl.lu/vuln/ghsa-v7pc-74h8-xq2h