CVE-2023-50868 is a high severity denial of service in DNSSEC validation, scored 7.5. The NSEC3 closest encloser proof can force heavy SHA-1 work in a resolver. PowerDNS Recursor fixed it in 4.8.6, 4.9.3 and 5.0.2. Check your own resolver vendor for its fix.
What's affected
This record is about a protocol behavior, so many products are affected, not one. The record lists NetApp hardware among its products and links Red Hat, SUSE and PowerDNS notices. Use your own resolver vendor's advisory to find your fixed version.
For PowerDNS Recursor, the advisory lists versions up to and including 4.8.5, 4.9.2 and 5.0.1 as affected. The fixed versions are 4.8.6, 4.9.3 and 5.0.2. The advisory covers this CVE together with CVE-2023-50387.
NVD scores it 7.5 (High) with the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H. PowerDNS also rates it High at 7.5, and states the impact is denial of service with no risk of system compromise. The record was published on 2024-02-14.
The PowerDNS page describes crafted DNSSEC related records in general. It does not map this CVE to NSEC3 by name, so the NSEC3 detail comes from the record, which attributes the issue to the Closest Encloser Proof in RFC 5155 when the RFC 9276 guidance is skipped.
How to check if you're exposed
Identify the DNS resolvers you run that validate DNSSEC and note the product and version. For PowerDNS Recursor:
rec_control version
Compare the output with 4.8.6, 4.9.3 and 5.0.2. For other resolvers, such as those in operating system packages, read the vendor tracker for this CVE.
Also check whether the resolver validates DNSSEC at all. A resolver with validation turned off does not do the work that causes the load. Look at CPU use on your resolvers during unusual query spikes, especially for random subdomains of a single zone.
What to do now
- List every validating resolver, including those inside appliances and network devices.
- Upgrade PowerDNS Recursor to 4.8.6, 4.9.3 or 5.0.2, or apply your vendor fix for other products.
- If you cannot upgrade, the advisory offers disabling validation with dnssec set to off or process-no-validate, and notes this affects clients that rely on validation.
- Monitor resolver CPU and set alerts for sustained spikes.
- Rate limit queries from untrusted clients.
Why it matters
The weakness is uncontrolled resource consumption, CWE-400. RFC 5155 describes how NSEC3 proves that a name does not exist, and the specification implies that a resolver may need thousands of hash computations in some situations. A response built for that case can make the resolver spend a lot of CPU.
The record describes this as a random subdomain attack, in which many queries for names that do not exist each trigger validation work. Because the work happens on the resolver, the cost lands on the victim, not the sender.
The record shows no CISA Known Exploited Vulnerabilities listing, and the fetched advisory does not report exploitation in the wild.
Quick check
Does the advisory say this is NSEC3?
The PowerDNS page speaks of crafted DNSSEC records generally. The NSEC3 attribution comes from the CVE record.
Can I turn off DNSSEC as a workaround?
PowerDNS lists that option, with the warning that clients depending on validation will be affected. Upgrading is the better fix.
Sources
Last reviewed: 19 October 2026.
