NLnet Labs has disclosed a heap overflow in Unbound’s DNSSEC validator, tracked as CVE-2026-81642, that affects every release up to and including 1.26.0. The advisory rates it denial of service and possible remote code execution, because the data that overflows the buffer is the attacker’s to choose. The fixed release, 1.26.1, is out, with patches for anyone still building 1.26.0 from source.
The bug
Validation digests DNSKEY records. A DNSKEY whose owner compression pointer points into its own RDATA makes the decompressed name longer than the buffer it is being written into, and the write walks off the end of the allocation. The fix is the check that was missing: measure the buffer after decompression, before writing.
Who has to act
Anyone running Unbound as a resolver, which is a lot of people who mostly think of their DNS as “the Pi-hole thing”. The exposure comes from what a resolver is for: an adversary controls a malicious zone and asks a vulnerable Unbound to resolve a name inside it, and answering the wider internet’s questions on your behalf is the product’s whole job. There is no foothold to gain first, and no authentication to pass.
Update to 1.26.1. If you build from source, the advisory carries two patches against 1.26.0, a full one and a minimal one, applied with patch -p1 and finished with make install. Give your package manager’s version a look before assuming you are covered.
My read
A validator reads records written by strangers for a living; this is a bug in exactly that habit. DNSSEC being intact does not help, either. The malicious record is a signed DNSKEY from a zone its owner controls, which is a legitimate shape for a resolver to encounter, and the only unusual ingredient is arithmetic the attacker supplies.
The reachability note is the homelab one. Unbound sits behind Pi-hole in a lot of houses precisely because it answers only the LAN, and that instinct is fine as far as it goes: you still resolve the wider internet for everyone on the network, so the malicious zone gets queried as soon as anything there looks it up. Patch it this week.
Source: CVE-2026-81642, NLnet Labs