CVE-2026-33278

What it actually does

CVE-2026-33278 is a remotely reachable use-after-free flaw in the DNSSEC validation logic of NLnet Labs Unbound versions 1.19.1 through 1.25.0. The bug occurs when Unbound validates responses involving DS sub-queries that are suspended after NSEC3 computational budget exhaustion. During that suspension path, Unbound deep-copies response message structures so they can survive memory-region teardown, but an erroneous struct assignment overwrites a destination pointer with a pointer from the source structure. After the original memory region is freed, validation later resumes and dereferences a dangling pointer. The most likely result is a resolver crash and denial of service; because the bug is memory-corruption in a network-facing process, remote code execution may be possible depending on allocator behavior, platform hardening, build options, and exploit reliability.

Why it matters to the business

Organizations running vulnerable Unbound resolvers could experience DNS resolution outages if an attacker causes the daemon to crash repeatedly. Because DNS is a foundational dependency for application access, authentication, software updates, service discovery, email delivery, monitoring, and incident response workflows, exploitation can create broad operational disruption even if no data is directly targeted. The CVSS severity is critical, but current public exploit maturity is reported as none, EPSS is low and flat over 30 days, and the issue is not currently listed in CISA KEV; nevertheless, internet-exposed recursive resolvers and infrastructure DNS services should be prioritized because the attack is unauthenticated and network-reachable.

How an attack unfolds

An attacker first prepares or controls a malicious DNSSEC-signed zone designed to drive vulnerable Unbound validation into the specific DS sub-query suspension path associated with NSEC3 computational budget exhaustion. The attacker then causes a vulnerable Unbound resolver to query records in that zone, either directly if they can send recursive queries to the resolver or indirectly by inducing a user, application, mail server, proxy, scanner, or other internal system to resolve attacker-controlled names. During validation, Unbound exhausts the NSEC3 computation budget, suspends DS sub-query validation, and deep-copies response messages across memory regions. The vulnerable copy operation corrupts pointer ownership by replacing the destination pointer with a source pointer. When the source memory region is later torn down and validation resumes, Unbound dereferences the freed pointer. This can terminate the Unbound process, causing DNS resolution failure. In a more advanced scenario, an attacker may attempt to shape memory layout and DNS response contents to turn the dangling pointer dereference into controlled memory corruption and possible code execution in the Unbound process context.

How to fix it

Upgrade NLnet Labs Unbound to version 1.25.1 or later, which fixes the incorrect pointer handling during deep copy. Treat versions 1.19.1 through 1.25.0 as affected. If immediate upgrade is not possible, reduce exposure by restricting recursive DNS access to trusted clients only, blocking open-recursive resolver behavior, rate-limiting abusive query sources, and ensuring Unbound runs with least privilege, sandboxing, ASLR, stack protections, and service manager restart limits. Disabling DNSSEC validation may avoid the vulnerable validation path but weakens DNS integrity protections and should only be considered as a short-term emergency workaround after risk review. Where feasible, deploy redundant resolvers so a crash of one resolver does not create a full DNS outage.

How to confirm the fix worked

Confirm installed Unbound versions with package-manager inventory and `unbound -V`; any version from 1.19.1 through 1.25.0 should be considered vulnerable, and 1.25.1 or later should be considered fixed. Verify all running resolver instances have been restarted after upgrade so the patched binary is active. Confirm recursive service is not open to the internet unless explicitly intended by testing access controls from untrusted networks. Review configuration for DNSSEC validation status, because the described vulnerable path is in the DNSSEC validator. For operational validation, monitor that the Unbound service remains stable under normal DNSSEC-validating workloads and that no recurring crash/restart loop occurs after remediation.

Typical attack path

1. Identify or assume the target uses Unbound 1.19.1 through 1.25.0 as a recursive resolver with DNSSEC validation enabled.
2. Register, compromise, or otherwise control a DNSSEC-signed zone.
3. Craft DNSSEC/NSEC3 responses that trigger DS sub-query suspension due to NSEC3 computational budget exhaustion.
4. Send recursive DNS queries to the vulnerable resolver, or induce systems that use it to resolve attacker-controlled domain names.
5. Trigger the vulnerable deep-copy path during DNSSEC validation.
6. Cause Unbound to resume validation after the original memory region has been freed.
7. Crash the Unbound daemon or, in a more sophisticated attack, attempt to gain code execution through use-after-free memory corruption.
8. Repeat queries to sustain denial of service if the resolver is automatically restarted.

How to detect it

Look for evidence of exploitation primarily in DNS resolver logs, system logs, crash dumps, service-manager logs, package inventory, and network DNS telemetry. Useful signs include unexpected Unbound process crashes or restarts, segmentation faults, core dumps involving the Unbound process, spikes in SERVFAIL responses, bursts of DNSSEC validation errors, and repeated resolution attempts for unusual or newly observed DNSSEC-signed domains shortly before a crash. Because exploitation depends on attacker-controlled signed zones and NSEC3-related validation behavior, correlate crash times with query logs for domains that produced DNSSEC, DS, DNSKEY, NSEC3, or validation-related activity. If core dumps are available, inspect stack traces for Unbound validator code paths and dangling-pointer or invalid-read faults. At the network level, search for query bursts to domains with complex DNSSEC/NSEC3 responses followed by resolver instability. There are no widely reported public exploit strings or named threat actors for this issue at this time, so detection should focus on behavioral evidence rather than a single fixed signature.

• unbound: segfault
• segfault at
• unbound.service: Main process exited
• unbound.service: Failed with result 'core-dump'
• unbound.service: Scheduled restart job
• Process: unbound
• comm="unbound"
• /var/lib/systemd/coredump/core.unbound
• core.unbound
• NSEC3
• DNSSEC validation failed
• validation failure
• SERVFAIL
• DS query
• DNSKEY
• unbound -V

What your security team should do

• Inventory all Unbound resolver deployments, including appliances, containers, embedded DNS stacks, and downstream packages that may bundle Unbound.
• Prioritize upgrading internet-facing or widely used recursive resolvers to Unbound 1.25.1 or later.
• Restrict recursive query access to trusted client networks and eliminate unintended open resolvers.
• Review DNS resolver telemetry for crashes, restarts, segmentation faults, and repeated queries to unusual DNSSEC-signed domains since publication.
• Ensure systemd, init, container, and orchestration logs are retained long enough to investigate historical resolver crashes.
• Deploy redundant DNS resolver capacity and alert on resolver availability, SERVFAIL spikes, process restarts, and abnormal DNSSEC validation failures.
• If immediate patching is delayed, apply compensating controls such as ACLs, query-rate limits, egress monitoring for suspicious domain resolution patterns, and service restart throttling.
• Track vendor advisories and downstream operating-system package updates to ensure patched package versions map to the upstream 1.25.1 fix.