CVE-2023-50387, known as KeyTrap, is a High severity (CVSS 7.5) denial of service flaw in how DNS resolvers validate DNSSEC. A zone with many DNSKEY and RRSIG records can drive CPU use very high. Patch your resolver, for example PowerDNS Recursor 4.8.6, 4.9.3 or 5.0.2.
What's affected
This is a protocol level issue, so many resolvers are affected, and the fix depends on which one you run. Per PowerDNS, any resolver following the RFCs can be affected, and it is not a problem of one implementation. NVD published the record on 14 February 2024.
Confirmed fixed versions from the PowerDNS advisory 2024-01: PowerDNS Recursor up to and including 4.8.5, 4.9.2 and 5.0.1 are affected, and 4.8.6, 4.9.3 and 5.0.2 are not. PowerDNS also lists CVE-2023-50868, a companion DNSSEC issue, in the same advisory. The record's references also link a Knot Resolver release, v5.7.1, and an oss-security thread about Unbound. I could not read the Knot Resolver release page, so check its notes yourself. For BIND, Unbound and others, I did not confirm fixed versions, so use each project's advisory. The record also lists Red Hat Enterprise Linux and Windows Server 2008 among its products.
Severity: NVD scores it 7.5 High with vector AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H, and PowerDNS gives the same 7.5 and calls it High, so the sources agree. PowerDNS states that the risk of system compromise is none.
How to check if you're exposed
Find every DNS resolver that performs DNSSEC validation, including ones inside appliances, firewalls and container hosts. Then read its version.
pdns_recursor --version
unbound -V
named -v
kresd --version
Run the one that matches your software. Compare the result with the fixed versions in your resolver's advisory. On Linux distributions, also check the package version and the distribution's security tracker, since vendors backport fixes without changing the upstream version number.
A resolver that does not validate DNSSEC is not affected in the way described, since the cost comes from validation. Check the validation setting in your configuration to see which case you are in.
What to do now
- Upgrade your validating resolver to the patched release. For PowerDNS Recursor, that is 4.8.6, 4.9.3 or 5.0.2 or later.
- Check your other resolvers, including Unbound, BIND and Knot Resolver, against their own project advisories, and apply the vendor patch.
- If you cannot patch at once, PowerDNS documents a workaround: turn DNSSEC validation off with dnssec=off or process-no-validate. This affects clients that rely on validation, so weigh it carefully.
- Watch CPU use on resolvers, and alert on sustained spikes that match no traffic growth.
- Record resolver versions in your inventory, including embedded ones in network gear.
Why it matters
The weakness is CWE-770, allocation of resources without limits or throttling. The DNSSEC specifications imply that a validator must check all combinations of DNSKEY and RRSIG records for a zone. If an attacker publishes a zone with a very large number of both, an honest implementation can spend an enormous amount of CPU time on one query, and the work is done before anyone gets an answer.
That is why PowerDNS describes the trigger as an attacker publishing a crafted zone. The attacker needs no access to your network. Your resolver reaches out to the zone as part of normal operation, and the cost lands on you. Other queries slow or fail while the resolver is busy.
The researchers from the ATHENE center disclosed it under the name KeyTrap, and PowerDNS thanks them in its advisory. KEV is false for this CVE, and I found no claim of exploitation in the sources I read. DNS is infrastructure, so resolver patching belongs on a platform schedule. See how Safeguard tracks such findings in the demo below, and use the free scan at gold.safeguard.sh/scan for the open source packages in your own repositories.
Try it yourself
Infrastructure flaws like this one land on many teams at once. The demo below shows how a findings queue is triaged.
Click through it at your own pace, or open it full screen.
Quick check
Do I have to turn off DNSSEC validation?
No. PowerDNS lists that as one possible remedy if you cannot patch, and notes it affects clients that rely on validation. Patching is the better route.
Is the attacker inside my network?
No. The vector is network based with no privileges. The trigger is a crafted zone that your resolver is asked to validate.
Sources
Last reviewed: 19 October 2026.
