DEV Community

kozhevniko
kozhevniko

Posted on

Reducing NSD exposure before the upgrade: interim mitigations for the 4.15.3 CVEs

#dns #nsd #vulnerability #cve2026101338

Reducing NSD exposure before the upgrade: interim mitigations for the 4.15.3 CVEs

Not every DNS fleet can jump to NSD 4.15.3 the same week. Change control, package rebuilds, and downstream image dependencies add days. The four stack overwrite CVEs in NSD 4.10.0 through 4.15.2 do not need a perfect response before then, but they do reward a deliberate sequence while the upgrade is in flight.

Restate the requirement for exploitation

NLnet Labs defines the trigger the same way in all four advisories: a crafted zone file must be fed to NSD directly. Files that NSD writes itself will not be formatted in the required way. That gives interim work two directions: reduce who can deliver such a file, and reduce the consequence if they do.
The four CVEs are CVE-2026-101338 for SVCB and HTTPS records, CVE-2026-101339 for HIP records, CVE-2026-101341 for text-bearing records, and CVE-2026-101337 for base64 presentation fields. SecurityOnline reports CVSS v4 scores of 8.7 and no public exploit at publication.

Direction one: shrink the set of writers

Enumerate the accounts, services, and pipelines that can write into the zone directory. On a typical deployment that includes the DNS administrators, a provisioning tool, a configuration management system, and possibly a web application.
For each, ask whether it needs direct write access. A provisioning tool usually needs to write files and then call nsd-control reload. A web application should never need filesystem access; it should call an API that validates records and renders the zone. Any account that can write zone files can deliver one of the CVE shapes.
Remove broad group write permissions, rotate credentials for pipeline accounts, and require that any change to the zone directory comes from a named deployment job rather than an interactive session.

Direction two: constrain the shapes files can take

The four CVEs need particular record layouts: an SVCB or HTTPS record past its wire-format limit with an additional ECH parameter, a HIP record with an appended rendezvous server, text tokens under 32 bytes in series, or base64 fields split into tiny chunks.
A validation step that enforces size budgets before files reach the daemon blocks those layouts. Two mechanisms are cheap:

  • Run nsd-checkzone from 4.15.3 in a disposable container against every incoming zone. The fixed parser includes the corrected boundary checks, so files resembling the CVE shapes are more likely to be rejected there than by 4.15.2.
  • Add a pre-parse size check in the generating tool. Reject an SVCB or HTTPS record whose RDATA is within a few bytes of its limit, and cap base64 chunks below the short-token thresholds. Neither prevents every variation, and neither substitutes for the patch. They reduce the chance that a hostile file reaches the vulnerable parser unexamined.

Direction three: reduce process privilege

The advisories describe command execution inside the NSD process. Anything that limits what that process can reach reduces the value of a successful exploit. Running NSD as a dedicated unprivileged user, with a zone directory readable but not broadly writable, keeps an overflow from turning into immediate control of other data.
On Linux, the usual hardening applies: keep the daemon in a service unit with restricted filesystem access, and avoid co-locating it with management software that holds credentials.

Interim monitoring

Watch for crashes. A parser overflow that fails kills the daemon, and supervisors log the exit. Correlate unexpected exits with reload events, and route that correlation to whoever can investigate quickly.
Also watch the reload caller. A reload triggered by an account that normally does not perform DNS changes is a signal worth escalating, since hostile zone delivery ends with a reload that loads the file.

Exposure context

Measurement sizes the population rather than the vulnerability. ZoomEye returned 116,266 assets for app="NSD" and 628,831 for banner="NSD" at the time of writing, while vul.cve="CVE-2026-101338" returned zero shortly after disclosure. Those counts do not indicate version or whether a server accepts externally produced zone files.
Search link: https://www.zoomeye.ai/searchResult?q=YXBwPSJOU0Qi

The upgrade itself

NSD 4.15.3 is published at https://nlnetlabs.nl/downloads/nsd/nsd-4.15.3.tar.gz. Where the release cannot be adopted immediately, the vendor provides per-CVE diffs against 4.15.2, for example https://nlnetlabs.nl/downloads/nsd/patch_CVE-2026-101338.diff, applied with patch -p1 in the source directory followed by make install and a restart. Confirm the restarted process reports the fixed build before considering the interim controls optional.

References

Top comments (0)