Unbound DNSSEC Heap Overflow Opens the Door to RCE

Unbound DNSSEC Heap Overflow Opens the Door to RCE

If you run Unbound as a recursive resolver, stop for a second: every release before 1.26.1 has a critical heap overflow in its DNSSEC validator. The trigger is nasty because the attacker does not need to be anywhere near your server — they just need to control a malicious DNS zone and get your resolver to query it. NLnet Labs rates the flaw Critical with a CVSS 4.0 score of 9.1, the impact is denial of service with possible remote code execution through attacker-controlled data.

There is no known in-the-wild exploitation yet — CISA's entry for CVE-2026-81642 marked exploitation as "none" as of the advisory. But this is the exact class of bug that earns pwn2own entries: a parser hole in the most trusted layer of your network, reachable by anyone who can make you resolve a name.

What the overflow actually is

The advisory describes it precisely: the overflow happens while the validator digests a DNSKEY record whose owner name is a compression pointer into the record's own data.

DNS name compression is an ancient RFC 1035 optimisation — a domain name in one part of a message can be expressed as a two-byte pointer to a previously written name, saving bytes in every response. The validator decompresses and digests DNSKEY records to build the chain of trust. A malicious zone can craft a DNSKEY whose owner name points back into its own RDATA, and Unbound's digest buffer does not guard its capacity correctly:

A DNSKEY with an owner compression pointer to its own RDATA can overflow the digest buffer. Remote code execution is possible through attacker controlled data.

So the "attacker controls a malicious zone and queries a vulnerable Unbound" — that is the described trigger, with a network vector and no privilege or user interaction required. The fix in 1.26.1 is a proper bounds check: Unbound now verifies the offending buffer's capacity after decompression and before writing.

What you need to know about scope:

• Affected: every release up to and including 1.26.0. That includes 1.25.2 — the July security release — and 1.26.0, dated August 4.
• Not this bug: the Critical validator flaw NLnet fixed back in May, CVE-2026-33278, is a different issue. Upgrading to 1.25.1 (which fixed that one) does not close this one.
• Reporting: found by Yuqi Qiu with Xiang Li at Nankai University's AOSP Lab, reported to NLnet Labs on August 11. NLnet shared a patch the next day, the reporter verified it on August 13, and the fix shipped five weeks later in the 1.26.1 batch.

Nine fixes in one release

Unbound 1.26.1, released September 16, does not just fix the DNSKEY overflow. It lands nine CVE fixes at once — a batch this size tells you the maintainers sat on a coordinated disclosure. The two worth your attention:

• CVE-2026-82717 (High): heap corruption in CNAME synthesis during an upstream response, reported by Ben Morris of Anthropic. A max-TTL rewrite combined with a stale compression pointer leaves an error path that does not move the buffer position — progressive heap corruption that can crash and, under certain systems and compilation options, could lead to remote code execution.
• CVE-2026-85501 (Medium): the ReTrap algorithmic-complexity family — TagTrap, DelegationTrap, NsecTrap, AdditionalTrap — where malicious zones burn resolver CPU with crafted DNSSEC outputs. Its fix also flips a default: val-clean-additional is now off, so Unbound stops validating DNSSEC data in the additional section of a response by default.

The rest: a 255-length query name with a large TCP response (CVE-2026-81634, High), a ZONEMD verification bypass window (CVE-2026-77955), a DoQ use-after-free on reset re-transmission (CVE-2026-78227), TCP/DoT degradation from sustained uncached queries (CVE-2026-80225), a DoH use-after-free (CVE-2026-82720), and a serve-expired bypass of the DNSBomb countermeasure that could take part in pulsing amplification attacks (CVE-2026-77860, Low).

Upgrade or patch

The fix ships as Unbound 1.26.1 source with checksums and a PGP signature, plus Windows installers and binaries. For everyone else:

# Fastest path: check what you're running, then upgrade
unbound -V
# or, on Debian/Ubuntu
dpkg -l | grep -i unbound

# If you must stay on 1.26.0 for now, apply the stand-alone patch:
wget https://nlnetlabs.nl/downloads/unbound/patch_CVE-2026-81642_with.diff
patch -p1 < patch_CVE-2026-81642_with.diff
make install

# Or the minimal variant that touches only the vulnerable code path:
wget https://nlnetlabs.nl/downloads/unbound/patch_CVE-2026-81642.diff
patch -p1 < patch_CVE-2026-81642.diff
make install

NLnet Labs has tested both stand-alone patches against 1.26.0. A combined patch for all nine fixes also exists if you want one apply instead of a full rebuild. Distro coverage is rolling in — Debian's security tracker already lists unbound 1.26.1-1 as fixed in unstable, with bookworm, trixie and forky still listed vulnerable, so apt upgrade on LTS branches will lag and needs watching.

Two operational notes while the patched versions spread:

1. Trust is the load-bearing surface here. A recursive resolver sits at the boundary of a network — it is reachable from inside by every client and from outside by anyone who can craft a query. Flaws in its zone-processing and validator code are not "just a resolver bug"; they are the same risk class as a chain of flaws being stitched into an artifact server and then exploited to plant backdoors.
2. Watch the default change. If you relied on val-clean-additional: yes to scrub extra records from responses, the ReTrap fix now defaults it to off. Re-validate your config if you want that behaviour back explicitly.

The ops takeaway

Patch Unbound like it is a router or an SSH daemon — because it is the same tier of infrastructure. The bug needs nothing more than for a victim resolver to touch a hostile zone: a poisoned SERVFAIL hunt, a zone transfer feed, or simply resolving a name whose delegation chain is attacker-controlled. That makes the full DNS/network security picture worth an audit while you are in there: check which resolvers face the internet, whether DNSSEC validation is actually on (a validator that is not validating is not exposed to this — but the ReTrap DoS family, and the whole point of having a resolver, still is), and whether your config pins val-clean-additional explicitly rather than depending on a default that just changed under you.

One critical reminder from the audit angle: the upstream May bug and this one are different CVEs with different fix releases. When you triage CVE-2026-81642 in a scanner, do not assume a "recent Unbound" is patched — confirm the binary is 1.26.1 or newer, not just newer than 1.25.0.

Sources

• NLnet Labs: CVE-2026-81642 — Unbound DNSSEC validator heap overflow
• NLnet Labs: CVE-2026-82717 — Unbound CNAME synthesis heap corruption
• NLnet Labs GitHub: Unbound 1.26.1 release notes
• The Hacker News: Critical Unbound DNSSEC Validator Flaw Could Allow RCE via a Malicious DNS Zone