Unbound 1.26.2 and PowerDNS Recursor 5.4.8: 12 Resolver CVEs Explained

On 21 October 2026, NLnet Labs released Unbound 1.26.2 with five CVE fixes, and PowerDNS released Recursor 5.3.12 and 5.4.8 with seven. One flaw is shared: chains of DNS name compression pointers that burn resolver CPU. Unbound up to 1.26.1 and Recursor up to 5.3.11 and 5.4.7 are affected. Upgrade or patch now.

Neither vendor reports exploitation of any of the 12 CVEs, and neither has published a proof of concept. This is a vulnerability disclosure, not a breach. Most of the fixes address denial of service or DNSSEC validation gaps that only appear under specific, often non-default, configurations. That makes triage practical: for each resolver you run, you can work out which bugs apply before you schedule the upgrade.

Recursive resolvers sit in front of almost everything else, so a resolver outage looks like an outage of every service behind it. Both projects posted to oss-security within a minute of each other because one research team reported the decompression problem to several DNS vendors at once. And the most severe Unbound bug, a use-after-free rated High, lives in the newest protocol code: DNS-over-QUIC.

ISC also released BIND 9.20.30 on 21 October with four CVE fixes, which we covered in our BIND 9 CVE-2026-94300 explainer. One of those BIND fixes also bounds unlimited processing of inbound messages, but ISC does not describe it as part of the same multi-vendor disclosure. On the evidence we have, the link between the BIND release and this one is timing only.

What happened

NLnet Labs maintains Unbound, a validating, recursive and caching resolver written in C. PowerDNS, part of Open-Xchange, maintains PowerDNS Recursor, written in C++. Both are open source, packaged by major Linux distributions and found inside firewalls, routers, appliances and container images.

On Wednesday 21 October 2026, both projects published security releases:

• Unbound 1.26.2. NLnet Labs posted the release announcement on the NLnet Labs community forum. In his words, the release "consolidates security fixes for issues reported over a period of time." It fixes CVE-2026-35501, CVE-2026-50106, CVE-2026-96405, CVE-2026-97206 and CVE-2026-109125. Yorgos Thessalonikefs then posted a summary to oss-security with a severity for each: one High, three Medium and one Low.
• PowerDNS Recursor 5.3.12 and 5.4.8. Otto Moerbeek posted PowerDNS Security Advisory 2026-12 to oss-security, listing seven CVEs. The changelog entries for both versions carry one line each: "Fix PowerDNS Security Advisory 2026-12 for PowerDNS Recursor: Multiple Issues," referencing pull requests 18197 (5.4.8) and 18198 (5.3.12). The same mail announced a change to PowerDNS's end-of-life policy.

The common thread is CVE-2026-96405 in Unbound and CVE-2026-73206 in PowerDNS Recursor. Both describe the same class of problem. Each vendor limited pointer following per name but had no overall budget for a whole packet, which we explain below. PowerDNS's advisory calls it "a multi-vendor issue" and says multiple DNS vendors are releasing fixed versions. NLnet Labs' text opens the same way: "A multi-vendor DNS decompression vulnerability has been discovered in DNS software."

Both vendors credit the same lead researchers. NLnet Labs thanks Yuheng Zhang and Jianjun Chen of Tsinghua University, along with two industry co-researchers. PowerDNS lists the same team plus Zihan Zhang of Shanghai Jiao Tong University, and thanks them for "reporting this issue and coordinating release with other vendors."

Timeline

Times are UTC unless noted. Each row cites the source we read it from. Dates without a time are given only as dates by the source.

Two vendor dates look inconsistent. The CVE-2026-96405 record lists "Coordinated fixes released with version 1.26.2" on 16 September, before 1.26.2 existed, and PowerDNS gives CVE-2026-85559 a discovery date of 23 October, after its own advisory date. Both look like data entry slips and change nothing you need to do.

Who is affected

Who can reach these bugs

For the decompression bugs, NLnet Labs says an attacker needs recursive-query access plus control of "an ordinarily delegated authority" serving crafted replies, so even an internal resolver is reachable by anyone inside who can query a domain the attacker hosts. CVE-2026-97206 needs a remote client that can reach the DoQ port. The DNSSEC bypasses and the side channel help someone who can deliver forged responses or probe source ports.

