CVE-2026-42012

What it actually does

This is a certificate name-validation flaw in GnuTLS. When a remote peer presents a specially crafted X.509 certificate containing URI or SRV Subject Alternative Name entries, affected GnuTLS validation logic may incorrectly fall back to comparing the requested DNS hostname against the certificate Common Name. Because modern TLS hostname validation should prioritize DNS Subject Alternative Names and avoid unsafe Common Name fallback in these cases, the flaw can allow a certificate that should not be accepted for a service to be treated as valid. The main technical risk is service impersonation and TLS interception, leading to loss of integrity and limited confidentiality impact for connections made by affected clients or services.

Why it matters to the business

Systems and applications that rely on affected GnuTLS versions may trust the wrong TLS certificate under specific conditions, allowing an attacker in a suitable network position or operating a malicious service endpoint to impersonate legitimate services. This can expose credentials, session tokens, API traffic, software update channels, or other sensitive data exchanged over TLS, and can undermine trust in service-to-service communication. The CVSS score indicates meaningful risk, especially to integrity, but current public exploitation signals are low: EPSS is 0.00354 with no 30-day increase, it is not listed in CISA KEV, no ransomware association is reported, and no public exploit maturity is identified. Organizations should still remediate because TLS validation weaknesses often affect many downstream applications and may be difficult to detect after the fact.

How an attack unfolds

An attacker first identifies a client, service, or application that uses an affected GnuTLS library for TLS certificate validation. The attacker then obtains or creates a certificate that includes URI or SRV Subject Alternative Names and a Common Name chosen to match the hostname the victim expects to reach. To exploit the flaw, the attacker must cause the victim to connect to an attacker-controlled TLS endpoint or position themselves to intercept traffic, such as through DNS manipulation, routing control, compromised network infrastructure, malicious proxy configuration, captive portal behavior, or control of an upstream service endpoint. When the victim initiates the TLS connection, the attacker presents the crafted certificate. An affected GnuTLS validation path may incorrectly fall back to Common Name hostname matching even though the SAN content should prevent that behavior. If the certificate chain is otherwise trusted and policy checks pass, the victim may accept the attacker-controlled endpoint as legitimate, enabling traffic interception, credential capture, response tampering, or impersonation of the intended service.

How to fix it

Upgrade GnuTLS to a vendor-fixed version as soon as packages are available from the operating system or software distribution. No exact fixed versions were provided in the input, so use the relevant distribution security advisory, package changelog, or upstream GnuTLS release notes to identify the corrected build. Ensure all products that bundle or statically link GnuTLS are rebuilt against a fixed library; updating only the system package may not remediate statically linked applications, containers, appliances, or embedded images. Where supported, configure applications to enforce modern hostname validation rules: require a valid dNSName Subject Alternative Name for DNS hostnames, avoid Common Name fallback, and reject certificates with inappropriate SAN types for the connection being made. As compensating controls, restrict outbound TLS destinations, harden DNS and proxy configuration, use certificate pinning only where operationally safe, monitor for unexpected certificate issuers or SAN types, and prefer mutual TLS or application-layer authentication for high-value service-to-service connections.

How to confirm the fix worked

Confirm package remediation by checking the installed GnuTLS package versions through the relevant package manager and comparing them with the vendor advisory for this issue. Inventory applications and containers that include their own GnuTLS copy, including statically linked binaries, language runtimes, appliances, and base images. Functionally validate the fix by connecting an affected client to a controlled TLS test endpoint that presents a certificate containing URI or SRV SANs with a Common Name matching the requested hostname but without an appropriate DNS SAN; a remediated client should reject the certificate. Review application TLS settings to verify that Common Name fallback is disabled or not used when SAN handling should govern hostname validation. For externally distributed software, verify that rebuilt artifacts, containers, and packages are based on the fixed GnuTLS library rather than only patched source dependencies.

Typical attack path

1. Identify applications, clients, agents, package managers, service connectors, or embedded products that use affected GnuTLS certificate validation.
2. Gain a position where victim TLS connections can be redirected, intercepted, or induced to connect to an attacker-controlled endpoint.
3. Prepare a certificate with URI or SRV Subject Alternative Names and a Common Name matching the victim's expected DNS hostname, with a chain trusted by the target environment.
4. Trigger the victim application to initiate a TLS connection to the spoofed or intercepted service.
5. Present the crafted certificate during the TLS handshake.
6. Rely on the affected validation behavior to fall back to Common Name matching and accept the certificate incorrectly.
7. Use the accepted TLS session to impersonate the legitimate service, observe sensitive data, capture credentials or tokens, or tamper with responses.

How to detect it

Successful exploitation may leave little or no application-level evidence because the TLS connection can appear valid to the affected client. Detection should focus on historical TLS, proxy, EDR, network sensor, DNS, and application connection telemetry. Look for TLS server certificates presented to affected clients where the certificate contains URI or SRV Subject Alternative Names, lacks a matching DNS Subject Alternative Name for the requested hostname, but has a Common Name matching the requested hostname. Compare observed certificate fingerprints, issuers, serial numbers, SAN fields, and validity periods against known-good baselines for sensitive services. Review DNS resolver logs, proxy logs, VPN logs, captive portal logs, firewall records, and routing changes for unexpected redirection or connections to unusual IP addresses for trusted service names. On endpoints and servers, investigate applications linked to GnuTLS that connected to sensitive destinations around suspicious certificate observations. If TLS interception infrastructure is used, review generated certificates and policy logs for URI or SRV SAN handling anomalies. Because no specific threat actors, campaigns, or public exploit artifacts were provided, hunts should be behavior-based rather than signature-only.

What your security team should do

• Prioritize identification of internet-facing, authentication-bearing, update-fetching, proxying, and service-to-service applications that use GnuTLS for TLS validation.
• Patch GnuTLS through the operating system or vendor distribution as soon as a fixed package is available, and track exceptions for bundled, containerized, embedded, or statically linked copies.
• Do not rely solely on low EPSS or absence from KEV; certificate validation flaws can be exploited opportunistically when attackers control network routing, DNS, proxies, or service endpoints.
• Add regression tests for TLS hostname validation using certificates with URI and SRV SANs to ensure affected applications reject unsafe certificate combinations.
• Monitor TLS telemetry for certificates presented to sensitive clients that contain URI or SRV SANs but lack appropriate DNS SANs for the requested hostname.
• Review proxy, DNS, VPN, captive portal, and enterprise TLS inspection infrastructure for paths where attackers or misconfigurations could redirect clients to spoofed services.
• For high-risk systems, enforce certificate pinning, mutual TLS, or explicit trust policies where feasible and maintainable.
• Document remediation status across base images, containers, appliances, and third-party products because GnuTLS is commonly consumed indirectly by downstream software.