Hickory DNS Multiple Security Flaws

DNSSEC nonexistence forgery in the Hickory DNS hickory-net crate 0.26.0 and 0.26.1 allows an attacker who can supply DNS responses to a validating resolver to forge denial of existence for arbitrary RRsets by pairing a genuine NSEC record and its RRSIG with a crafted SOA record. The flaw is an authentication bypass (CWE-290) in the wraparound-NSEC coverage check, which trusts a response SOA even when that SOA fails validation; deployments that do not perform DNSSEC validation are unaffected. No public exploit code was identified at time of analysis and there is no CISA KEV entry, but the impact is integrity-only and remote, with no authentication or user interaction required (PR:N/UI:N); exploitation requires the attacker to be positioned to deliver the response to the validator, such as a malicious or compromised upstream resolver, an on-path interceptor, or successful response injection.

Denial of service in the Hickory DNS recursive resolver: unauthenticated remote attackers who control two cyclic sibling zones lacking glue records can drive repeated upstream lookups until the per-request query budget is exhausted, with zero-TTL NS records amplifying the volume. Affected are hickory-recursor 0.25.0-alpha.3 through 0.25.2, which the advisory lists as not yet patched, and hickory-resolver 0.26.0-alpha.1 and later, fixed in 0.26.2. Impact is confined to availability (VC:N/VI:N/VA:H), no public exploit code has been identified at time of analysis, and this is a genuine but bounded availability risk rather than a top-tier emergency.

Referral fan-out in the Hickory DNS recursor lets remote unauthenticated attackers exhaust recursor resources or flood third-party authoritative servers by returning referrals whose NS targets are out-of-bailiwick and carry no glue records. Affected are the hickory-recursor crate 0.25.0-alpha.3 through 0.25.2 and hickory-resolver 0.26.0-alpha.1 through 0.26.1 when the opt-in 'recursor' feature is enabled (the resolver line is fixed in 0.26.2); the recursor walks every NS target in the referral and issues A and AAAA lookups for each with no per-query upstream work budget. Impact is availability-only (CVSS 8.7, CWE-400), no public exploit identified at time of analysis, and the GHSA characterizes it as the same class as the 2020 NXNSAttack (CVE-2020-8616 / CVE-2020-12662).

Denial of service in the Hickory DNS hickory-proto zone file parser: parsing a zone file containing a single token of 4096 bytes or longer causes the parser to panic. Affected releases are hickory-proto 0.24.0 through 0.26.1; exposure is limited to applications that actually parse zone files from an untrusted source, while deployments that only parse operator-controlled zone files are not reachable through this path. The vendor advisory provides the fix in 0.26.2, and no public exploit code was identified at time of analysis.

DNSSEC validation bypass in Hickory DNS lets an attacker who controls any single DNSSEC-signed zone mint cryptographically valid RRSIGs over records in unrelated zones, so resolvers, recursors and clients using DnssecDnsHandle accept forged data as authenticated. Affected are hickory-proto 0.1 through 0.25.0-alpha.3 and hickory-net v0.26.0-beta.1 through 0.26.1 when built with the dnssec-ring or dnssec-aws-lc-rs feature and configured to validate DNSSEC; hickory-proto 0.25.0-alpha.4 and later are not affected, and hickory-net is fixed in 0.26.2. The issue is rated 8.7 (CVSS:4.0 AV:N/AC:L/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H) and the assessed impact is high-integrity rather than availability-driven; no public exploit identified at time of analysis and no CISA KEV listing, though the referenced advisory is public and priority is this-week remediation.

Hickory DNS can be induced to accept forged DNSSEC nonexistence proofs in its NSEC3 validation path, allowing a response-supplying attacker to make a signed name appear absent from a zone and thereby bypass DNSSEC denial-of-existence authentication. The flaw affects hickory-net 0.26.0-beta.1 through 0.26.1 (fixed in 0.26.2) and hickory-proto through 0.26.0-alpha.1, and requires the library to act as a DNSSEC-validating resolver plus an attacker able to inject DNS responses and supply a cross-zone NSEC3 record with a matching hashed label. The independent assessment rates the impact as integrity-only; no public exploit was identified at time of analysis.

