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.
Advisories
| Source | ID | Title |
|---|---|---|
Ubuntu USN |
USN-8474-1 | NSD vulnerabilities |
Fixes
Solution
This issue is fixed starting with version 4.14.3.
Workaround
No workaround given by the vendor.
References
| Link | Providers |
|---|---|
| https://www.nlnetlabs.nl/downloads/nsd/CVE-2026-12490.txt |
|
History
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
|
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
|
Projects
Sign in to view the affected projects.
Status: PUBLISHED
Assigner: NLnet Labs
Published:
Updated: 2026-06-25T12:41:18.144Z
Reserved: 2026-06-17T06:44:23.686Z
Link: CVE-2026-12490
Updated: 2026-06-25T12:40:18.903Z
No data.
No data.
OpenCVE Enrichment
Updated: 2026-06-25T13:15:03Z
Ubuntu USN