CVE-2026-81642 — Unbound DNSKEY digest heap overflow

Summary

All three bugs sit in the code a validating Unbound runs while checking DNSSEC data it fetched from the internet, and all three are reached through answers the resolver fetches: for CVE-2026-81642 and CVE-2026-85501 by making it look up a name in an attacker-controlled zone, for CVE-2026-81634 also by tampering with a response in flight. On a recursive resolver, a lookup is something any client can start, as can anything that makes a client resolve a name — a web page, an email, a log entry. No authentication is involved, and for CVE-2026-81634 the advisory is explicit that the overflow precedes any signature check.

CVE-2026-81642 is the serious one. When the validator digests a DNSKEY record to match it against the parent zone’s DS record, it decompresses the record’s owner name into the digest buffer. A DNSKEY whose owner name is a compression pointer into the record’s own RDATA makes that decompression overrun the buffer, and the bytes written are the attacker’s. NLnet Labs rates the outcome as denial of service and possible remote code execution. The fix checks the buffer’s capacity after decompression and before writing.

CVE-2026-81634 is in RRset canonicalisation — the routine that puts an RRset into the canonical form signatures are computed over. Its length check omitted the first owner name, so a 255-byte query name combined with a large TCP response overflows a heap buffer. Because canonicalisation runs before any signature is verified, a malicious nameserver or anyone who can tamper with a response in flight can trigger it without defeating DNSSEC. NLnet Labs scores it as denial of service only.

CVE-2026-85501 is the Unbound share of ReTrap, a family of algorithmic-complexity attacks on DNSSEC validators. Four variants apply: TagTrap floods the validator with mismatched DNSKEY, RRSIG, and DS records so that the (zone, algorithm, key tag) matching does far too much work; DelegationTrap forces the chain-of-trust walk to validate DNSKEY and DS records for deeply nested delegations; NsecTrap makes the resolver validate an excessive number of bogus NSEC records; and AdditionalTrap exploits Unbound’s former default of validating the ADDITIONAL section too. The effect is degradation of service — validator time spent on attacker-supplied records — for every client of the resolver.

ℹ️ Exposure follows DNSSEC validation. A resolver with validation enabled runs all of this code on every answer it validates; Debian’s and NixOS’s default configurations both enable it. Only a package carrying the upstream fixes closes the bugs — no configuration setting does.

Affected versions

Per the NLnet Labs advisories for CVE-2026-81642, CVE-2026-81634, and CVE-2026-85501, each of which lists “Unbound up to and including version 1.26.0” as affected. For operators building from source, NLnet Labs also publishes a patch per CVE against 1.26.0 — a minimal one (patch_<CVE>.diff) and one with the surrounding code improvements (patch_<CVE>_with.diff), linked from each advisory.

For CVE-2026-85501 the fix is a set of limits: at most 256 DNSKEY tag matches, at most 32 attempted DS operations and 32 attempted DNSKEY operations (configurable in 1.26.1 as val-hash-attempts and val-validation-attempts respectively), at most 8 NSEC or NSEC3 validations per message, and val-clean-additional now off by default so the ADDITIONAL section is no longer validated.

The same 1.26.1 release also closed six other CVEs, outside the DNSSEC validator and not tracked here — a distribution’s update for the three above will normally close these at the same time: CVE-2026-82717 (CNAME synthesis heap corruption), CVE-2026-77955 (ZONEMD verification bypass window), CVE-2026-78227 (use-after-free in the DoQ stream output buffer), CVE-2026-80225 (degradation of service from continuous queries on one TCP or DoT connection), CVE-2026-82720 (use-after-free in DoH stream cleanup), and CVE-2026-77860 (serve-expired bypassing wait-limit).

Distribution status

Fix status depends on the package version and on whether the maintainer backported the upstream patches. A distribution can carry the fixes as a -N Debian packaging revision, a patches/patch-* file (with a PKGREVISION bump) in pkgsrc, or a patch entry in the nixpkgs expression — so an older version string does not by itself mean vulnerable.

A row is Fixed once its package closes all three CVEs, at Unbound 1.26.1 or later or through backports of all three patches. A package that closes some of them but not all is marked Partial, naming the CVE still open.

Debian versions are the apt-installable value: the <suite>-security archive where it exists, since that is what hosts run and where a DSA fix lands first.

Debian

The Debian security tracker is the authoritative source for per-suite status; it carries a page per CVE (CVE-2026-81634, CVE-2026-85501) and the three agree suite for suite. sid took the upstream 1.26.1 release as 1.26.1-1, whose changelog names all nine CVEs of the release; forky inherits it through the normal testing migration. Trixie and bookworm each need a security upload backporting the patches onto their 1.22.0 and 1.17.1 bases, and both remain open in the tracker.

A default Debian install validates: the package ships /etc/unbound/unbound.conf.d/root-auto-trust-anchor-file.conf, which configures the root trust anchor, so an unpatched Debian resolver is exposed unless the operator removed that file.

pkgsrc

