Several vulnerabilities were found in NSD. The overview of the vulnerabilities with a brief description is:
CVE-2026-101337 - severity: HIGH RCE class stack overwrite from specially formatted base64 RDATA field
CVE-2026-101338 - severity: HIGH RCE class stack overwrite from a crafted and formatted SVCB or HTTPS RR
CVE-2026-101339 - severity: HIGH RCE class stack overwrite from a crafted and formatted HIP RR
CVE-2026-101341 - severity: HIGH RCE class stack overwrite from specially formatted TXT-DATA RDATA field
The patches are tested to apply/work on 4.15.2.
Best regards, -- Willem, on behalf of the NSD team.
Tokens of text in RDATA (of for example TXT records) under 32 bytes are not checked to stay within the space reserved for the RDATA allowing for arbitrary sized out of bound stack writes, including an overwrite of a callback function pointer which is called directly after parse. Zone files which are written out by NSD itself, such for zones for which the NSD instance is secondary, will not be formatted like this. The zone file must be fed to NSD directly, (but it could come, for example, from an operator controlled provisioning system).
A HIP resource record that fills the RDATA near or at is limit, and has another dname RDATA field (a HIP Rendezvous server) can overwrite the stack with up to 191 bytes of attacker controlled data. Zone files which are written out by NSD itself, such as for zones for which the NSD instance is secondary, will not be formatted like this. The zone file must be fed to NSD directly, (but it could come, for example, from an operator controlled provisioning system).
When a SVCB or HTTPS RR has filled the wire format RDATA up to the brim, another ECH parameter may overwrite the stack, and once beyond the limit, the base64 decoder can write attacker controlled data of unlimited size. Zone files which are written out by NSD itself, such as for zones for which the NSD instance is secondary, will not be formatted like this. The zone file must be fed to NSD directly, (but it could come, for example, from an operator controlled provisioning system).
When base64 data is split up in pieces, of 3 character or less, tokens were incorrectly calculated to produce 0 bytes. This enables attackers to overwrite the stack with up to 64K of attacker controlled data. Zone files which are written out by NSD itself, such as for zones for which the NSD instance is secondary, will not be formatted like this. The zone file must be fed to NSD directly, (but it could come, for example, from an operator controlled provisioning system).
Several vulnerabilities were found in NLnet Labs NSD. The overview of the vulnerabilities with a brief description is:
CVE-2026-12244 - severity: HIGH Heap overflow and crash with crafted SVCB RR
CVE-2026-12245 - severity: HIGH Denial of DNS over TLS service by any DoT client
CVE-2026-12246 - severity: HIGH Out of bounds stack write with crafted APL RR
CVE-2026-12490 - severity: HIGH Bypass of client certificate verification with transfer over TLS
The patches are tested to apply/work on 4.14.2
Best regards, -- Willem, on behalf of the NSD team.
Last updated 29 June 2026