Memory exhaustion in Hickory DNS's DNS-over-HTTPS HTTP/2 server before 0.26.2 allows remote unauthenticated attackers to open DoH connections, send incomplete request bodies, and hold them open until server memory is depleted and availability suffers. Only instances that expose the DoH HTTP/2 listener are affected, and reverse-proxy connection and timeout limits or restricting access to that port reduce exposure. No public exploit identified at time of analysis; the complete fix is upgrading to 0.26.2, and this is a genuine, moderately prioritized availability risk rather than a critical emergency.

Memory exhaustion in Hickory DNS 0.24.0 through 0.26.1 allows remote unauthenticated attackers to consume server memory by opening many DNS-over-QUIC connections and sending only large length prefixes, leaving pre-allocated buffers pending without a timeout. The impact is availability-only: no code execution, data disclosure, or integrity loss is involved, and only deployments that expose the DNS-over-QUIC server are affected. No public exploit was identified at time of analysis, and no vendor-released patch is yet available.

Hickory DNS's recursive resolver can be pushed into a persistent denial-of-service state for a whole zone: when it follows a referral that carries no glue records and every lookup for the name servers' IP addresses fails, it constructs a connection pool containing no connections and caches it, so all later queries for that zone fail until the cache entry expires or is evicted. All versions of the hickory-recursor crate and hickory-resolver 0.26.0 through 0.26.1 are affected, with 0.26.2 fixing the resolver. The condition requires an attacker able to spoof DNS responses and force the name-server address lookups to fail, which is why the assessed vector is network-reachable but high complexity (AC:H) even though the published CVSS 4.0 score is 8.7; no public exploit code or CISA KEV entry was identified at time of analysis.

DNSSEC validation bypass in Hickory DNS allows a crafted response built from legitimately signed parent-side NSEC3 records to make a validating recursor cache NXDOMAIN or NODATA with AD=1 for names that exist at and below a zone cut. hickory-proto 0.25 through 0.26.0-alpha.1 and hickory-net 0.26.0-beta.1 before 0.26.2 are affected; hickory-net is fixed in 0.26.2, while the advisory lists no patched hickory-proto release. No public exploit identified at time of analysis, and the assessed impact is integrity and availability (C:N/I:L/A:H), not confidentiality.

Forged NXDOMAIN responses can make Hickory DNS's validating recursor return authenticated denial of existence (AD=1) for names that genuinely exist below a zone cut, suppressing resolution of legitimate child-zone records for the duration of the negative TTL. Affected are hickory-proto through 0.26.0-alpha.1 and hickory-net 0.26.0-beta.1 through 0.26.1 running with DNSSEC validation enabled; the attacker needs to land exactly one crafted response, either from an on-path position, via a rogue parent/TLD nameserver, or by winning a source-port plus transaction-ID race. No public exploit code or confirmed active exploitation was identified at time of analysis, the CVSS 4.0 score is 8.7 against an independently assessed CVSS 3.1 vector of AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:H/A:H, and the issue is tracked as a this_week priority rather than a mass-exploitation emergency.

A resource-exhaustion denial of service in the hickory-resolver name server pool (versions 0.26.0-beta.1 through 0.26.1, fixed in 0.26.2) lets an attacker-controlled authoritative DNS server keep the resolver spinning by setting the truncated (TC) header bit on every response, including over the persistent TCP connection. Because the NameServerPool::try_send retry arm re-queues truncated requests without checking which transport answered or counting iterations, each affected query burns its full 5-second wall-clock deadline, allowing repeated queries to exhaust resolver resources. No public exploit code is identified at time of analysis and the issue is not recorded as actively exploited (CISA KEV); this is a genuine availability risk but a narrow one, since the attacker must control or influence the authoritative response path for a name the target resolves, and per-request impact is bounded by the 5-second deadline rather than a permanent lockup. There is no confidentiality or integrity impact.

