DEV Community

StarkMan
StarkMan

Posted on

Managed DNS providers inherit a new supply-chain risk from the NSD stack overwrite flaws

#vulnerability #dns #nsd

Managed DNS providers inherit a new supply-chain risk from the NSD stack overwrite flaws

For a managed DNS provider or a registry running NLnet Labs NSD, the four vulnerabilities patched in version 4.15.3 describe an uncomfortable scenario. The attack arrives as customer data, in a format the platform is contractually obliged to accept, and it is parsed by a daemon whose job is to trust that data enough to serve it.

The facts a provider needs

NLnet Labs published advisories on 14 October 2026 for CVE-2026-101341, CVE-2026-101339, CVE-2026-101338 and CVE-2026-101337. Each affects NSD 4.10.0 through 4.15.2, each is rated High, and each results in an out-of-bounds stack overwrite that can be exploited to execute arbitrary commands. Version 4.15.3 contains the fixes.

The four are distinguished by record type: TXT and related text records, HIP records, SVCB and HTTPS records, and base64 RDATA presentation formatting. In each case the parser's byte accounting breaks and a write lands on the stack; the TXT-family advisory names a callback function pointer invoked immediately after parsing as the reachable target.

Why the multi-tenant case is different

Everyone running the affected versions needs the patch. What separates a provider from a single-tenant operator is the number of parties who can already influence zone content. A customer portal, an API for zone uploads, a bulk import path, a delegated-zone workflow or a migration service all deliver files that the daemon parses. Those channels exist because customers need them, and they are precisely the delivery route the advisories describe.

The vendor's own qualifier matters here. Zone files NSD writes out itself, including those for secondary zones, are not formatted in the vulnerable way. That means a provider whose architecture only ever re-serves files the daemon generated has less exposure than one that ingests externally authored files. Many providers do both.

Threat scenarios worth stating plainly

An attacker with a legitimate account could submit a syntactically plausible zone file containing one crafted record. If the platform parses it in the production process that also answers queries, the consequences are not limited to the customer's own zone: a stack overwrite in an authoritative server can affect availability and integrity for every zone that instance serves.

A second scenario is quieter. A crafted record sits in a migration script, a test fixture or a template repository, is reviewed as routine data, and reaches a production parser months later during a batch import. Nothing about it looks like an attack at the time.

Neither scenario has been observed in the wild. The vendor reports no confirmed exploitation, and no public proof-of-concept is described.

Concrete programme changes

Patch first: upgrade to 4.15.3 or apply the per-CVE diff patches and rebuild. Then treat zone ingestion as a trust boundary with real controls. Parse untrusted submissions out of band, in a process that does not serve queries. Validate records against an independent implementation before promotion. Keep an auditable record of which submission produced each file that a production daemon reads. For organisations on a release cadence slower than upstream, subscribe to the NSD advisory feed rather than discovering the next batch after publication.

Exposure framing for a provider's own reporting

A ZoomEye lookup on 25 October 2026 for the NSD application fingerprint counted 116,266 assets, and 116,203 when restricted to the fingerprint plus port 53. Those figures measure NSD-like services on the internet. They say nothing about version distribution, nothing about whether a host ingests third-party zone files, and nothing about exploitation. Internal inventory, not an external scan, is the number a provider should use to state its own exposure.

References

Top comments (0)