Description
When a provide-xfr is given with a tls-auth-name, a secondary requesting a transfer should provide a client certificate with that name. However, no client certificate is needed when the request comes in over TLS over the regular tls-port (and not the tls-auth-port) or over over TCP over the regular port, when the other conditions of the provide-xfr rule match.
Published: 2026-06-25
Score: 8.2 High
EPSS: < 1% Very Low
KEV: No
Impact: n/a
Action: n/a
AI Analysis

Impact

Vulnerability allows an attacker to perform zone transfers without client certificate authentication when using the provider transfer mechanism over the server’s standard TLS address or an unencrypted TCP connection, as long as the request satisfies the provide‑xfr rule with a tls-auth-name. The flaw arises from missing authentication checks and improper access control (CWE-284, CWE-306, and CWE-303), enabling the disclosure of private DNS zone data.

Affected Systems

Affects NLnet Labs NSD 4.14.x and earlier. Versions prior to 4.14.3 are vulnerable; upgrade is required. Without patch or configuration changes, an NSD deployment that includes a provide‑xfr rule with a tls-auth-name can expose zone data to unauthenticated clients.

Risk and Exploitability

The CVSS score of 8.2 signifies high severity. The EPSS score of < 1% indicates a low exploitation probability, but the lack of a certificate requirement implies that remote attackers who can reach the server’s port can exploit easily. The vulnerability is not listed in CISA KEV; nevertheless, it presents a serious threat to the confidentiality of DNS information. Attackers can trigger the bypass over the normal TLS or standard TCP ports, enabling an unauthenticated zone transfer if a matching provide‑xfr rule is configured.

Generated by OpenCVE AI on June 30, 2026 at 01:53 UTC.

Remediation

Vendor Solution

This issue is fixed starting with version 4.14.3.


OpenCVE Recommended Actions

  • Upgrade NSD to version 4.14.3 or later to apply the vendor patch.
  • If an upgrade is not immediately feasible, disable the provide‑xfr rule or configure it to require the dedicated TLS authentication port only.
  • Configure firewall rules to allow zone transfer only through the TLS authentication port, blocking the standard TLS and regular TCP ports for zone transfer traffic.

Generated by OpenCVE AI on June 30, 2026 at 01:53 UTC.

Tracking

Sign in to view the affected projects.

Advisories
Source ID Title
Ubuntu USN Ubuntu USN USN-8474-1 NSD vulnerabilities
History

Tue, 30 Jun 2026 00:45:00 +0000

Type Values Removed Values Added
Weaknesses CWE-303
References
Metrics threat_severity

None

cvssV3_1

{'score': 7.5, 'vector': 'CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N'}

threat_severity

Moderate


Thu, 25 Jun 2026 13:30:00 +0000

Type Values Removed Values Added
First Time appeared Nlnetlabs
Nlnetlabs nsd
Vendors & Products Nlnetlabs
Nlnetlabs nsd
Metrics ssvc

{'options': {'Automatable': 'no', 'Exploitation': 'none', 'Technical Impact': 'partial'}, 'version': '2.0.3'}


Thu, 25 Jun 2026 06:45:00 +0000

Type Values Removed Values Added
Description When a provide-xfr is given with a tls-auth-name, a secondary requesting a transfer should provide a client certificate with that name. However, no client certificate is needed when the request comes in over TLS over the regular tls-port (and not the tls-auth-port) or over over TCP over the regular port, when the other conditions of the provide-xfr rule match.
Title Bypass of client certificate verification with transfer over TLS
Weaknesses CWE-284
CWE-306
References
Metrics cvssV4_0

{'score': 8.2, 'vector': 'CVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N'}


cve-icon MITRE

Status: PUBLISHED

Assigner: NLnet Labs

Published:

Updated: 2026-06-25T12:41:18.144Z

Reserved: 2026-06-17T06:44:23.686Z

Link: CVE-2026-12490

cve-icon Vulnrichment

Updated: 2026-06-25T12:40:18.903Z

cve-icon NVD

No data.

cve-icon Redhat

Severity : Moderate

Publid Date: 2026-06-25T00:00:00Z

Links: CVE-2026-12490 - Bugzilla

cve-icon OpenCVE Enrichment

Updated: 2026-06-30T02:00:05Z

Weaknesses
  • CWE-284

    Improper Access Control

  • CWE-303

    Incorrect Implementation of Authentication Algorithm

  • CWE-306

    Missing Authentication for Critical Function