CVE-2026-12490
When a provide-xfr is given with a tls-auth-name, a secondary requesting a transfer should provide a client certificate with that name.
Does this matter?
High impact if exploited, but EPSS currently rates exploitation as unlikely (0.16%). Schedule it in the normal patch cycle and watch for a rise in EPSS or a public exploit.
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.
- CVSS 4.0
- 8.2 HIGHCVSS:4.0/AV:N/AC:H/AT:N/PR:N/UI:N/VC:H/VI:N/VA:N/SC:N/SI:N/SA:N/E:X/CR:X/IR:X/AR:X/MAV:X/MAC:X/MAT:X/MPR:X/MUI:X/MVC:X/M
- EPSS
- 0.16% probability · 5th percentile
- CISA KEV
- Not listed
- Weakness
- CWE-284, CWE-306
- Affected
- nlnetlabs/nsd
- Source
- sep@nlnetlabs.nl
References
- https://www.nlnetlabs.nl/downloads/nsd/CVE-2026-12490.txtPatch, Vendor Advisory
Source: NVD record, EPSS from FIRST.org, KEV from CISA. Refreshed daily.