How it works

This section explains each family in plain language. It contains no attack steps.

Name compression and the decompression budget

DNS messages save space by pointing back to names that already appear earlier in the packet. A name can end with a two-byte pointer that says, in effect, "the rest of this name is at offset N." The resolver follows that pointer to rebuild the full name. Pointers can point to names that themselves end in pointers, so following one name can mean several jumps.

Resolvers have long limited the jumps for a single name. The new reports show that is not enough: a packet can carry many names, each needing the maximum number of jumps, so the total work for one packet far exceeds what its size suggests.

The fixes add a per-packet budget. NLnet Labs states the numbers: Unbound 1.26.2 allows at most 2048 decompression steps per upstream reply packet and 128000 per zone transfer packet. PowerDNS says Recursor now limits decompression for a single name and for a packet as a whole, without publishing the values.

In both advisories the bad packet is an upstream reply from an authoritative server. The attacker needs your resolver to ask about a domain whose servers they run.

DNS-over-QUIC use-after-free in Unbound

DNS-over-QUIC (DoQ) carries DNS over QUIC, which lets a client move a connection to a new network path. NLnet Labs says a client-triggered path migration can start stream and connection cleanup while a pending reply inside Unbound still holds a pointer to that stream. Cleanup frees the stream; when the pending reply later finishes, it uses the freed memory and Unbound crashes.

The stated impact is denial of service; NLnet Labs does not claim code execution. The fix looks the stream up properly and removes the reference safely.

Three conditions must all hold: Unbound 1.22.0 or later, built with DoQ support, serving DoQ on an interface, and running with more than one thread.

Island trust anchors and two DNSSEC bypasses in Unbound

A DNSSEC "island of security" is a signed zone whose parent is not signed, so the chain from the root cannot vouch for it. Operators who care about such a zone can configure its key directly with a trust-anchor: line, alongside the normal root trust anchor.

Both bugs below need exactly that setup.

• CVE-2026-50106 (Medium, CVSS 6.5). A single forged NXDOMAIN response for a name inside the island, with signatures that name the insecure parent as signer, could steer the validator toward the root chain and then the insecure parent. A name in the island could then be made to "not exist." The fix insists the denial come from a secure, signed parent.
• CVE-2026-35501 (Low, CVSS 3.7). A forged NSEC reply with the SOA bit cleared could make Unbound treat the configured island as insecure. NLnet Labs traces it to an obsolete code path that let the NSEC skip signature validation; 1.26.2 removes it.

If you only use the root trust anchor, neither bypass applies.

A cache side channel that reveals source ports in Unbound

Resolvers resist cache poisoning by using a random source port and a random 16-bit transaction ID for each upstream query.

Unbound's optional unwanted-reply-threshold counts replies that arrive with the wrong transaction ID and, at the threshold, clears the RRset and message caches. The default is 0 (off); the documentation suggests 10 million if enabled.

CVE-2026-109125 notes that the cache flush is visible from outside and does not cancel the pending query on that port. Someone who can trigger and observe the flush could learn which source port is in use, which removes half the guessing. NLnet Labs says this is not feasible on defaults and unreliable with the suggested value, but could make poisoning feasible in some setups. The fix also clears the UDP queries waiting on the revealed port.

Out-of-band NS names and DNSSEC in PowerDNS Recursor

PowerDNS Recursor can serve some zones locally, outside the normal recursion, for example through forwarding or local authoritative zones. CVE-2026-85555 is about what happens when a delegation's NS record points to a name inside such a local zone. Validation should be skipped only while resolving that NS name. Instead, Recursor skipped validation for the rest of the query. PowerDNS rates it High, CVSS 7.5. It only matters if delegations can point into local or forwarded zones on your Recursor.

The other five PowerDNS fixes

The remaining Recursor bugs are narrower. CVE-2026-85556 accepted EDNS OPT records not owned by the root name, bypassing ECS hardening. CVE-2026-73205 lets a client push Recursor into so many TIME_WAIT sockets that new outgoing TCP connections fail. CVE-2026-85557 lets one client that never finishes a TLS handshake lock others out of the web server, but only when web server TLS is configured. CVE-2026-85559 is an out-of-bounds read in the ECS scope-zero check, only with incoming.use_incoming_edns_subnet enabled. CVE-2026-85558 is a slow leak of TCP client addresses.

