CVE-2026-12490When a provide-xfr is given with a tls-auth-name, a secondary requesting a transfer should provide a client certificate with that name.
Updated under an hour ago ()
Does this affect you?
It affects nlnetlabs nsd. Add what you run to find out whether that includes you.
No exploitation reported and no EPSS estimate yet.
Do this next
Free account, 1 product
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
- 7.5 HIGH (v3.1, NVD)CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:N
- Weakness (CWE)
- CWE-284, CWE-306
- Known exploited
- Not in CISA's KEV catalog
- EPSS (exploitation in the next 30 days)
- Not loaded for this CVE
- Assigned by
- Not given
- NVD analysis
- Analyzed
- Record last updated
- Jun 26, 2026
- First seen by InfoSec Signals
- Oct 9, 2026
Affected products
nlnetlabs nsd nlnetlabs:nsd | before 4.14.3 | NVD |
References
- https://www.nlnetlabs.nl/downloads/nsd/CVE-2026-12490.txtpatch, vendor-advisory
The CVE record on cve.org NVD's entry
The CVE record is authoritative. Products marked “from the name” were identified from the CNA's free-text names, not a CPE, and are matched less certainly. This product uses the NVD API but is not endorsed or certified by the NVD.