Hickory DNS EUVD-2026-119340

Applies only to deployments using the affected crates (hickory-proto through 0.26.0-alpha.1, hickory-net 0.26.0-beta.1 through 0.26.1) with DNSSEC validation enabled for positive-response handling. The attacker must be able to deliver a DNS response to the validating resolver - e.g. an on-path position, control of a malicious authoritative server in the resolution path, or successful off-path UDP spoofing - and must possess any validly signed RRset to place in the answer section. Limiting factors: the impact is bounded to integrity (converting a legitimate no-data result into an accepted positive answer); there is no confidentiality or availability effect, no code execution, and non-DNSSEC-validating paths are unaffected. hickory-net users can fully remediate by updating to 0.26.2; for hickory-proto no fixed version is available yet per the advisory.

This is a medium-severity DNSSEC validation bypass (input CVSS 4.0 base 6.9; my independent assessment lands lower, ~5.3 CVSS 3.1, because the only impact is low integrity). The input CVSS 4.0 vector (AV:N/AC:L/AT:N/PR:N/UI:N) describes network reach with no privileges or user interaction, which fits a resolver accepting attacker-supplied responses, but it understates a practical precondition: an attacker must be positioned to deliver DNS responses (on-path, operating a malicious authoritative server, or successfully spoofing off-path) - that is a real limiter the metrics do not capture. Exploitation signals are modest and consistent: no CISA KEV listing, no EPSS score provided, and no public exploit identified at time of analysis (the references are the GHSA and VulnCheck advisories, not PoC or working exploit code). The vuln.today decision label is 'this_month', not act_now/emergency, which aligns with a genuine but non-urgent validation flaw rather than a mass-exploited issue. Impact is confined to integrity: forged positive answers where a no-data response was correct (VC:N/VI:L/VA:N), so this is a correctness/spoofing weakness, not RCE or data theft. Treat it as a real priority for DNSSEC-validating deployments of the affected Rust crates, but not an emergency.

An attacker able to answer a victim resolver's queries (on-path, a malicious authoritative server, or UDP spoofing) returns a response whose answer section contains a validly signed but unrelated RRset instead of records matching the query. Because the resolver only checks that some valid RRset exists rather than that it is responsive to the query, it accepts the message as a positive answer rather than treating it as no-data, letting the attacker suppress or misrepresent the true (non-)existence of a record. No public exploit code was identified at time of analysis; the trigger mechanism is described in the vendor advisory.