Technical details

Values come from the vendor advisories, CVE records, release announcements and trackers listed in Sources.

Unbound 1.26.2: the five CVEs

PowerDNS Security Advisory 2026-12: the seven CVEs

All seven share the same version data: affects Recursor up to and including 5.3.11 and 5.4.7; first fixed in 5.3.12 and 5.4.8; dated 2026-10-21; "Risk of system compromise: None"; solution: upgrade.

The severity disagreement

PowerDNS's two publications do not agree cleanly on severity.

• The oss-security post says three CVEs are High without saying which, so anyone working from the mail alone has to guess.
• The advisory page labels exactly three CVEs High: CVE-2026-73206, CVE-2026-85555 and CVE-2026-85556. It labels CVE-2026-73205 Medium with a 5.3 score.
• CVE-2026-85556's label and score disagree. The page labels it High, but its own CVSS vector computes to 5.9, which CVSS 3.1 calls Medium. The vector has high attack complexity and integrity impact only.

We treat the advisory page as authoritative. Tools that rank by score will show CVE-2026-85556 as Medium; tools that use the vendor label will show High. If you have seen CVE-2026-73205 called High, that is not what the advisory page says.

There is also a gap in the records themselves. As of 24 October, the CVE Services API returned "record does not exist" for all seven PowerDNS IDs, so feeds that rely on CVE.org may not show them yet. Debian's tracker already lists all seven.

Release artifacts, signatures and patches

Unbound, per the NLnet Labs announcement:

NLnet Labs publishes patches that apply to Unbound 1.26.1, for teams that cannot move to 1.26.2 at once:

All are under https://nlnetlabs.nl/downloads/unbound/. NLnet Labs says each per-CVE patch is tested on 1.26.1. The "minimal" variants carry only the security change, to make backporting easier.

PowerDNS Recursor, per the oss-security post:

PowerDNS did not publish tarball hashes in the advisory or the mail, so verify the .sig files against the PowerDNS release key you already trust.

Configuration preconditions at a glance

Use this table to rank which resolvers to upgrade first. These are the preconditions as the advisories state them, not vendor workarounds. Every resolver should still be upgraded.

Distribution status

From the Debian security tracker at the time of writing:

Debian lists bookworm's Unbound 1.17.1 against CVE-2026-97206, though NLnet Labs says that bug affects only 1.22.0 and later. The pdns-recursor packages in trixie and bookworm come from trains PowerDNS lists as end of life, so fixes there must be Debian backports. We did not check other distributions.

Indicators of compromise

Neither vendor published indicators of compromise. The useful signals are operational; see step 5 below.

The coordinated decompression disclosure

The decompression issue is the part of this release that reaches beyond Unbound and PowerDNS. Here is what the primary sources do and do not establish.

Established. The same research team, led from Tsinghua University, reported the aggregate decompression problem to NLnet Labs on 16 July; PowerDNS records a discovery date of 10 July for its version of the bug. Both vendors call it multi-vendor. PowerDNS thanks the reporters for "coordinating release with other vendors." Both vendors published on 21 October, posting to oss-security 34 seconds apart.

Not established. Neither vendor names the other vendors. ISC's BIND release the same day includes CVE-2026-19630, "Amplified resource exhaustion in inbound message processing." ISC describes inbound messages with "a particular structure" that trigger extra processing with no limit, causing high CPU and memory use, and, as our BIND post notes, the 9.20.30 change log says name expansion per message is now bounded. That is similar in shape. But ISC credits it to internal testing and does not call it multi-vendor or mention the Tsinghua team, so we cannot say it is the same finding. We also found no statement from Knot Resolver, dnsmasq or CoreDNS about this disclosure.

Context. PowerDNS's advisory index includes 2015-01, "Label decompression bug can cause crashes or CPU spikes," and on 6 August 2026 advisory 2026-11 (CVE-2026-52682, CVSS 7.5) fixed a crafted packet that raised memory and CPU use across Authoritative Server, Recursor and dnsdist. Parsing DNS names safely remains hard.

If you run any other resolver or DNS proxy, watch its security page over the coming weeks.

