CVE-2026-44608
Description
NLnet Labs Unbound 1.14.0 up to and including version 1.25.0 has a locking inconsistency vulnerability that when certain conditions are met (multi-threaded, RPZ XFR reload, RPZ zone with 'rpz-nsip'/'rpz-nsdname' triggers) it could result in heap use-after-free and eventual crash. An adversary can exploit the vulnerability if conditions are first met on a vulnerable Unbound, i.e., multi-threaded, an RPZ zone with 'rpz-nsip'/'rpz-nsdname' triggers and an ongoing XFR for that RPZ zone. Local RPZ files do not trigger the vulnerability. If the timing is right and an XFR happens at the same time another thread needs to read that RPZ zone, the reader may not hold the lock long enough and the thread applying the XFR may free objects that the reader is about to walk causing the use-after-free. Unbound 1.25.1 contains a patch with a fix to the locking code.
AI Insight
LLM-synthesized narrative grounded in this CVE's description and references.
A locking inconsistency in Unbound 1.14.0-1.25.0 can cause heap use-after-free and crash when multi-threaded with RPZ XFR and specific triggers.
Vulnerability
A locking inconsistency vulnerability exists in NLnet Labs Unbound versions 1.14.0 up to and including 1.25.0. The bug is triggered when the server is multi-threaded, uses an RPZ (Response Policy Zone) with rpz-nsip or rpz-nsdname triggers, and performs an XFR (zone transfer) reload of that RPZ zone. Local RPZ files do not trigger the vulnerability. The race condition occurs because the reader thread may not hold the lock long enough, allowing the thread applying the XFR to free objects that the reader is about to walk, leading to a heap use-after-free [1].
Exploitation
An adversary can exploit this vulnerability only if the required conditions are first met on a vulnerable Unbound instance: multi-threaded operation, an RPZ zone configured with rpz-nsip or rpz-nsdname triggers, and an ongoing XFR for that RPZ zone. The exploitation relies on precise timing: if an XFR update occurs concurrently with another thread reading the same RPZ zone, the reader may access freed memory. No authentication or network position beyond triggering the XFR is needed, but the attacker must be able to initiate or influence the XFR (e.g., via a malicious primary DNS server). The race window is narrow, making exploitation probabilistic [1].
Impact
Successful exploitation results in a heap use-after-free, which typically causes an immediate crash of the Unbound process, leading to a denial of service (DoS). The vulnerability does not appear to allow arbitrary code execution or information disclosure based on the available references. The crash disrupts DNS resolution for clients relying on the affected server [1].
Mitigation
The vulnerability is fixed in Unbound version 1.25.1, released on 2026-05-20. Users should upgrade to this version or apply the provided patch for 1.25.0 from the NLnet Labs advisory [1]. The patch addresses the locking code to ensure proper synchronization during RPZ XFR reloads. No workaround is available for versions prior to 1.25.0; upgrading is the only mitigation.
AI Insight generated on May 21, 2026. Synthesized from this CVE's description and the cited reference URLs; citations are validated against the source bundle.
Affected products
2Patches
175b6dba593d4- Fix CVE-2026-44608, Use after free and crash in RPZ code. Thanks
2 files changed · +8 −4
doc/Changelog+2 −0 modified@@ -25,6 +25,8 @@ - Fix CVE-2026-44390, Unbounded name compression in certain cases causes degradation of service. Thanks to Qifan Zhang, Palo Alto Networks, for the report. + - Fix CVE-2026-44608, Use after free and crash in RPZ code. Thanks + to Qifan Zhang, Palo Alto Networks, for the report. 23 April 2026: Wouter - Merge #1441: Fix buffer overrun in
services/rpz.c+6 −4 modified@@ -2469,6 +2469,7 @@ rpz_callback_from_iterator_module(struct module_qstate* ms, struct iter_qstate* { struct auth_zones* az; struct auth_zone* a; + struct dns_msg* ret = NULL; struct clientip_synthesized_rr* raddr = NULL; struct rpz* r = NULL; struct local_zone* z = NULL; @@ -2512,13 +2513,11 @@ rpz_callback_from_iterator_module(struct module_qstate* ms, struct iter_qstate* z = rpz_delegation_point_zone_lookup(is->dp, r->nsdname_zones, is->qchase.qclass, &match); if(z != NULL) { - lock_rw_unlock(&a->lock); break; } raddr = rpz_delegation_point_ipbased_trigger_lookup(r, is); if(raddr != NULL) { - lock_rw_unlock(&a->lock); break; } lock_rw_unlock(&a->lock); @@ -2533,9 +2532,12 @@ rpz_callback_from_iterator_module(struct module_qstate* ms, struct iter_qstate* if(z) { lock_rw_unlock(&z->lock); } - return rpz_apply_nsip_trigger(ms, &is->qchase, r, raddr, a); + ret = rpz_apply_nsip_trigger(ms, &is->qchase, r, raddr, a); + } else { + ret = rpz_apply_nsdname_trigger(ms, &is->qchase, r, z, &match, a); } - return rpz_apply_nsdname_trigger(ms, &is->qchase, r, z, &match, a); + lock_rw_unlock(&a->lock); + return ret; } struct dns_msg* rpz_callback_from_iterator_cname(struct module_qstate* ms,
Vulnerability mechanics
Root cause
"Improper resource locking in the RPZ zone reload path allows a use-after-free when one thread frees RPZ data structures while another thread is still reading them."
Attack vector
An attacker must first set up conditions on a vulnerable Unbound instance: it must be running multi-threaded, have an RPZ zone configured with 'rpz-nsip' or 'rpz-nsdname' triggers, and have an ongoing XFR (zone transfer) for that RPZ zone. Local RPZ files do not trigger the vulnerability. When an XFR reload occurs concurrently with another thread reading the same RPZ zone, the reader may not hold the lock long enough, and the thread applying the XFR can free objects that the reader is about to walk, causing a use-after-free [CWE-413]. An attacker who can trigger or influence the timing of an RPZ XFR reload can exploit this to cause a crash.
Affected code
The vulnerability affects the RPZ (Response Policy Zone) reload code path in NLnet Labs Unbound versions 1.14.0 through 1.25.0. The advisory does not specify exact function names or file paths, but the locking inconsistency occurs in the code that handles concurrent XFR reloads and reader access to RPZ zone data structures. The patch [patch_id=792199] modifies the locking logic in this area.
What the fix does
The patch [patch_id=792199] modifies the locking code in the RPZ reload path. The advisory states that the reader may not hold the lock long enough while the XFR-applying thread frees objects the reader is walking. The fix ensures proper lock acquisition and release ordering so that a reader thread retains exclusive access to the RPZ data structures until it has finished walking them, preventing the concurrent XFR thread from freeing objects still in use. This closes the use-after-free by enforcing correct mutual exclusion during RPZ zone reloads.
Preconditions
- configUnbound must be configured to run multi-threaded
- configAn RPZ zone must be configured with 'rpz-nsip' or 'rpz-nsdname' triggers
- networkAn ongoing XFR (zone transfer) for that RPZ zone must be in progress
- inputThe XFR reload must occur concurrently with another thread reading the same RPZ zone
Generated on May 20, 2026. Inputs: CWE entries + fix-commit diffs from this CVE's patches. Citations validated against bundle.
References
1- www.nlnetlabs.nl/downloads/unbound/CVE-2026-44608.txtnvdMitigationVendor Advisory
News mentions
0No linked articles in our index yet.