CVE-2026-77860 in Unbound
Summary
by MITRE • 09/16/2026
In NLnetLabs Unbound 1.20.0 up to and including 1.26.0, a vulnerability on the 'serve-expired' code path can cause a double decrement on the 'wait-limit' counter per client IP essentially bypassing one of the counter measures that was introduced for DNSBomb (CVE-2024-33655). A malicious actor can exploit this by controlling an authoritative zone with short TTL, so cached entries expire quickly. Each 'slow' query, one the attacker's authoritative never answers, is followed by one query for an expired cached name, which is answered immediately via the 'serve-expired' path and decrements the counter twice. This second query was named 'pump'. By alternating slow queries and pumps, the attacker keeps the per-client counter at or below the configured 'wait-limit' indefinitely, and can hold an arbitrary number of pending queries from a single source IP, up to the global mesh quota (num-queries-per-thread); eventually bypassing one of the counter measures introduced for DNSBomb (CVE-2024-33655). This vulnerability is present on the 'serve-expired' code path.
If you want to get best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 09/17/2026
The vulnerability identified in NLnetLabs Unbound versions 1.20.0 through 1.26.0 represents a critical logic flaw within the DNS server's query handling mechanisms, specifically targeting the serve-expired functionality designed to mitigate cache poisoning and denial-of-service attacks known as DNSBomb. This issue effectively bypasses one of the primary countermeasures introduced in response to CVE-2024-33655 by manipulating how internal counters are decremented during specific operational states. The core technical flaw lies in a double decrement operation applied to the wait-limit counter associated with each client IP address. Under normal circumstances, this counter serves as a rate-limiting mechanism to prevent any single source from overwhelming the resolver with excessive pending queries. However, due to the logic error on the serve-expired code path, certain query sequences trigger two decrements for what should logically be treated as a single event or where the decrement is applied redundantly without proper state validation.
An attacker can exploit this vulnerability by controlling an authoritative DNS zone configured with short Time-to-Live values. By ensuring that cached entries expire rapidly, the attacker creates conditions where Unbound must rely on its serve-expired feature to respond to queries for these stale records. The exploitation strategy involves a two-step process alternating between slow and fast responses from the attacker's authority server. First, the attacker initiates a query for which their authoritative server deliberately delays or fails to answer, causing it to be classified as a slow query that consumes resources and increments internal tracking metrics. Immediately following this, the attacker sends another query for an expired cached name belonging to the same zone. Because the record is expired but still present in cache, Unbound serves it immediately via the serve-expired path rather than attempting further upstream resolution. This specific action triggers the double decrement on the wait-limit counter instead of a single one or no change depending on the exact state machine logic.
By alternating between these slow queries and pump queries, an attacker can artificially maintain the per-client wait-limit counter at or below its configured threshold indefinitely. Since the counter is decremented twice for each cycle while only effectively consuming resources once in terms of legitimate resolution attempts, the rate limiting mechanism fails to accurately reflect the actual load imposed by the client IP address. This allows the malicious actor to hold an arbitrary number of pending queries from a single source IP address. The attack scales until it hits the global mesh quota limit defined as num-queries-per-thread per thread in Unbound's configuration. Once this global limit is reached, the resolver may become unresponsive or drop legitimate traffic, resulting in a denial-of-service condition for other users relying on that specific instance of Unbound.
From an industry standard perspective, this vulnerability aligns with CWE-841 Improper Enforcement of Behavioral Workflow and CWE-756 Missing or Incorrect Logical Checkpoint, as the software fails to correctly enforce the intended state transitions regarding resource allocation limits. In terms of MITRE ATT&CK framework classification, this behavior is consistent with T1498 Network Denial of Service, specifically subtechniques involving resource exhaustion through inefficient processing loops or logic flaws that bypass rate limiting controls. The impact extends beyond simple availability loss; it undermines the integrity of DDoS mitigation strategies built into modern recursive resolvers by rendering specific anti-abuse counters ineffective against targeted attacks.
Mitigation for this vulnerability requires upgrading Unbound to a version later than 1.26.0 where the logic error in the serve-expired path has been corrected. Administrators should also consider implementing additional network-level rate limiting and monitoring tools that operate independently of application-layer counters, as reliance solely on internal software metrics can be circumvented by such logical flaws. Furthermore, configuring stricter timeouts for upstream queries and optimizing TTL values for critical zones can reduce the window of opportunity for attackers to exploit the serve-expired mechanism. Regular auditing of resolver logs against known exploitation patterns involving rapid alternation between timed-out and immediately served responses is recommended to detect ongoing attempts at this specific abuse vector before significant resource exhaustion occurs.