CVE-2026-12490: NSD TLS Authentication Bypass in Zone Transfer (CVSS 7.5)

Technical summary

NSD's provide-xfr rule with tls-auth-name parameter is intended to enforce mutual TLS authentication for zone transfers: secondaries must present a client certificate matching the specified name. However, the implementation fails to validate this certificate requirement consistently. When a zone transfer request is received over TLS on the regular tls-port (rather than the dedicated tls-auth-port) or over unencrypted TCP on the standard port, the certificate check is bypassed. If other conditions in the provide-xfr rule match (such as IP address restrictions), the transfer is granted without authentication. This breaks the intended access control model.

Business impact

Organizations relying on NSD's certificate-based zone transfer authentication to protect DNS zone data and prevent unauthorized secondary nameserver provisioning are exposed to compromise. An attacker with network access to the server can enumerate all DNS records without needing the certificate, potentially exposing internal naming conventions, infrastructure topology, and sensitive hostnames. This can enable reconnaissance for follow-on attacks and may violate compliance requirements around DNS security and data protection.

Affected systems

NLnet Labs NSD is affected. The exact affected versions are determined by the vendor advisory—verify against the official NLnet Labs security announcement for specific version numbers and patch availability. Any NSD deployment using the provide-xfr directive with tls-auth-name configuration is potentially vulnerable if running an unpatched version.

Exploitability

Exploitability is straightforward: an attacker with network access to the DNS server can connect over standard TLS or TCP and request zone transfers. No special tools, authentication credentials, or user interaction are required. The attack is likely automated and can be performed at scale. The CVSS:3.1/AV:N/AC:L/PR:N/UI:N vector reflects this low barrier to entry. However, the vulnerability requires the administrator to have explicitly configured a provide-xfr rule with tls-auth-name; servers without this configuration are not affected.

Remediation

Apply the security patch released by NLnet Labs for NSD. Verify the specific patched version numbers in the vendor advisory. The fix ensures that client certificate validation is enforced consistently across all connection paths—TLS and TCP—when tls-auth-name is specified in a provide-xfr rule. Until patching is complete, consider restricting network access to the DNS server via firewall rules, limiting zone transfer requests to trusted IP ranges only.

Patch guidance

Consult the official NLnet Labs security advisory for CVE-2026-12490 to identify the patched version(s) applicable to your NSD deployment. Upgrade to the recommended version as soon as testing permits. Prioritize this for any NSD server currently using provide-xfr with tls-auth-name in production. Post-patch, verify that zone transfer requests from secondary nameservers are again properly enforcing client certificate checks by monitoring access logs and testing transfers with and without valid certificates.

Detection guidance

Monitor DNS server logs for unusual zone transfer requests, particularly from unexpected IP addresses or without valid TLS client certificate presentations. If your NSD logging captures AXFR/IXFR requests and authentication details, look for successful zone transfers that do not have corresponding certificate authentication events. Network-based detection can identify zone transfer patterns (port 53 TCP, AXFR queries) from clients that are not registered secondaries. Implement alerting on zone transfer attempts from any source outside your authorized secondary nameserver population.

Why prioritize this

This vulnerability merits high priority because it directly bypasses a security control that many DNS operators implement specifically to protect zone data confidentiality. The attack surface is broad (any network-accessible NSD server), the exploit is trivial, and the impact—unauthorized zone data disclosure—can enable broader reconnaissance and attacks. Organizations with sensitive internal DNS infrastructure should patch immediately.

Risk score, explained

The CVSS 3.1 score of 7.5 (HIGH) reflects high network accessibility (AV:N), low attack complexity (AC:L), no privilege or user interaction requirements (PR:N/UI:N), a bounded scope (S:U), and high confidentiality impact (C:H) with no integrity or availability impact (I:N/A:N). The score appropriately captures the nature of an authentication bypass that exposes sensitive data without requiring exploitation sophistication. The HIGH severity rating warrants timely patching.

Frequently asked questions