cbcvebase.
CVE-2023-50387
published 2024-02-14

CVE-2023-50387: Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU…

PriorityP358high7.5CVSS 3.1
AVNACLPRNUINSUCNINAH
EPSS
100.00%
100.0th percentile
Certain DNSSEC aspects of the DNS protocol (in RFC 4033, 4034, 4035, 6840, and related RFCs) allow remote attackers to cause a denial of service (CPU consumption) via one or more DNSSEC responses, aka the "KeyTrap" issue. One of the concerns is that, when there is a zone with many DNSKEY and RRSIG records, the protocol specification implies that an algorithm must evaluate all combinations of DNSKEY and RRSIG records.

Affected

60 ranges· showing 25
VendorProductVersion rangeFixed in
cz.nicknot-resolver>= 0 < 5.6.0-1+deb12u15.6.0-1+deb12u1
cz.nicknot-resolver>= 0 < 5.7.1-15.7.1-1
cz.nicknot-resolver>= 0 < 5.7.1-15.7.1-1
debianbind9< bind9 1:9.18.24-1 (bookworm)bind9 1:9.18.24-1 (bookworm)
debiandnsjava< bind9 1:9.18.24-1 (bookworm)bind9 1:9.18.24-1 (bookworm)
debiandnsmasq< bind9 1:9.18.24-1 (bookworm)bind9 1:9.18.24-1 (bookworm)
debianknot-resolver< bind9 1:9.18.24-1 (bookworm)bind9 1:9.18.24-1 (bookworm)
debianpdns-recursor< bind9 1:9.18.24-1 (bookworm)bind9 1:9.18.24-1 (bookworm)
debiansystemd< bind9 1:9.18.24-1 (bookworm)bind9 1:9.18.24-1 (bookworm)
debianunbound< bind9 1:9.18.24-1 (bookworm)bind9 1:9.18.24-1 (bookworm)
fedoraprojectfedora
iscbind9.0.0 – 9.16.46
iscbind9.18.0 – 9.18.22
iscbind9.19.0 – 9.19.20
iscbind9>= 0 < 1:9.16.48-11:9.16.48-1
iscbind9>= 0 < 1:9.18.24-11:9.18.24-1
iscbind9>= 0 < 1:9.19.21-11:9.19.21-1
iscbind9>= 0 < 1:9.19.21-11:9.19.21-1
iscbind9>= 0 < 1:9.16.48-0ubuntu0.20.04.11:9.16.48-0ubuntu0.20.04.1
iscbind9>= 0 < 1:9.18.18-0ubuntu0.22.04.21:9.18.18-0ubuntu0.22.04.2
iscbind9>= 0 < 1:9.9.5.dfsg-3ubuntu0.19+esm121:9.9.5.dfsg-3ubuntu0.19+esm12
iscbind9>= 0 < 1:9.10.3.dfsg.P4-8ubuntu1.19+esm81:9.10.3.dfsg.P4-8ubuntu1.19+esm8
iscbind9>= 0 < 1:9.11.3+dfsg-1ubuntu1.19+esm31:9.11.3+dfsg-1ubuntu1.19+esm3
microsoftwindows_server_2008
microsoftwindows_server_2012

Detection & IOCsextracted from sources · hover to see the quote

commanddig @ example.dnssec-malicious-domain.com +dnssec
  • Monitor DNS resolvers for sustained or unexplained high CPU usage, which may indicate active KeyTrap exploitation via excessive DNSSEC cryptographic validation.
  • Detect DNS responses containing unusually large numbers of DNSKEY and RRSIG records — a single malicious response can trigger millions of cryptographic operations on the resolver.
  • Alert on DNS query timeouts or resolution failures across client networks, which may indicate a resolver is stalled due to KeyTrap exploitation.
  • Use resolver debug or query logs to identify repetitive DNSSEC validation loops, a behavioral indicator of KeyTrap exploitation.
  • Correlate in SIEM: anomalous resolver CPU spikes linked to DNSSEC validation routines, especially when tied to queries toward unknown or suspicious authoritative servers.
  • Monitor for outbound connections from resolvers to unexpected authoritative servers, which may indicate redirection to a malicious DNSSEC zone serving crafted responses.
  • A single DNS packet causing a ~2,000,000x spike in CPU instruction count is the key behavioral signature of KeyTrap; network-level monitoring for oversized DNSSEC payloads in a single response packet can serve as a detection trigger.
  • Identify DNS responses where key tag collisions are present — multiple DNSKEY records sharing identical (zone name, algorithm, key tag) triples in a single response are a strong indicator of a crafted KeyTrap payload.
  • Flag DNS responses containing multiple RRSIG records for the same RRset — this is a prerequisite for the multiple-signatures variant of the KeyTrap attack.
  • ·Akamai's mitigation limits cryptographic failures to a maximum of 32 per validation attempt, which effectively prevents CPU exhaustion; this threshold can serve as a reference for tuning similar limits in other resolver implementations.
  • ·The vulnerability is rooted in the DNSSEC protocol specification itself (RFC 4033/4034/4035/6840), not just implementation bugs — patching resolvers mitigates the risk but does not fully resolve the underlying protocol design flaw.
  • ·Approximately 35% of US-based and 30% of worldwide internet users rely on DNSSEC-validating resolvers, meaning a large fraction of resolvers remain exposed if unpatched.
  • ·The attack requires the adversary to operate or control a malicious authoritative DNS zone serving crafted DNSSEC responses; exploitation does not require a man-in-the-middle position.
  • ·The stall duration varies significantly by resolver implementation — from 56 seconds to up to 16 hours — so detection thresholds for CPU exhaustion alerts should be tuned per resolver type.

CVSS provenance

nvdv3.17.5HIGHCVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:N/I:N/A:H
osv7.5HIGH
vendor_debian7.5HIGH
vendor_msrc7.5HIGH
vendor_redhat7.5HIGH
vendor_ubuntu7.5HIGH
Stop checking back — get the weekly exploitation signal.

Every Monday: what got weaponized or added to CISA KEV in the last seven days — each CVE cross-linked to its PoC, Nuclei template, and detection rule. Free, one email a week, unsubscribe in one click.