Hickory DNS can be driven into an unbounded loop that panics debug builds and exhausts memory in release builds when DNSSEC validation is enabled and a crafted NoData or NXDomain response carries an authority-section SOA record that is not an ancestor of the QNAME. Affected are hickory-proto 0.25.0-alpha.3 through 0.25.2 and hickory-net 0.26.0-alpha.1 through 0.26.0 when built with the dnssec-ring or dnssec-aws-lc-rs feature and configured to validate DNSSEC; callers include the resolver, recursor and client. The attacker must be a reachable upstream party able to return the malformed response, making this a bounded availability threat rather than a confidentiality or integrity risk; no public exploit code was identified at time of analysis.

CPU exhaustion in hickory-proto 0.3.1 through 0.26.0 lets remote attackers force quadratic-time work during DNS message encoding by supplying record-heavy input that creates many compression-candidate labels and triggers repeated linear scans. Any deployment that encodes attacker-influenced DNS messages with an affected version is exposed, and the vector indicates no authentication or user interaction. This is a genuine denial-of-service issue rather than a drop-everything emergency; it is fixed in 0.26.1, with no public exploit identified at time of analysis.

Denial of service in hickory-dns (hickory-proto) 0.20.1 through 0.26.1: feeding the presentation-format zone file parser an SVCB (RR type 64) or HTTPS (RR type 65) record whose service parameter value is replaced by a lone single or double quote triggers a panic that crashes the parsing process. Only deployments that parse attacker-influenced or externally supplied zone files are realistically exposed, since the flaw requires untrusted zone data to reach the parser; no confidentiality or integrity impact is involved, only process availability. No public exploit code was identified at time of analysis and the issue is not in CISA KEV, though the CVSS 4.0 base score of 8.7 and the 'this_week' priority label reflect a straightforward remote, no-interaction trigger once such data is parsed.

Hickory DNS (the Rust DNS library formerly known as Trust-DNS), in hickory-server versions 0.24.0 through 0.26.1, buffers DNS-over-HTTP request bodies in memory without any size limit, so a remote unauthenticated client can stream oversized bodies over HTTP/2 or HTTP/3 and exhaust server memory until the process or host becomes unavailable. Impact is availability-only (CVSS 4.0 8.7, AV:N/AC:L/PR:N/UI:N, VA:H); only deployments actually exposing a DoH listener with HTTP/2 or HTTP/3 are exposed, while classic UDP/TCP DNS servers are unaffected. No public exploit code and no confirmed active exploitation were identified at time of analysis, though the missing bound makes the attack trivial to attempt against any reachable DoH endpoint.

DNSSEC validation in Hickory DNS can be tricked into accepting forged proofs of nonexistence, letting an attacker who can inject DNS responses into a resolver's path deny legitimate names (high availability impact, low integrity impact, no confidentiality impact). The flaw is an inverted pair of relational operators in the wrap-around branch of find_covering_record() in nsec3.rs, which causes the last NSEC3 record in a zone's hash ring to be treated as covering every hash except its owner name; replaying that ordinary, queryable NSEC3 record together with its RRSIG is enough to manufacture a DNSSEC-validated NXDOMAIN/NODATA answer. Affected versions are hickory-net 0.26.0-beta.1 through 0.26.1 (fixed in 0.26.2) and hickory-proto 0.25.0 through 0.26.0-alpha.1 (no patched release listed at time of analysis), and only deployments with DNSSEC validation enabled are exposed; no public exploit is identified at time of analysis, and exploitation additionally requires an on-path/MITM or winning off-path spoofing position, which is reflected in AC:H in the assessed CVSS 3.1 vector and AT:P in the CVSS 4.0 vector.

Malformed UDP response handling in the hickory-net crate of Hickory DNS 0.26.0 and 0.26.1 allows unauthenticated remote attackers to abort in-flight client queries, causing denial of service. When a client UDP socket waiting on a name server receives a datagram that cannot be parsed as a DNS message, it stops listening and returns an error instead of discarding the packet; because the attacker only has to guess the connection's source port and does not need the DNS transaction ID, spoofed garbage packets can terminate queries. Availability-only impact (C:N/I:N/A:H) with high attack complexity, fixed in 0.26.2; no public exploit identified at time of analysis.

