NSD

Bypass of client certificate verification with transfer over TLS

When a "provide-xfr" is given with a "tls-auth-name", a secondary requesting a transfer should provide a client certificate with that name. However, no client certificate is needed when the request comes in over TLS over the regular "tls-port" (and not the "tls-auth-port") or over over TCP over the regular port, when the other conditions of the "provide-xfr" rule match.

The transfer security restrictions for client certificates can be bypassed completely if the attacker can match the other access control conditions, and the "tls-auth-xfr-only" option is not explicitly set to "yes" (which it by default is not)

NSD 4.14.3 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the NSD source directory with patch -p1 < patch_cve-2026-12490.diff and then run make install to install NSD.

Out of bounds stack write with crafted APL RR

NSD version 4.14.0 introduced a bug where a specially crafted APL RR, with an adflength larger than permitted for the address family will overwrite the stack when the zone is written to disk, with a maximum of 111 attacker controlled bytes.

Even though the data is from a configured primary inside NSD's trust boundary, we do consider the risk significant enough for multi-tenant secondary DNS deployments, where a primary could introduce the rogue APL with the secondary not noticing or only after the fact.

NSD 4.14.3 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the NSD source directory with patch -p1 < patch_cve-2026-12246.diff and then run make install to install NSD.

Denial of DNS over TLS service by any DoT client

NSD from version 4.13.0 has a heap use-after-free bug in logging errors on TLS connections, causing a crash of the server process, which can be triggered trivially by sending a DNS query over a DoT connection, and closing the connection without reading the response.

Any client with access to the DoT port (853) can trigger this. Even though a new server process will be immediately reforked to replace the crashed one, an attacker can keep all children in a crash-restart loop denying DoT service.

NSD 4.14.3 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the NSD source directory with patch -p1 < patch_cve-2026-12245.diff and then run make install to install NSD.

Heap overflow and crash with crafted SVCB RR

If NSD is configured as secondary for a zone, the primary of that zone can crash NSD with an AXFR containing a DNS message with a special crafted SVCB RR with an rdata size of 65512, that let's an (uint16_t) variable that is used to allocate space needed for the RR wrap (because total size > 65535), causing a heap overflow. The attacker can perform a controlled (RCE class) head write of up to 65509 bytes

Even though the data is from a configured primary inside NSD's trust boundary, we do consider the risk significant enough for multi-tenant secondary DNS deployments, given the potential severity of the attack.

NSD 4.14.3 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the NSD source directory with patch -p1 < patch_cve-2026-12244.diff and then run make install to install NSD.

Local symlink attack

NSD when writing and later chown'ing the PID file would not check if an existing file was a symlink. This is a local vulnerability that could create a Denial of Service of the system NSD is running on. It requires an attacker having access to the limited permission user NSD runs as and point through the symlink to a critical file on the system.

NSD 4.3.4 contains a patch. If you cannot upgrade you can also apply the patch manually. To do this, apply the patch on the NSD source directory with patch -p1 < patch_cve-2020-28935_nsd.diff and then run make install to install NSD.

NSD time sensitive TSIG compare vulnerability

NSD uses TSIG to protect zone transfers. The TSIG code uses a secret key to protect the data. The secret key is shared with both sides of the zone transfer connection. The comparison code in NSD was not time insensitive, causing the potential for an attacker to use timing information to discover data about the key contents.

Denial of service via a zone transfer with unlimited data

NSD before 4.1.11 allows remote DNS master servers to cause a denial of service (/tmp disk consumption and slave server crash) via a zone transfer with unlimited data. size-limit-xfr was implemented in NSD 4.1.11 to stop it from downloading infinite zone transfer data size.