CVE-2026-44390

What it actually does

NLnet Labs Unbound versions up to and including 1.25.0 can be forced into excessive CPU work while constructing DNS replies that require name compression for very large RRsets. If queried for attacker-controlled records in a malicious upstream zone, Unbound attempts to compress names in the downstream response. In the vulnerable code path, RRsets whose records do not share a suffix above the root can trigger compression-tree lookup failures where the compression operation counter is not incremented, bypassing the intended compression limit. Repeated or coordinated queries can monopolize resolver CPU, degrade DNS resolution performance, and cause denial of service for clients that depend on the resolver.

Why it matters to the business

Organizations using Unbound as a recursive resolver, forwarding resolver, or local DNS caching service may experience slow or failed DNS lookups if attackers direct queries toward maliciously crafted DNS zones. Because DNS is a dependency for authentication, application access, updates, monitoring, and many internal services, even partial resolver degradation can create broad operational disruption. The CVSS score is moderate and EPSS is currently low, with no known KEV listing or ransomware association, but the issue is remotely reachable, unauthenticated, and can affect shared DNS infrastructure if left unpatched.

How an attack unfolds

An attacker first controls or influences an authoritative DNS zone containing specially crafted records with very large RRsets whose names do not share useful suffixes beyond the root. The attacker then sends DNS queries to a vulnerable Unbound resolver for names in that malicious zone, or causes clients behind the resolver to make those queries. Unbound retrieves the upstream response and prepares a downstream response to the requester. During response construction, Unbound performs DNS name compression. Because the crafted RRset causes compression-tree lookup failures, the vulnerable code path can fail to count those compression attempts against the configured or built-in compression limit. The resolver spends an excessive amount of CPU time completing the packet. Repeating this across many queries, source addresses, or resolver instances can degrade service and eventually deny DNS resolution to legitimate users.

How to fix it

Upgrade NLnet Labs Unbound to version 1.25.1 or later. The fix ensures the compression counter is incremented regardless of compression-tree lookup outcome, closing the bypass in the name-compression limit. Where immediate upgrade is not possible, reduce exposure by restricting who can query recursive resolvers, blocking open-recursive access from the internet, enforcing rate limits such as response rate limiting where applicable, monitoring and limiting expensive query patterns, and placing recursive resolvers behind network controls. Ensure resolver capacity and redundancy are sufficient so a single degraded resolver does not become a critical outage point. Because this complements the earlier CVE-2024-8508 fix, do not rely on being patched for only that prior issue; verify the Unbound version is beyond 1.25.0.

How to confirm the fix worked

Confirm installed Unbound versions are 1.25.1 or later using package inventory, image manifests, or commands such as `unbound -V` or the operating system package manager. Validate that recursive resolver access is restricted to intended client networks and is not openly reachable from the internet. Review configuration for access-control rules, interface exposure, and rate-limiting protections. In a controlled test environment only, query against a crafted or vendor-provided regression test zone and compare CPU utilization and response latency before and after patching. Operationally, confirm that DNS latency, SERVFAIL rates, timeout rates, and resolver CPU remain stable under normal query volume after the upgrade.

Typical attack path

1. Set up or compromise an authoritative DNS zone under attacker control.
2. Populate the zone with very large RRsets containing record names designed not to share a suffix above the DNS root.
3. Send queries to a vulnerable Unbound resolver for the crafted records, or lure systems that use the resolver into making those queries.
4. The resolver fetches the malicious upstream response and begins constructing the downstream DNS reply.
5. Unbound enters an expensive name-compression path that is insufficiently bounded in affected versions.
6. The attacker repeats or parallelizes the queries to consume resolver CPU and cause DNS latency, timeouts, or service unavailability.

How to detect it

Look for evidence of attempted or successful denial-of-service activity against Unbound resolvers rather than code execution artifacts. Relevant sources include Unbound service logs, DNS query logs if enabled, resolver telemetry, system CPU metrics, network flow records, firewall logs, and upstream authoritative DNS query traces. Investigate periods where Unbound CPU usage is high while network traffic volume is only modest, because the vulnerability amplifies CPU cost per query. Correlate spikes in DNS latency, client timeouts, SERVFAILs, or resolver thread saturation with repeated queries for the same domain, unusually large DNS answers, or domains returning very large RRsets. Look for queries to attacker-controlled or newly observed domains immediately preceding CPU saturation. There are no public threat actors or KEV exploitation reports in the provided data, so detection should focus on behavioral signs: high-cost DNS responses, repeated lookups to unusual zones, and resolver performance collapse without corresponding infrastructure failures.

• unbound: info: service stopped
• unbound: notice: Restart of unbound
• unbound: error: out of memory
• unbound: warning: so-rcvbuf
• SERVFAIL
• large RRset
• unbound -V

What your security team should do

• Prioritize upgrading all Unbound deployments to 1.25.1 or later, especially internet-reachable, shared, or high-dependency recursive resolvers.
• Identify and eliminate open recursive resolver exposure; restrict queries to trusted client networks only.
• Add monitoring for resolver CPU saturation, DNS response latency, timeout spikes, and unusual query volume to rarely seen or newly registered domains.
• Review DNS infrastructure redundancy and failover so resolver degradation does not interrupt critical business services.
• Apply rate limiting and network-layer controls where compatible with operational requirements.
• Track vendor advisories and downstream package updates for operating systems or appliances that embed Unbound, because fixed package versions may vary by distribution.
• Perform post-upgrade validation with version checks and resolver health metrics rather than relying only on package deployment status.