What to do now

1. Find every Unbound and PowerDNS Recursor

Resolvers hide. Unbound ships in the OpenBSD and FreeBSD base systems, sits behind the DNS resolver in pfSense and OPNsense, and is common in container images as a local cache.

On a host:

# Unbound: version, build options (look for ngtcp2 / DoQ), and the running config
unbound -V
unbound-control status
unbound-checkconf -o num-threads
unbound-checkconf -o unwanted-reply-threshold

# PowerDNS Recursor
rec_control version
pdns_recursor --version

# Packages
dpkg -l unbound pdns-recursor 2>/dev/null
rpm -q unbound pdns-recursor 2>/dev/null
apk info -v 2>/dev/null | grep -E 'unbound|pdns-recursor'
pkg info unbound 2>/dev/null          # FreeBSD ports/packages

Across container images:

# List images that contain either resolver binary
for img in $(docker images --format '{{.Repository}}:{{.Tag}}'); do
  docker run --rm --entrypoint sh "$img" -c \
    'command -v unbound >/dev/null && unbound -V | head -1; command -v pdns_recursor >/dev/null && pdns_recursor --version 2>&1 | head -1' \
    2>/dev/null | sed "s|^|$img: |"
done

In Kubernetes, look for workloads that run a resolver as a sidecar or DaemonSet:

kubectl get pods -A -o jsonpath='{range .items[*]}{.metadata.namespace}{"\t"}{.metadata.name}{"\t"}{range .spec.containers[*]}{.image}{" "}{end}{"\n"}{end}' \
  | grep -Ei 'unbound|pdns|powerdns|recursor'

On appliances such as pfSense and OPNsense, the fix comes from the appliance vendor's release.

2. Triage by configuration

For Unbound, check the preconditions:

# DoQ: is any interface bound to the QUIC port, and is QUIC enabled?
unbound-checkconf -o quic-port
grep -RnE '^\s*interface:.*@' /etc/unbound/

# Threads (CVE-2026-97206 needs more than one)
unbound-checkconf -o num-threads

# Extra trust anchors (CVE-2026-50106, CVE-2026-35501)
grep -RnE '^\s*(trust-anchor|trust-anchor-file|trusted-keys-file):' /etc/unbound/

# Side channel precondition (CVE-2026-109125)
unbound-checkconf -o unwanted-reply-threshold

For PowerDNS Recursor with YAML settings:

grep -nE 'use_incoming_edns_subnet|edns_subnet_allow_list|listen:|forward_zones|auth_zones' /etc/powerdns/recursor.yml
rec_control get-parameter incoming.use_incoming_edns_subnet 2>/dev/null

Rank resolvers like this: anything open to the internet or to untrusted networks first, then anything serving DoQ with several threads, then validating resolvers with extra trust anchors or local zones, then the rest.

3. Upgrade

Unbound from source. Download, verify, build:

curl -O https://nlnetlabs.nl/downloads/unbound/unbound-1.26.2.tar.gz
curl -O https://nlnetlabs.nl/downloads/unbound/unbound-1.26.2.tar.gz.asc
echo "d8ee7aa6bbb3ff1be7d9e57637d0d0ec2f18273a8efff1a0afe2c665858b96f7  unbound-1.26.2.tar.gz" | sha256sum -c -
gpg --recv-keys 231018690C4D903EF419146AA144323DEAACDF45
gpg --verify unbound-1.26.2.tar.gz.asc unbound-1.26.2.tar.gz
tar xzf unbound-1.26.2.tar.gz && cd unbound-1.26.2
./configure   # reuse the flags shown by your current `unbound -V`
make && sudo make install
sudo systemctl restart unbound

Unbound 1.26.1 with patches. If you carry local changes, apply the combined patch instead:

curl -O https://nlnetlabs.nl/downloads/unbound/patch_combined_with_v3-1.26.2.diff
cd unbound-1.26.1
patch -p1 < ../patch_combined_with_v3-1.26.2.diff
make && sudo make install

Debian trixie:

sudo apt update && sudo apt install --only-upgrade unbound
dpkg -l unbound   # expect 1.26.2-0+deb13u1

PowerDNS Recursor from the PowerDNS repository (after adding the 5.4 or 5.3 repository for your distribution from repo.powerdns.com):

