The four NSD flaws fixed in 4.15.3 are worth reading together because they are variations on one mistake. In each case the zone-file parser derived a write length that did not match the space it had actually reserved. The fixes tighten those checks. The differences between the four cases show how many places a length can go wrong.

CVE-2026-101338: SVCB, HTTPS, and the extra parameter

SVCB and HTTPS records carry a set of key-value parameters in wire format. The advisory describes a record whose RDATA is filled to the brim, followed by another ECH parameter. Once the limit is passed, the base64 decoder writes attacker-controlled data of unlimited size.
Two failures combine here. The boundary between "the RDATA is full" and "there is room for another parameter" was computed incorrectly, and the decoder that consumes the resulting value had no bound tied to the remaining space. A single confused length check therefore produced an unbounded write rather than a truncated one.

CVE-2026-101339: HIP records and a fixed 191-byte overwrite

HIP records contain a rendezvous server field, itself a domain name. When an RDATA is filled near or at its limit and a rendezvous server is appended, the parser overwrites the stack with up to 191 bytes of attacker-controlled data.
The number is instructive. A fixed, bounded overflow of 191 bytes is still enough to redirect a callback or corrupt saved state, but it demands more precision from an attacker than an unbounded write. It also suggests the check that failed here was local to the rendezvous field rather than the whole record.

CVE-2026-101341: short text tokens slip through

Records that carry series of strings, including TXT, NINFO, SPF, AVC, RESINFO and WALLET, had a subtle gap. Text tokens under 32 bytes were not checked to stay within the space reserved for RDATA, which allows an arbitrarily sized out-of-bounds stack write.
The advisory notes the write can overwrite a callback function pointer that is called directly after parsing. That is the difference between corrupting a buffer and influencing control flow. TXT records are also the most commonly editable type in managed DNS platforms, which raises the practical importance of this one.

CVE-2026-101337: base64 token arithmetic

When base64 data is split into pieces of three characters or less, tokens were incorrectly calculated to produce zero bytes. The parser therefore believed it needed no space, while the decoder produced up to 64 KB of attacker-controlled data.
This is a size calculation error rather than a missing bound. The write itself was permitted to proceed based on a computed length of zero, and the ceiling of 64 KB comes from the practical size of the input rather than an explicit limit in the code.

The precondition that keeps the risk uneven

All four advisories repeat the same constraint. Zone files written out by NSD itself will not be formatted in the required way. The zone file must be fed to NSD directly, typically from an operator-controlled provisioning system.
That single sentence splits the affected population into two groups. Servers whose zone data always arrives through transfers from a peer NSD instance are unlikely to see the required shapes in normal operation, though an attacker with write access to the zone directory still reaches the vulnerable parser. Servers whose zone data is assembled by other software are exposed to whatever that software allows its users to express.

Impact

The advisories describe the outcome as execution of arbitrary commands. NSD normally runs as a long-lived daemon, and a corrupted parse can crash it before an attacker achieves anything useful. Getting from a crash to execution requires the write to be shaped for the target build, with the usual dependencies on compiler options, memory layout, and platform hardening.
For a primary authoritative server, successful execution exposes the zone data it serves and the answers it returns. For a hidden primary that feeds public secondaries, the exposure runs through replication rather than direct queries.

Affected scope

NSD 4.10.0 through 4.15.2 inclusive. Earlier releases and 4.15.3 are unaffected. SecurityOnline reports CVSS v4 scores of 8.7 for each CVE and records no public proof-of-concept or in-the-wild exploitation at publication time.

Exposure context

Public measurement sizes the service population, not the vulnerable subset. A ZoomEye query for app="NSD" returned 116,266 assets at the time of writing, and banner="NSD" returned 628,831. A CVE-scoped query for vul.cve="CVE-2026-101338" returned zero, which is normal within days of disclosure. Neither count indicates version, configuration, or whether the server parses externally supplied zone files.
Search link: https://www.zoomeye.ai/searchResult?q=YXBwPSJOU0Qi

Remediation

Move to NSD 4.15.3 or later, from https://nlnetlabs.nl/downloads/nsd/nsd-4.15.3.tar.gz. Per-CVE diffs against 4.15.2 exist for backporting, for example https://nlnetlabs.nl/downloads/nsd/patch_CVE-2026-101337.diff, applied with patch -p1 and followed by make install. Verify the running binary after restart, and run nsd-checkzone from the fixed release against production zones before the change window.

References

  • NLnet Labs advisory for CVE-2026-101338: https://nlnetlabs.nl/downloads/nsd/CVE-2026-101338.txt

  • NLnet Labs advisory for CVE-2026-101341: https://nlnetlabs.nl/downloads/nsd/CVE-2026-101341.txt

  • NLnet Labs advisory for CVE-2026-101339: https://nlnetlabs.nl/downloads/nsd/CVE-2026-101339.txt

  • NLnet Labs advisory for CVE-2026-101337: https://nlnetlabs.nl/downloads/nsd/CVE-2026-101337.txt

  • SecurityOnline report: https://securityonline.info/nsd-stack-overwrite-vulnerability-patched/