CVE-2026-93657: hickory-resolver DNSSEC Auth Bypass Flaw

CVE-2026-93657 Overview

CVE-2026-93657 affects the hickory-resolver Rust crate in versions prior to 0.26.2. The library fails to propagate bogus Domain Name System Security Extensions (DNSSEC) proof states through the Resolver::lookup() and Resolver::lookup_ip() APIs. Invalid records are returned to callers as successful lookup results, bypassing DNSSEC authentication guarantees. Attackers who control the answering zone or occupy a network path position can forge DNS records that consuming applications accept as validated. The weakness is classified under [CWE-347: Improper Verification of Cryptographic Signature].

Critical Impact
Applications relying on hickory-resolver for DNSSEC-validated responses may accept spoofed or tampered DNS records, undermining the integrity guarantees that DNSSEC is designed to provide.

Affected Products

hickory-resolver crate versions before 0.26.2
Hickory DNS project components that consume the resolver APIs
Downstream Rust applications performing DNSSEC-validated lookups via Resolver::lookup() or Resolver::lookup_ip()

Discovery Timeline

2026-09-18 - CVE-2026-93657 published to NVD
2026-09-22 - Last updated in NVD database

Technical Details for CVE-2026-93657

Vulnerability Analysis

Hickory DNS is a Rust-native DNS client, server, and resolver stack. The resolver crate supports DNSSEC validation, which cryptographically verifies that DNS responses originate from the authoritative zone and have not been tampered with in transit. When validation fails, the resolver internally marks the response with a Proof::Bogus state.

Before version 0.26.2, this bogus proof state was not translated into an error at the boundary of the public Resolver::lookup() and Resolver::lookup_ip() APIs. Records with failed cryptographic verification flowed through as successful lookup results, defeating the purpose of enabling DNSSEC in the first place.

Root Cause

The root cause is an incomplete error mapping in the resolver's result path. The DnsError enumeration did not carry a DnssecBogus variant, so components downstream of validation had no way to signal that verification failed. Retry and lookup logic treated bogus responses the same as valid ones and returned them to callers.

Attack Vector

Exploitation requires an attacker to either control the answering authoritative zone or occupy a position on the network path between the resolver and upstream servers. The attacker forges DNS records for a target zone and delivers them in response to a lookup issued by an application using a vulnerable version of hickory-resolver. Because the bogus DNSSEC state is not propagated, the application accepts the forged records as authentic and acts on them, for example by connecting to an attacker-controlled host.

rust

// Security patch in crates/net/src/error.rs
// Adds an explicit error variant for failed DNSSEC validation
         /// DNSSEC proof of the record
         proof: Proof,
     },
+    /// DNSSEC validation failure
+    #[error("DNSSEC validation failed")]
+    DnssecBogus,
 }

 impl DnsError {
// Source: https://github.com/hickory-dns/hickory-dns/commit/30720f4fb22e5556ecbf26d2c8274ea4a9fdd238

rust

// Security patch in crates/net/src/xfer/retry_dns_handle.rs
// Ensures retry logic surfaces DnssecBogus as a terminal error
                 (
                     _,
                     err @ NetError::NoConnections
-                    | err @ NetError::Dns(DnsError::NoRecordsFound(_)),
+                    | err @ NetError::Dns(DnsError::NoRecordsFound(_))
+                    | err @ NetError::Dns(DnsError::DnssecBogus),
                 ) => return Poll::Ready(Some(Err(err))),
                 // Don't count `Busy` as an attempt
                 (_, NetError::Busy) => {}
// Source: https://github.com/hickory-dns/hickory-dns/commit/30720f4fb22e5556ecbf26d2c8274ea4a9fdd238

Detection Methods for CVE-2026-93657

Indicators of Compromise

Applications resolving unexpected IP addresses for domains that are known to be DNSSEC-signed.
DNS responses that contain records for signed zones without corresponding valid RRSIG chains, yet are acted upon by the application.
Outbound connections from services to hosts that do not match the authoritative zone data observed by an independent validating resolver.

Detection Strategies

Inventory Rust projects and dependency lockfiles (Cargo.lock) for hickory-resolver versions below 0.26.2.
Compare DNS answers returned by application-embedded resolvers against a known-good validating resolver such as Unbound or BIND to detect divergence.
Enable DNSSEC validation logging on network resolvers and alert on services that continue to accept records flagged as bogus upstream.

Monitoring Recommendations

Ingest DNS query and response telemetry into a centralized analytics platform and correlate against threat intelligence for zone hijacks.
Track dependency updates in CI pipelines and fail builds that pin vulnerable hickory-resolver versions.
Monitor for anomalous egress connections that follow DNS lookups for high-value domains.

How to Mitigate CVE-2026-93657

Immediate Actions Required

Upgrade hickory-resolver to version 0.26.2 or later in every affected project and rebuild dependent binaries.
Audit application code paths that call Resolver::lookup() and Resolver::lookup_ip() and confirm they now handle the new DnssecBogus error.
Rotate any secrets or credentials that may have been sent to endpoints resolved during the vulnerable window if compromise is suspected.

Patch Information

The fix is included in Hickory DNS Release v0.26.2 and delivered through the changes in Pull Request #3871 and commit 30720f4. Coordinated disclosure details are available in GitHub Security Advisory GHSA-5j98-2g5x-46v6 and the VulnCheck advisory.

Workarounds

Route DNS resolution through an external validating resolver that rejects bogus responses before they reach the application.
Restrict outbound DNS traffic to trusted resolvers over authenticated transports such as DNS over TLS (DoT) or DNS over HTTPS (DoH) to reduce on-path tampering risk.
Pin critical hostnames to known-good addresses or use certificate pinning at the application layer where DNS integrity cannot be guaranteed.

bash

# Update the crate in Cargo.toml and refresh the lockfile
cargo update -p hickory-resolver --precise 0.26.2
cargo tree -i hickory-resolver  # Verify no transitive dependency pins an older version
cargo build --release