sudo apt update && sudo apt install --only-upgrade pdns-recursor
# or
sudo dnf upgrade pdns-recursor
rec_control version   # expect 5.4.8 or 5.3.12

Containers. Rebuild with --pull --no-cache so the new package lands, confirm with unbound -V inside the container, then roll out:

kubectl -n dns set image deployment/unbound unbound=registry.example.com/unbound:1.26.2
kubectl -n dns rollout status deployment/unbound

Recursor 5.2 and older. These are end of life upstream. Move to 5.4.8 or 5.3.12 after reading PowerDNS's upgrade guide, or rely on a distribution backport.

4. Interim measures while you schedule the upgrade

These remove the stated preconditions. They are not vendor-endorsed workarounds, apart from the TIME_WAIT setting, which PowerDNS does recommend.

• Unbound DoQ. If you do not need DNS-over-QUIC right now, remove the QUIC port from your interface: lines or set quic-port: 0, which the documentation says stops Unbound from initialising QUIC. Running with num-threads: 1 also removes the multi-threaded precondition, at a performance cost.
• Unbound side channel. Keep unwanted-reply-threshold: 0 (the default) until you upgrade.
• Recursor TIME_WAIT. PowerDNS says lowering tcp_max_tw_buckets below 64k reduces the impact on Linux, and notes that the default depends on system memory:

sysctl net.ipv4.tcp_max_tw_buckets
sudo sysctl -w net.ipv4.tcp_max_tw_buckets=60000

• Recursor web server. Do not expose the web server or API to untrusted networks. If you do not need TLS on it, the TLS handshake bug does not apply.
• Recursor ECS. If you enabled incoming.use_incoming_edns_subnet and do not rely on it, turning it off removes the precondition for CVE-2026-85559.
• Access control. Unbound's access-control: and Recursor's incoming.allow_from should list only your networks. This limits who can make your resolver ask, though it does not stop the decompression bugs.

There is no configuration change that stops the decompression bugs. Only the upgrade adds the per-packet budget.

5. Watch for signs of trouble

These are health signals, not proof of attack.

# Unbound: CPU, request list, and unwanted replies
unbound-control stats_noreset | grep -E 'total.num.queries=|total.requestlist|unwanted|num.answer.bogus'
top -b -n1 | grep unbound

# PowerDNS Recursor
rec_control get-all | grep -E 'questions|tcp-outqueries|over-capacity-drops|cpu-msec|bogus'

# Linux: TIME_WAIT sockets towards authoritative servers
ss -tan state time-wait | wc -l

Look for CPU near 100 percent without a matching rise in queries, repeated crashes of a multi-threaded Unbound serving DoQ, or a jump in TIME_WAIT sockets. Crash records help: journalctl -u unbound --since "2026-10-01" and coredumpctl list unbound.

6. Confirm and record

After each upgrade, confirm the running version and check resolution and validation:

unbound -V | head -1
rec_control version
dig @127.0.0.1 example.com A +dnssec +multi | grep -E 'flags|status'

A validating resolver should return the ad flag for a signed zone. Record each resolver and its version in your inventory.

What changed since first reports

• Distribution packages. Debian has since shipped DSA-6581-1 for unbound in trixie and updated forky and sid for both projects. Older Debian releases are still listed as vulnerable.
• CVE records. The Unbound records were live on release day; the PowerDNS records were still missing from CVE.org on 24 October.

Open questions

• Which other DNS vendors were part of the coordinated decompression disclosure? Neither vendor says. ISC's CVE-2026-19630 is similar in shape but not described as the same finding.
• When will appliance vendors ship Unbound 1.26.2? We did not find release notes from pfSense, OPNsense or router vendors at the time of writing.
• What limits did PowerDNS choose? NLnet Labs published its numbers (2048 and 128000); PowerDNS did not.
• Will the odd vendor dates be corrected? The 16 September entry for CVE-2026-96405 and the 23 October discovery date for CVE-2026-85559 may be revised.

What would have helped

There is no breach here. The question is what gets every resolver onto a fixed version in days.

Practices any team can use