The Hickory DNS recursor keeps using apex NS records it learned from the child side of a delegation even after the parent zone has revoked or changed that delegation, so stale name servers can keep answering for a zone. Affected code is the hickory-recursor crate in all versions and hickory-resolver 0.26.0-beta.1 through 0.26.1 when the optional 'recursor' feature is enabled; resolvers built without that feature are not affected. An unauthenticated remote attacker who controls (or once controlled) a zone's delegated name servers can repeatedly send '<zone>. IN NS' queries to keep the RRset cached indefinitely, and once the parent revokes the referral the recursor still trusts the old servers, giving them control over resolution of the zone. No public exploit code has been identified at time of analysis, and the flaw is scored 8.2 under CVSS 4.0 (with a 3.1 assessment of AC:H, I:H) because the integrity impact only materializes after a delegation change the attacker does not control.

DNSSEC validation bypass in Hickory DNS lets an attacker who can spoof resolver responses reuse child-side NSEC or NSEC3 records to fake an insecure delegation and forge child-zone records. The flaw affects hickory-net 0.26.0-beta.1 through 0.26.1 (fixed in 0.26.2) and hickory-proto through 0.26.0-alpha.1 (not yet patched). No public exploit identified at time of analysis, and exploitation requires DNSSEC validation plus the ability to inject or spoof DNS responses at a zone cut.

DNSSEC validation bypass in the hickory-net crate shipped with Hickory DNS lets an attacker who controls an unsigned delegation get forged resource records accepted for a name in a signed zone, because the resolver returns NOERROR with AD=0 instead of SERVFAIL. Only resolvers running the affected hickory-net DNSSEC validation path in versions 0.26.0-beta.1 through 0.26.1 are exposed, and the attacker must be able to prime the validation cache with an Insecure verdict before the victim queries the real target, so success depends on cache state and resolution order. No public exploit code has been identified at time of analysis; priority guidance places remediation in the near-term (this week) rather than emergency response, and the vendor's only complete fix is upgrading to 0.26.2.

Hickory DNS contains a DNSSEC validation bypass in which a signed but unrelated RRset in the answer section is accepted as a positive answer to the query. The affected code is hickory-proto through 0.26.0-alpha.1 and hickory-net 0.26.0-beta.1 through 0.26.1 when DNSSEC validation is enabled; an attacker who can deliver a DNS response and has any validly signed RRset can cause a legitimate no-data response to be accepted as a positive answer. The issue is integrity-only and medium severity, no public exploit has been identified at time of analysis, and hickory-net is fixed in 0.26.2 while hickory-proto is listed as not yet patched.

IPv4-mapped IPv6 addresses are not canonicalized before being compared against deny/allow filters in the Hickory DNS Rust libraries, letting an attacker present an address in ::ffff:a.b.c.d form and slip past rules written for the plain IPv4 form. Three distinct exposures follow: hickory-resolver (0.26.0-0.26.1) can return answers that deny_answers should have stripped and, with the non-default recursor feature, query nameservers that deny_server should have blocked; hickory-proto (0.26.0-0.26.1) with the non-default access-control feature can mis-evaluate AccessControlSet rules; and hickory-server (0.25.0-alpha.1-0.26.1) built directly against the library with Server::with_access() plus register_socket() on IPv6 sockets lacking set_only_v6(true) can accept clients that should have been denied. The shipped hickory-dns binary is explicitly unaffected, every vulnerable path is opt-in and requires an administrator to have configured a filter in the first place, and no public exploit or CISA KEV entry was identified at time of analysis; the now-defunct hickory-recursor crate (0.25.0-alpha.3-0.26.0-alpha.1) is covered by the same flaw and has no fixed release listed.

Missing request-read timeout in the DNS-over-QUIC (DoQ) listener of hickory-server (hickory-dns) 0.26.1 and earlier allows a remote unauthenticated client to open a QUIC connection and request stream and hold it open indefinitely, bypassing every configured timeout and steadily consuming server resources. Impact is bounded to availability degradation on servers that have the opt-in DoQ listener enabled and reachable from untrusted networks; DNS over UDP/TCP deployments that do not run DoQ are unaffected. There is no CISA KEV entry and no public exploit identified at time of analysis, and the issue is fixed in 0.26.2; vuln.today prioritizes it for remediation this month.

