Hickory Resolver
Monthly
hickory-resolver releases before 0.26.2 fail to propagate a 'bogus' DNSSEC proof state out of the high-level Resolver::lookup() and Resolver::lookup_ip() APIs, so records that fail DNSSEC signature validation are handed back to the caller as successful, apparently validated answers. This is an integrity-only bypass affecting unauthenticated remote attackers (CVSS:4.0 8.7 / assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) who either control the authoritative zone answering the query or sit on the network path to inject forged records with invalid RRSIGs; applications that do not compile the crate's __dnssec feature are unaffected because they never expected validation in the first place. A vendor fix is available in 0.26.2 (commit 30720f4, PR 3871), and no public exploit code or confirmed active exploitation was observed at time of analysis. This is a genuine, high-priority integrity flaw despite the absence of exploitation telemetry.
hickory-resolver releases before 0.26.2 fail to propagate a 'bogus' DNSSEC proof state out of the high-level Resolver::lookup() and Resolver::lookup_ip() APIs, so records that fail DNSSEC signature validation are handed back to the caller as successful, apparently validated answers. This is an integrity-only bypass affecting unauthenticated remote attackers (CVSS:4.0 8.7 / assessed CVSS:3.1 AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:N) who either control the authoritative zone answering the query or sit on the network path to inject forged records with invalid RRSIGs; applications that do not compile the crate's __dnssec feature are unaffected because they never expected validation in the first place. A vendor fix is available in 0.26.2 (commit 30720f4, PR 3871), and no public exploit code or confirmed active exploitation was observed at time of analysis. This is a genuine, high-priority integrity flaw despite the absence of exploitation telemetry.