• Keep a resolver inventory. List every recursive resolver, its software, version, owner and exposure. Most teams know their authoritative DNS far better than their resolvers.
• Record the build options, not just the version. Whether DoQ is compiled in decides whether CVE-2026-97206 applies. unbound -V output belongs in your inventory.
• Keep resolver configs in version control. Non-default settings decided exposure in this release, and versioned configs make step 2 a search.
• Subscribe at the source. NLnet Labs' advisories page, PowerDNS's advisory index and oss-security carried this release on day one; CVE.org still lacked the PowerDNS records three days later.
• Rebuild resolver images, do not patch in place. A container patched by hand reverts on the next restart.
• Plan for end of life. PowerDNS 5.2 and older will not get upstream fixes.
• Turn off what you do not use. DoQ, the Recursor web server and ECS forwarding are all useful when needed and pure attack surface when not.
• Watch resolver health. CPU per query and TIME_WAIT counts are cheap to graph. Our post on edge device zero-days this month makes the same case for internet-facing infrastructure in general.

Unbound has had a busy 2026. For background on earlier fixes, see our posts on CVE-2026-81642, the DNSKEY overflow, CVE-2026-82717, the CNAME heap bug, CVE-2026-85501, the DNSSEC algorithmic complexity issue, CVE-2026-80225, the TCP and DoT read limit and CVE-2026-42960, cache poisoning.

Zero-Day Discovery and Gold

Two Safeguard capabilities relate to the habit this post argues for, and we want to be exact about them.

Zero-Day Discovery looks for previously unknown flaws before a CVE exists, in two modes, an agentic mode and a deterministic scanner mode. Findings are issued as SGZ advisories before they reach public CVE databases, and it covers seven package ecosystems. Unbound and PowerDNS Recursor are C and C++ daemons that most teams install from operating system packages or source tarballs, so we do not claim Zero-Day Discovery covers them, and it did not find these bugs.

Gold Open Source at gold.safeguard.sh is free and needs no login. It offers searchable CVE intelligence with CVSS, EPSS, CISA KEV status, affected and fixed versions and a recommended safe version, with a free read API and a CI gate GitHub Action. Gold Registry at registry.safeguard.sh, a paid service, provides hardened drop-in components and container images held to zero exploitable critical or high CVEs, with SLSA L3 or higher provenance, Sigstore signatures and evidence pages; an artifact loses its badge if it regresses.

We have not confirmed that Gold holds records or hardened builds for these 12 CVEs, so we do not claim it. The habit these capabilities support is the right one here: look up the safe version quickly, pull patched and signed components from a curated source, and rebuild fast.

Where Safeguard fits

For a resolver release like this, the honest fit is inventory, matching and rebuilding what you build and ship yourself.

• Finding resolvers inside images you build. safeguard scan --image <name> scans a container image, safeguard scan --dir . scans a repository and safeguard scan --sbom <file> scans an SBOM, with results written as JSON under ./output. When the scanner identifies an Unbound or pdns-recursor package, the platform shows which projects contain that component and version. Our post on using SBOMs in incident response walks through that workflow.
• Matching against vulnerability databases. For the PowerDNS CVEs, matching depends on the records reaching those databases, still incomplete on 24 October.
• Policies and gates. Policies evaluated in the platform can stop a build that still carries a resolver version you have decided not to ship.
• Autonomous remediation. When a fixed version exists, fix pull requests can bump the package or image tag. It ships switched off by default.
• The Safeguard CLI assistant. It can edit a Dockerfile, Helm values file or compose file, then run your build and tests, asking before each command under the permission mode you choose (/permissions: Ask, Accept edits, Plan, Auto, Strict). safeguard exec runs the same work in CI.

Where Safeguard does not help: it does not upgrade Unbound inside a firewall appliance, a router or a managed DNS service; that fix comes from the vendor. It does not read resolver configs to tell you whether DoQ or extra trust anchors are enabled, it does not monitor resolver CPU or TIME_WAIT counts, and it does not see a resolver installed by hand on a host that is not in a repository, image or SBOM you scan.

When you are ready to try it, download Safeguard and read the CLI documentation.

Common mistakes and troubleshooting