The pkgsrc tree (NetBSD’s package collection, also used on SmartOS, macOS via pkgin, and elsewhere) ships Unbound as net/unbound. pkgsrc-current is the rolling tip; the quarterly stable branches inherit fixes by cherry-pick, and pkgsrc-2026Q2 is the current one. pkgsrc-2026Q3 is expected around the end of September, and starts from whatever pkgsrc-current carries on the day it is cut — if the 1.26.1 update lands on pkgsrc-current first, the new branch is born fixed.

The identifier carries an nbN suffix when the package’s PKGREVISION is set. That revision bumps for many reasons besides security patches — recursive bumps for shared-library ABI changes, dependency and build-system tweaks — so an nbN suffix on its own says nothing about these CVEs. unbound-1.26.0nb1 on pkgsrc-current took its nb1 from a recursive abseil bump, not from a security patch.

Whether a pkgsrc host validates is up to its operator: the package ships no trust anchor configuration of its own.

NixOS

nixpkgs builds Unbound from a single expression, pkgs/by-name/un/unbound/package.nix; the unbound, unbound-full, and unbound-with-systemd attributes all take their version from it, so one row per channel covers every variant. A channel is fixed once its pinned version reaches 1.26.1 or the expression carries the three fixes as patches on the 1.26.0 base. The 1.26.0 bump reached master on 2026-08-07 and was backported to release-26.05 the next day, so the stable channels are as current as unstable here.

The NixOS services.unbound module enables the root trust anchor by default (enableRootTrustAnchor = true), so a NixOS resolver validates unless that option was turned off.

Each channel row’s Fixed since will be the date that channel actually publishes a release containing the fix, not the date this tracker notices it.

Flake users

A flake input like github:NixOS/nixpkgs/nixos-unstable resolves to the git branch of that name, not to the channel — but the channel bot advances the branch to exactly the revision the channel publishes, so an input following a channel name is answered by that channel’s row.

Two branches have no channel gating them and will carry the fix earlier — they are listed above as master and release-26.05:

• github:NixOS/nixpkgs/master — the fix’s first appearance anywhere in nixpkgs, the moment it is merged.
• github:NixOS/nixpkgs/release-26.05 — the ungated 26.05 branch, ahead of the nixos-26.05 channel by however long Hydra takes.

Their Fixed since will be the commit date of the version bump, not a channel release date: an ungated branch has the fix as soon as the commit lands. That also bounds every other row — no channel can be fixed before the branch it is cut from.

Detection

To check whether a running Unbound is on a fixed build:

unbound -V | head -1

• 1.26.1 or later ⇒ fixed.
• Anything older ⇒ vulnerable, unless the distribution packager has backported the upstream patches (see the per-distribution notes above).

To see whether the resolver validates at all — and so whether the validator code is reachable — check the running configuration for a trust anchor:

unbound-checkconf -o auto-trust-anchor-file

An empty result, together with no trust-anchor-file, trust-anchor, or trusted-keys-file setting, means validation is off and the bugs are not reached; conversely an anchor validates only while module-config still lists validator, which the default does. That is a statement about exposure, not a fix.

Debian

A Debian-side backport keeps the upstream version and bumps the packaging revision instead (the -N suffix on unstable, +debXuY on the stable suites). Query the installed package version:

dpkg-query -W -f='${Version}\n' unbound

Cross-reference the version against the Debian rows in Distribution status and, ultimately, against the Debian security tracker.

pkgsrc

Query the installed package:

pkg_info -e unbound

The output is unbound-<version> plus, if the Makefile sets PKGREVISION, the suffix nb<PKGREVISION> — for example unbound-1.26.0nb1. Cross-reference against the pkgsrc rows in the table above.

NixOS

The Unbound version in the system closure is the version = field in pkgs/by-name/un/unbound/package.nix at the channel revision the system was built from; there is no separate packaging-revision concept. Query the running build:

unbound -V | head -1

…and cross-reference against the per-channel rows in the table above.

Mitigation

There is no configuration workaround for the two heap overflows: the missing capacity checks are in code every validating resolver runs, and only a build carrying the upstream fixes closes them. Upgrade to a fixed Unbound as soon as your distribution carries one, or apply the per-CVE patches from the advisories to a 1.26.0 source build.

Until then:

• val-clean-additional: no removes the AdditionalTrap variant of CVE-2026-85501 on an unpatched build — it is the setting 1.26.1 changed the default of. It does nothing for the other three ReTrap variants or for the overflows.
• Limit who can ask. The trigger for all three is an answer the attacker shaped — usually by getting the resolver to look up a name in their zone — so a resolver that answers only its own networks (access-control) narrows the set of parties who can start one. It does not remove the risk: any client, and anything that makes a client resolve a name, still can, and an on-path attacker needs no client at all.
• Watch for crashes. A validating resolver that restarts unexpectedly after the disclosure date is worth investigating rather than shrugging off.

Turning DNSSEC validation off would take the validator out of reach, at the cost of every protection it provides. Upstream does not offer it as a workaround, and neither does this tracker.

No exploit code has been published for any of the three. NLnet Labs' own threat metric (E:U, exploit maturity unreported) and CISA’s SSVC assessment (exploitation none) both record no known exploitation.

Verification log

Every verdict in the table above is backed by a checkable source. This log records the provenance — the advisory, repository index, or git reference that established each fact — so any row can be audited or reproduced. Most readers never need it.

References