Nlnetlabs: community verdicts

4 notable / known-exploited Nlnetlabs CVEs the community has triaged.

ⓘ Not an exhaustive list: we focus on the findings that matter (exploited / notable). For every Nlnetlabs CVE, see NVD ↗.

CVE-2026-12244HIGH 8.8Real · low riskEPSS 0%
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
CVE-2026-12245HIGH 7.5Real · low riskEPSS 0%
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.
CVE-2026-12246HIGH 8.1Real · low riskEPSS 0%
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.
CVE-2026-12490HIGH 7.5Real · low riskEPSS 0%
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.