• Upgrading the package but not restarting. Check the running version with unbound-control status or rec_control version.
• Trusting the distribution version string. A backported fix may keep an older upstream number. Check your distribution's tracker for the CVE, not just unbound -V.
• Losing build options on a source rebuild. Copy the configure flags from unbound -V before you rebuild.
• Assuming "not open to the internet" means safe from the decompression bugs. The bad packets come from an authoritative server your resolver asks.
• Ranking by score alone. CVE-2026-50106 scores 6.5 but needs an unusual trust anchor setup. Use the preconditions table.

FAQ

What did Unbound 1.26.2 fix?

Five CVEs: a DNS-over-QUIC use-after-free (CVE-2026-97206, High), an aggregate decompression denial of service (CVE-2026-96405, Medium), two DNSSEC bypasses for configured island trust anchors (CVE-2026-50106 Medium, CVE-2026-35501 Low) and a cache side channel that could aid poisoning when unwanted-reply-threshold is enabled (CVE-2026-109125, Medium).

Are any of these bugs being exploited?

Neither NLnet Labs nor PowerDNS reports exploitation, and we found no public proof of concept as of 25 October 2026. None of the 12 CVEs was in CISA's Known Exploited Vulnerabilities catalog as of its 23 October 2026 release.

Is the decompression bug the same in both products?

It is the same class of issue reported by the same research team, and both vendors call it a multi-vendor disclosure. Each project fixed its own code. Unbound now caps decompression at 2048 steps per upstream reply and 128000 per zone transfer packet; PowerDNS added per-name and per-packet limits without publishing the numbers.

Does this affect BIND?

ISC released BIND fixes the same day, including CVE-2026-19630, which bounds unlimited processing of inbound messages. ISC does not say it is part of the same multi-vendor disclosure, so treat the link as timing and similarity only. See our BIND post for BIND versions and fixes.

I do not use DNS-over-QUIC. Do I still need to upgrade Unbound?

Yes. The decompression fix applies to every recursive Unbound, and the side channel and trust anchor fixes apply to anyone who uses those settings. Not using DoQ only removes CVE-2026-97206 from your list.

Is PowerDNS Recursor 5.2 affected?

The advisory names only the 5.3 and 5.4 trains, and PowerDNS lists 5.2 and older as end of life, so there is no upstream fix for them. Debian's tracker lists its trixie 5.2.13 package as vulnerable. Plan a move to 5.4.8 or 5.3.12.

Which of these should I fix first?

Any resolver reachable from untrusted networks, then multi-threaded Unbound serving DNS-over-QUIC, then validating resolvers with extra trust anchors or local zones. The decompression fix matters everywhere, so every resolver still needs the upgrade.

How do I tell whether my Unbound serves DNS-over-QUIC?

Run unbound -V to see whether the build includes QUIC support, then check whether any interface: line uses the QUIC port and quic-port is not 0.

Fix it without waiting for upstream

For DNS resolvers, the useful gap to close is the one between "NLnet Labs and PowerDNS shipped fixes" and "every image we build carries them." That is mostly a rebuild problem, and it is where the following helps.

Whatever the vulnerability, most of the risk sits in two gaps. The first is the time between a fix being published and that fix actually running in your production builds. The second, and worse, is the time before any fix exists at all, while a maintainer works out a patch and a release schedule. Waiting through both gaps is a habit, not a requirement. Safeguard gives teams three ways to close them.

1. Autonomous remediation: pull requests, not tickets

When a fixed version exists, Safeguard's Griffin models open a tested, policy gated pull request that moves the affected dependency to the safe version. You can run it on one repository or in bulk across every project that carries the vulnerable version. Remediation covers eight categories, including dependencies, licenses, security posture and findings. Reachability analysis ranks the vulnerable code paths your application actually calls first, so the first pull requests you merge are the ones that matter most. Autonomous remediation ships switched off, with every category set to Manual, so your team decides how much runs on its own and what still needs a human approval.

2. Gold Open Source: the safe version in seconds, free

gold.safeguard.sh is free and needs no login. Search any CVE or package to see affected and fixed versions, CVSS, EPSS, CISA KEV status and a recommended safe version, or use the "Am I affected?" checker. The same data is available through a free read API, README status badges and RSS threat feeds. The safeguard-sh/gold-scan-action GitHub Action can fail a build on a known exploited vulnerability, on any known vulnerability, or never, so a version you have just removed cannot quietly come back in next week's merge.

