How to curb NSD exposure to four stack-overwrite CVEs before the 4.15.3 upgrade lands

Four stack overflows with one shared trigger

NLnet Labs shipped NSD 4.15.3 to close four stack overwrite vulnerabilities affecting versions 4.10.0 through 4.15.2. The flaws are tracked as CVE-2026-101338 (SVCB and HTTPS records), CVE-2026-101339 (HIP records), CVE-2026-101341 (text-bearing records) and CVE-2026-101337 (base64 presentation fields). SecurityOnline reports CVSS v4 scores of 8.7 and no public exploit at publication time.

A dev.to post aimed at operators who cannot deploy the fixed release immediately points to a detail common to all four NLnet Labs advisories: exploitation requires a crafted zone file delivered directly to NSD, and files the daemon writes itself will not take the required shape. That constraint frames the interim playbook — narrow the paths by which such a file can arrive, soften the blast radius if one does, and watch for the signals of an attempt.

Limit who can write zone files

The post's first recommendation is an audit of everything with write access to the zone directory: administrator accounts, provisioning tools, configuration management systems and, on some deployments, web applications. Not all of them genuinely need it. A provisioning pipeline legitimately writes files and triggers a reload; a web front end should instead hand records to an API that validates them and renders the zone itself.

Concrete steps include stripping broad group-write permissions, rotating credentials used by pipeline accounts, and requiring that changes to the zone directory come from a named deployment job rather than an interactive session. The reasoning is blunt: whatever account can write a zone file can also deliver one of the malformed record layouts these CVEs depend on.

Block the malformed record layouts upstream

Each flaw needs a particular record layout — an SVCB or HTTPS record just past its wire-format limit carrying an extra ECH parameter, a HIP record with an appended rendezvous server, text tokens under 32 bytes in series, or base64 fields split into very small chunks. Two validation mechanisms can intercept those shapes before a file reaches the daemon.

The first is to run nsd-checkzone taken from 4.15.3 in a disposable container against every incoming zone; the fixed parser carries the corrected boundary checks, so files resembling the CVE shapes are more likely to be rejected there than by the 4.15.2 code. The second is a pre-parse size check in whatever tool generates zones, rejecting SVCB or HTTPS records whose RDATA sits within a few bytes of the limit and capping base64 chunk sizes. The post is explicit that neither catches every variation and neither substitutes for the patch.

Reduce what the daemon can reach

Because the advisories describe command execution inside the NSD process, the third direction is limiting what that process can touch. Running the daemon as a dedicated unprivileged user, with a zone directory that is readable but not broadly writable, keeps an overflow from turning into immediate control of other data. On Linux, the post recommends the usual service-unit hardening: restricted filesystem access and no co-location with management software that holds credentials.

Watch crashes and reload callers

Two monitoring signals are worth correlating. A failed parser overflow kills the daemon, so supervisors will log the exit; unexpected exits timed against reload events should reach someone who can investigate quickly. Separately, a reload triggered by an account that never normally performs DNS changes deserves escalation, since a hostile zone delivery ends with a reload that loads the file.

How many servers are exposed

The post includes ZoomEye figures as context: 116,266 assets matching an NSD application fingerprint and 628,831 matching NSD banners at the time of writing, while a query for CVE-2026-101338 returned zero shortly after disclosure. The author cautions that these counts say nothing about version or about whether a given server accepts externally produced zone files — the numbers size the population, not the vulnerability.

Getting to the fixed release

NSD 4.15.3 is published by NLnet Labs. Where the full release cannot be adopted at once, the vendor provides per-CVE diffs against 4.15.2 that can be applied with patch -p1 in the source directory, followed by make install and a restart. The post advises confirming that the restarted process reports the fixed build before treating the interim controls as optional.

Why it matters

These CVEs matter less as remote threats than as amplifiers: an attacker who already controls a pipeline, provisioning tool or web app that writes zones gains command execution inside the DNS daemon. Real fleets take days or weeks to repackage and roll updates, so interim measures fill a genuine gap. The specific controls on offer — least-privilege write paths, pre-parse validation, and crash-and-reload correlation — are also durable hygiene that outlives this patch cycle. And with hundreds of thousands of NSD hosts visible to internet scanning, most operators cannot assume their instance is simply unknown.