Query amplification in Hickory DNS's hickory-resolver 0.25.0 through 0.26.1 lets unauthenticated remote attackers who control or inject DNS responses make the resolver follow CNAME records that are irrelevant to the original recursive query, producing unnecessary outbound queries and increased amplification. The impact is limited to availability (low) with no confidentiality or integrity effect, and exploitation requires the victim resolver to process an attacker-influenced response during recursive resolution. No public exploit has been identified at time of analysis, and the issue is fixed in 0.26.2.

DNSSEC validation bypass in Hickory DNS allows an on-path attacker to convert a genuine signed NODATA response for an existing empty non-terminal into a forged NXDOMAIN, because the NSEC validator returns a secure proof when the covering NSEC's Next Domain Name is a strict descendant of the query name. The affected components are hickory-proto through 0.26.0-alpha.1 and hickory-net 0.26.0-beta.1 through 0.26.1, with exploitation requiring the library to act as a validating resolver, an on-path adversary, and a query name that exists as an empty non-terminal. No public exploit is identified at time of analysis; impact is limited to integrity and availability of denial-of-existence answers.

Hickory DNS's DNSSEC-validating recursor can cache DNSSEC-bogus answers for up to 24 hours when a spoofed authoritative response supplies an invalid signature and a long attacker-supplied TTL. The affected Rust packages are hickory-recursor 0.25.0 through 0.26.0-alpha.1, hickory-resolver 0.26.0-alpha.1 before 0.26.2, and hickory-net 0.26.0-beta.1 before 0.26.2; hickory-resolver and hickory-net are fixed in 0.26.2, while hickory-recursor has no fixed release listed. The impact is denial of resolution for attacker-targeted names, with no confidentiality or integrity compromise, and no public exploit identified at time of analysis.

Hickory DNS UDP clients skip response validation when a reply carries an empty question section (QDCOUNT=0), letting remote attackers who can inject spoofed UDP packets bypass the question-section match and, where enabled, the 0x20 case-randomization check that normally serve as defense-in-depth against DNS spoofing. The flaw affects hickory-net 0.26.0 through 0.26.1 (fixed in 0.26.2) and hickory-proto 0.25.0 through 0.25.2 (no patched release listed in the advisory at time of analysis), and is unauthenticated per the CVSS vector (PR:N). It is a defense-in-depth weakening rather than standalone spoofing: the attacker must still satisfy remaining matching criteria such as transaction ID and source port and beat the legitimate response, which is reflected in the high attack complexity and attack prerequisites; no public exploit code has been identified, and the issue is not listed in CISA KEV. Priority signals place remediation in the this-month window rather than an emergency response.

Hickory DNS recursive resolver fails to apply out-of-bailiwick filtering to negative DNS responses in hickory-recursor 0.25.0 through 0.25.2 and hickory-resolver 0.26.0 before 0.26.2, allowing crafted NXDOMAIN/NODATA responses to carry out-of-bailiwick records that can facilitate cache poisoning. No authentication or user interaction is required, but the assessed impact is limited to low integrity and exploitation depends on an attacker being able to supply crafted negative responses; no public exploit was identified at time of analysis and the issue is not in CISA KEV.

DNSSEC validation in Hickory DNS can accept a bogus wildcard-expanded positive answer for a query that should return NODATA, allowing an unauthenticated remote attacker who can deliver a crafted response to alter the validation outcome with low integrity impact. Affected code is hickory-net 0.26.0-beta.1 through 0.26.1 and hickory-proto through 0.26.0-alpha.1; hickory-net is fixed in 0.26.2, while hickory-proto has no fixed release per the advisory. No public exploit code has been identified at time of analysis, and exploitation requires DNSSEC validation, a wildcard-containing zone, a NODATA query, and the ability to inject or forge the DNS response path.

DNSSEC validation bypass in Hickory DNS allows attackers who can supply DNS responses to a validating resolver to have forged CH- or HS-class records, including DS records, treated as secure after genuine IN-class records validate. Affected code is hickory-proto before 0.26.0-beta.1 and hickory-net 0.26.0-beta.1 through 0.26.1. The issue has integrity-only impact, requires the attacker to be able to inject or supply DNS responses, and no public exploit code is identified in the supplied intelligence.

