DEV Community

OnaEiuspkz
OnaEiuspkz

Posted on

If Customers Set TXT Records, the NSD Parser Bugs Are Your Problem

#vulnerability #dns #nsd

If Customers Set TXT Records, the NSD Parser Bugs Are Your Problem

Hosting providers and SaaS platforms share a structural property with the NSD vulnerabilities published on 14 October 2026: customers write record content into zone files that a nameserver then parses. Two of the four CVEs apply directly to the record types customers touch most.

The two customer-facing CVEs

CVE-2026-101341 covers records built from a series of text strings: TXT, NINFO, SPF, AVC, RESINFO and WALLET. Text tokens under 32 bytes are not checked against the space reserved for the RDATA, and the vendor states the write can reach a callback function pointer invoked directly after parsing.

CVE-2026-101337 covers base64-encoded RDATA where the data is split into pieces of three characters or fewer. The token size is computed as zero bytes, and up to 64 KB of attacker-controlled data can be written.

Both involve record content a customer might supply through a control panel. TXT records hold SPF policies, domain verification strings, and DKIM material. Base64 RDATA appears in DKIM public keys and in several DNS-based authentication records.

Why the multi-tenant case differs

A single-organisation nameserver usually has one set of authors: the DNS team. A multi-tenant platform has thousands, and their access is mediated by a UI that was designed to constrain record content, not to survive a parser bug.

That mediation is usually validation, not isolation. A control panel that rejects spaces or over-long strings is protecting the zone file syntax. It is not protecting the parser, because the parser bug lives in a code path that reads whatever syntax the UI permitted.

The advisories also constrain the attack path in a way that matters here. The zone file must be supplied to NSD directly, and files NSD writes itself do not carry the required formatting. A platform that renders zone files from customer input and hands them to NSD is precisely the deployment the vendor describes as the origin of that input.

Three checks for a platform operator

First, determine whether customer-supplied content reaches a file NSD reads as presentation format. Some platforms write records into a database and render zones on a schedule; others write zone files directly. The second group is the one this advisory describes.

Second, determine which record families the platform allows. If TXT is available — and it almost always is — then CVE-2026-101341 and CVE-2026-101337 are in the reachable set as soon as the platform writes zone text.

Third, determine whether validation normalises or merely checks. A validator that accepts a customer record and passes it through unchanged does not control a parser that mis-handles unusual formatting; one that rejects non-canonical formatting does.

Communicating with customers

There is no evidence in the advisories of exploitation, and no public proof-of-concept. A customer notice that implies otherwise would be inaccurate.

The accurate statement is narrower and more useful: the nameserver software had parser defects reachable through zone files produced from customer input; the platform has upgraded to NSD 4.15.3; the parser fix is in place; validation of record content continues.

Exposure context

ZoomEye reports 116272 assets matching app="NSD". The CVE query vul.cve="CVE-2026-101337" returns nothing indexed at the time of writing. Link: https://www.zoomeye.ai/searchResult?q=YXBwPSJOU0Qi

Those assets are banner matches rather than tenants: a shared-hosting platform may appear as one or a few of them while representing many thousands of customers.

Remediation

Upgrade to NSD 4.15.3, which ships the corrected parser in simdzone 0.2.7. Where the upgrade is blocked, apply the advisory diff patches to a 4.15.2 source tree with patch -p1 and rebuild.

Then re-examine what the control panel actually guarantees. Constraining syntax and guaranteeing parser safety are different promises.

References

Top comments (0)