CVE-2026-41292

What it actually does

NLnet Labs Unbound versions up to and including 1.25.0 can spend excessive CPU time parsing DNS queries that contain unusually long lists of EDNS options. Because parsing and internal data-structure creation occur on Unbound worker threads, a remote unauthenticated attacker can repeatedly send crafted DNS queries to keep those threads busy. Coordinated traffic can degrade resolver responsiveness or cause denial of service for dependent DNS clients. The issue affects availability, not confidentiality or integrity.

Why it matters to the business

Organizations using affected Unbound resolvers may experience slow or failed DNS resolution, which can make applications, websites, identity services, monitoring, and other network-dependent operations appear unavailable even when the underlying services are healthy. The CVSS availability impact is high, but current public exploitation signals are low: EPSS is 0.00625, flat over 30 days, not listed in CISA KEV, not associated with ransomware, and no mature public exploit is reported. Because DNS is often a critical shared dependency, even a simple network-level DoS flaw should be prioritized for externally reachable or high-volume recursive resolver deployments.

How an attack unfolds

An attacker identifies an exposed Unbound resolver, typically one reachable over UDP or TCP port 53. The attacker then sends DNS queries containing an excessive number of EDNS options. Vulnerable versions parse the long option list and allocate or build internal structures before applying a practical limit, causing worker threads to remain occupied longer than normal. By sending these malformed or pathological queries at sufficient volume, or by coordinating traffic from multiple sources, the attacker can exhaust available Unbound worker capacity. Legitimate DNS queries are then delayed, time out, or fail, resulting in degraded name resolution or an outage for clients that depend on the resolver.

How to fix it

Upgrade NLnet Labs Unbound to version 1.25.1 or later. The fixed release limits acceptable incoming EDNS options to 100, preventing long option lists from monopolizing worker threads. If immediate upgrade is not possible, reduce exposure by restricting access to the resolver to trusted networks, blocking open-recursive access from the internet, rate-limiting DNS queries at network edges, filtering clearly abnormal DNS messages with excessive EDNS options where supported, and ensuring redundant resolvers are available so clients do not depend on a single vulnerable instance. Review resolver capacity and thread settings, but treat tuning as a mitigation only; it does not remove the parsing flaw.

How to confirm the fix worked

Confirm the installed Unbound version is 1.25.1 or later using package metadata or `unbound -V`. Verify that internet-facing systems do not expose unintended open recursion on UDP/TCP port 53. From an authorized test network, send benign DNS queries with normal EDNS options and confirm resolution still works, then validate that abnormal queries containing more than 100 EDNS options are rejected, truncated, rate-limited, or do not cause sustained CPU/thread exhaustion. Monitor resolver latency, query timeout rates, SERVFAIL rates, worker utilization, and CPU use before and after the upgrade to confirm normal operating behavior.

Typical attack path

1. Discover an Unbound DNS resolver reachable over the network, commonly on UDP/TCP port 53.
2. Send DNS queries that include an EDNS OPT record with an abnormally large number of EDNS options.
3. Cause vulnerable Unbound worker threads to spend excessive time parsing and constructing internal representations of the options.
4. Repeat the traffic from one or more sources to keep worker threads occupied.
5. Observe degraded DNS response times, increased timeouts, or resolver unavailability for legitimate clients.

How to detect it

Investigate for prior exploitation by reviewing DNS resolver logs, network flow records, firewall telemetry, packet captures, IDS data, and infrastructure monitoring around periods of DNS latency, timeout spikes, or Unbound CPU saturation. Look for bursts of DNS traffic to Unbound on UDP or TCP port 53 from a small set of sources or distributed sources where packets contain EDNS OPT records with unusually many EDNS options, especially more than 100. Correlate these events with elevated Unbound worker utilization, increased query processing latency, dropped queries, SERVFAIL increases, or client-side DNS timeout reports. Because successful exploitation may not create a unique application log entry, packet-level or DNS-protocol telemetry is the most reliable source. If available, use Zeek, Suricata, packet captures, DNS load balancer telemetry, or DNS firewall logs to identify messages with DNS RR type 41 OPT records and excessive EDNS option counts.

• Unbound version <= 1.25.0
• UDP/53 DNS query with EDNS OPT RR type 41 and more than 100 EDNS options
• TCP/53 DNS query with EDNS OPT RR type 41 and more than 100 EDNS options
• EDNS option count > 100
• abnormally large EDNS option list
• burst of DNS queries containing repeated EDNS OPT records
• sustained Unbound CPU saturation concurrent with DNS query spikes
• increased DNS client timeouts concurrent with EDNS-heavy traffic
• unbound -V showing version 1.25.0
• unbound -V showing version 1.24
• unbound -V showing version 1.23
• unbound -V showing version 1.22

What your security team should do

• Prioritize upgrading all Unbound deployments at or below 1.25.0 to 1.25.1 or later, especially recursive resolvers reachable from untrusted networks.
• Inventory DNS resolvers and confirm none are unintentionally operating as open resolvers exposed to the internet.
• Apply network ACLs so only authorized clients can query recursive resolvers.
• Enable or tune DNS rate limiting and upstream DDoS protections for public-facing resolver infrastructure.
• Add monitoring for spikes in DNS queries containing unusually many EDNS options, elevated resolver CPU, increased response latency, and client timeout rates.
• Review firewall, DNS, and packet-capture telemetry for evidence of abnormal EDNS-heavy query bursts since publication on 2026-05-20.
• Maintain redundant resolver paths and client failover to reduce operational impact from resolver-specific denial-of-service events.