3. Gold Registry: start from components that are already fixed

registry.safeguard.sh provides hardened, drop in replacements for upstream packages and container images. Every Gold artifact is held continuously to zero exploitable critical or high CVEs, zero malware and a completed license check, with SLSA L3 or higher provenance, a Sigstore signature and a public evidence page you can hand to an auditor. An artifact loses its Gold badge if it regresses. Teams can point their own package directory at the registry so hardened equivalents resolve without changing how developers install anything.

When upstream has no fix yet, or will not ship one, Safeguard first works to get the fix accepted upstream. If the issue is severe or upstream will not move, Safeguard builds a fork, fixes the vulnerability there and publishes a hardened Gold build, so you are not stuck on a maintainer's release schedule. You can also request a hardened, compatibility tested build of a specific package. This fork and patch flow is in early access today, so ask which packages it covers before you plan around it.

One honest limit: when the vulnerable code lives in a vendor appliance, a hosted service or an operating system runtime you do not build yourself, the fix still has to come from that vendor or distribution. The steps above apply to the open source dependencies and container images you build and ship, which is where most teams carry the largest and least tracked share of their exposure.

See how Safeguard would have helped

None of these demos shows Unbound or PowerDNS; each shows a real flow that maps onto this work.

The first demo is a real Safeguard CLI session asked to fix a lodash CVE: it reads the finding, asks before each command, edits package.json to lodash 4.17.21, runs npm install and npm test with approval, and pushes nothing. For this release you would ask the same assistant to bump the Unbound image tag in your Helm values or Dockerfile to 1.26.2, or the pdns-recursor package pin to 5.4.8, then run your build and a dig smoke test, approving each command.

Click through it at your own pace, or open it full screen.

The second demo sets up the Safeguard runner on your own machine, approves it with a device code and then scans from the terminal. That is the step that answers "which of our images still carry Unbound 1.26.1 or Recursor 5.4.7" across the images and repositories you already have.

Click through it at your own pace, or open it full screen.

The third demo is a real desktop app session: you ask for work on your computer, pick the folder, and Approve or Deny each command and file edit, ending with an upgrade done and tests passing. For a resolver rollout, point it at the repository that defines your DNS images and approve the bump, rebuild and tests one at a time.

Click through it at your own pace, or open it full screen.

Quick check

Sources

• Unbound: 1.26.2 addresses multiple CVE items (oss-security, 21 Oct 2026)
• Unbound 1.26.2 released (NLnet Labs community forum)
• Unbound security advisories (NLnet Labs)
• CVE-2026-97206 advisory text (NLnet Labs)
• CVE-2026-50106 advisory text (NLnet Labs)
• CVE-2026-96405 advisory text (NLnet Labs)
• CVE-2026-109125 advisory text (NLnet Labs)
• CVE-2026-35501 advisory text (NLnet Labs)
• CVE-2026-97206 record (CVE.org)
• CVE-2026-50106 record (CVE Services API)
• CVE-2026-96405 record (CVE Services API)
• CVE-2026-109125 record (CVE Services API)
• CVE-2026-35501 record (CVE Services API)
• CVE-2026-73206 lookup, no record as of 24 Oct (CVE Services API)
• PowerDNS Security Advisory 2026-12 for PowerDNS Recursor (oss-security, 21 Oct 2026)
• PowerDNS Security Advisory 2026-12 (PowerDNS)
• PowerDNS Security Advisory 2026-11 (PowerDNS)
• PowerDNS Recursor 5.4 changelog, 5.4.8
• PowerDNS Recursor 5.3 changelog, 5.3.12
• PowerDNS Recursor end of life statements
• PowerDNS Recursor YAML settings
• unbound.conf manual (NLnet Labs)
• ISC KB: CVE-2026-19630, Amplified resource exhaustion in inbound message processing
• Debian security tracker: CVE-2026-97206
• Debian security tracker: DSA-6581-1
• Debian security tracker: unbound
• Debian security tracker: pdns-recursor
• oss-security archive for 21 Oct 2026
• Known Exploited Vulnerabilities catalog JSON feed, version 2026.10.23 (CISA)

Last reviewed: 25 October 2026. This is a developing story; check the linked advisories for the latest status.