DNSSEC-validating Hickory DNS deployments can be tricked into returning an authenticated (AD=1) NODATA answer for any record type at a zone apex, because DnssecDnsHandle marks NSEC3-signed apex NODATA responses as secure even when no NSEC3 record in the response matches the hashed query name. Affected are hickory-proto 0.25.0-alpha.3 through 0.25.2 (not yet patched) and hickory-net 0.26.0-alpha.1 before 0.26.2, but only when built with the dnssec-ring or dnssec-aws-lc-rs feature and explicitly configured to perform DNSSEC validation - a non-default, opt-in configuration. An attacker on-path between resolver and authoritative, or in control of a malicious or compromised authoritative server for the victim zone, can replay any validly signed non-apex NSEC3 from that zone together with the zone's signed SOA, suppressing resolution of apex record types for the duration of the negative-cache TTL; there is no confidentiality impact and no code execution. No public exploit code and no confirmed active exploitation were identified at time of analysis; the input CVSS 4.0 score is 6.3 (medium, gated by AT:P) while our assessed CVSS 3.1 vector is AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:L/A:L, and the vuln.today decision label is this_month.

DNSSEC validation bypass in Hickory DNS (hickory-server) 0.25.0 through 0.26.1 causes forged SOA records to be delivered to downstream clients with the AD bit set in NXDOMAIN and NODATA responses, because the resolver never checks whether that SOA record actually passed DNSSEC validation. The attacker must be able to supply forged DNS responses (an on-path position or a successful off-path spoofing effort) and the flaw only manifests when hickory-server runs as a validating recursive resolver or validating forwarder; the CVSS:4.0 vector shows PR:N, so no credentials are required. Impact is integrity-only and further constrained to clients that both delegate validation to this server and consume SOA contents - there is no confidentiality or availability impact. No public exploit code has been identified at time of analysis and the issue is not in CISA KEV; a vendor patch exists in 0.26.2.

DNSSEC validation bypass in Hickory DNS lets an attacker who can supply DNS responses forge nonexistence proofs for records that actually exist. hickory-net 0.26.0-beta.1 through 0.26.1 and hickory-proto through 0.26.0-alpha.1 are affected when DNSSEC validation is enabled; the attacker must be on-path or control an upstream/authoritative server and mix a validly signed same-name record with bogus NSEC or NSEC3 records in the authority section. No public exploit was identified at time of analysis, and the issue is assessed as mid-tier priority (this_month), with hickory-net fixed in 0.26.2 and hickory-proto not yet patched.

DNSSEC validation in Hickory DNS can be bypassed: when a resolver builds a DNSKEY RRset consisting solely of public keys that match configured trust anchors, the validator accepts it without verifying any RRSIG (the trust-anchor comparison omits the record name). An attacker positioned to spoof or control the name server responses reaching the resolver can therefore swap a secure zone's DNSKEY RRset for the root zone's public keys and extend the damage by attaching a large TTL so the forged RRset stays in cache. Affected code is hickory-net 0.26.0-beta.1 up to (excluding) 0.26.2 and hickory-proto 0.24.0 through 0.26.0-alpha.1; a fix is released only for hickory-net (0.26.2), while no public exploit code was identified at time of analysis and exploitation requires on-path or upstream name server control rather than a purely off-path position.

Hickory DNS caches transient DS lookup failures as Bogus DNSSEC validation results, causing resolvers built with DNSSEC support to return SERVFAIL for every name under the affected child zone until the cache entry's TTL expires. The logic bug affects hickory-proto 0.25.0-alpha.1 through 0.26.0-alpha.1 and hickory-net 0.26.0-beta.1 through 0.26.1; hickory-net 0.26.2 is the fixed release. No public exploit identified at time of analysis, and the independent assessment scores it as a limited availability denial of service (CVSS 4.0 base 6.3; CVSS 3.1 AV:N/AC:H/PR:N/UI:N/S:U/C:N/I:N/A:L).