DEV Community

yutianle
yutianle

Posted on

Parsing Is the Attack Surface: Lessons From NSD and CVE-2026-101339

#vulnerability #dns #nsd

Parsing Is the Attack Surface: Lessons From NSD and CVE-2026-101339

Every input format an internet-facing daemon accepts is a piece of attack surface, and the more obscure the format, the longer defects survive. The NSD update released on 14 October 2026 makes that argument concretely: four stack overwrites, all in the same zone file parser, found and fixed together.

The four defects

CVE-2026-101339 leads the set. A HIP resource record with RDATA filled near or at its limit, followed by a Rendezvous server dname, causes an out-of-bounds stack write of up to 191 bytes of attacker-controlled data. NLnet Labs describes the possible result as arbitrary command execution.

CVE-2026-101341 covers records built from string sequences, naming TXT, NINFO, SPF, AVC, RESINFO and WALLET. Text tokens under 32 bytes are not checked against the space reserved for RDATA, so the write can be arbitrarily sized and can overwrite a callback function pointer invoked immediately after parsing.

CVE-2026-101338 concerns SVCB and HTTPS records. When the wire-format RDATA is filled to capacity, an additional ECH parameter carries the parser past the boundary, and the base64 decoder writes attacker data with no size limit.

CVE-2026-101337 involves base64 presentation formatting. Splitting base64 into pieces of three characters or fewer causes the token size to be computed as zero, opening a window of up to 64 KB.

All four affect NSD 4.10.0 through 4.15.2 and are fixed in 4.15.3. CVSS v4.0 scores are 8.7 for each. No public proof of concept and no exploitation in the wild were reported.

The common root cause

Look past the record types and one pattern appears: the parser trusted a length it calculated itself. Text tokens, ECH parameters, base64 chunk sizes, and HIP rendezvous names all pass through code that derives a size and then writes without re-verifying the destination.

The four fixes address a class of error. Where one instance of it exists in a parser, others usually do, and the four fixes here look like the result of a systematic review of the same code area rather than four independent discoveries.

Three researchers are credited across the advisories, including Qifan Zhang of Palo Alto Networks, Alwaleed Ashi of LXR, and Gaurang Maheta, which fits that theory: multiple reviewers sweeping the same parser.

Why the file path matters more than the wire

The advisories state that zone files written by NSD itself, including for secondary zones, will not be formatted in the triggering way. The file must be handed to NSD directly.

For a defender this is the single most useful sentence in the release. It eliminates the entire population of pure secondary servers from the direct risk set, and it focuses attention on provisioning. Any pipeline that converts outside input into a zone file belongs on the review list. So does any environment where a customer, partner, or automated feed can influence zone contents.

Where the exposed population sits

ZoomEye returned 116,266 assets for the NSD product fingerprint app="NSD" at 2026-10-25T20:15:54Z.

Those are internet-visible services carrying the fingerprint. The number does not encode version, role, or ingestion policy, which are the three attributes that determine real risk. An identifier-scoped query for CVE-2026-101341 returned zero, illustrating how limited CVE-level index coverage is for a fresh advisory.

Combine the fingerprint measurement with your own configuration records. The intersection is your actual work list.

Fix and follow-up

Move to NSD 4.15.3 or newer. For source-based installs that cannot, each advisory provides a diff against 4.15.2, applied with patch -p1 < patch_CVE-2026-101339.diff in the source directory and then make install. Applying one diff out of four is not a fix.

After the upgrade, restart the daemon and verify the running version, because the parser executes in memory.

Then treat parsing as a standing review topic. Enumerate every format your internet-facing services accept from outside parties, and ask for each whether length handling has been tested against deliberately malformed input. The NSD release shows the answer is often no until someone looks.

References

Top comments (0)