CVE-2026-12490: Bypass of client certificate verification with transfer over TLS
Last updated 29 June 2026
Other sources
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.
— Launchpad
Affected Software
Remediation
Recommended actions to resolve this vulnerability, in priority order.
- Upgrade
Upgrade
debian/nsdto a version that resolves this vulnerability.Fixed in 4.14.3-1 - Upgrade
Upgrade to a fixed release to a version that resolves this vulnerability.
Fixed in 4.14.3 - Configuration
When using a provide-xfr with a tls-auth-name, require the secondary requesting the transfer to present a client certificate with that tls-auth-name (client certificate needed for the transfer request when tls-auth-name is set).
provide-xfr (named TLS auth) / secondary transfer request client certificate verification = required when using tls-auth-name
Event History
Frequently Asked Questions
What is the severity of CVE-2026-12490?
CVE-2026-12490 has a severity rating of high, with a CVSS score of 8.2.
How do I fix CVE-2026-12490?
To mitigate CVE-2026-12490, ensure that client certificate verification is enforced for all TLS connections.
What software is affected by CVE-2026-12490?
CVE-2026-12490 affects ISC BIND versions which implement the provide-xfr feature.
What does CVE-2026-12490 exploit?
CVE-2026-12490 exploits a bypass of client certificate verification when transfers occur over standard TLS ports.
When was CVE-2026-12490 published?
CVE-2026-12490 was published on June 25, 2026.