CVE-2026-42013

What it actually does

The flaw affects GnuTLS certificate validation logic. When a peer certificate contains an oversized Subject Alternative Name (SAN), validation may incorrectly fall back to checking the legacy Common Name (CN) field instead of enforcing SAN-based identity matching. Because modern TLS identity validation is expected to use SAN as the authoritative hostname identity, this fallback can allow a certificate that should not match a target hostname to be accepted. A remote, unauthenticated attacker who can present a crafted certificate and position themselves in a TLS connection path could bypass certificate identity validation, enabling spoofing or man-in-the-middle interception. The CVSS score of 8.2 reflects network exploitability, no authentication or user interaction requirement, and high integrity impact.

Why it matters to the business

Systems and applications using vulnerable GnuTLS versions may trust the wrong TLS endpoint under specific certificate conditions. In practical terms, this can let an attacker impersonate services, intercept or alter traffic, redirect clients, or undermine secure integrations that rely on TLS for server identity. The main operational risk is loss of trust in encrypted connections rather than service outage. Although EPSS is currently low and there is no known KEV listing or public exploit maturity reported, the issue is important for internet-facing services, package repositories, update clients, APIs, identity integrations, and any workload where TLS validation protects high-value transactions.

How an attack unfolds

An attacker first identifies a client or service that uses a vulnerable GnuTLS build for TLS certificate validation. The attacker then obtains or generates a certificate with an oversized SAN field crafted to trigger the faulty validation path while placing a desired hostname or misleading identity in the CN field. To make the attack effective, the attacker must cause the victim to connect through infrastructure they control or otherwise intercept the TLS session, such as by network positioning, DNS manipulation, rogue Wi-Fi, compromised routing, proxy abuse, or service impersonation. During the TLS handshake, the attacker presents the crafted certificate. Instead of rejecting the certificate because the SAN identity is invalid or unprocessable, the vulnerable validation path may fall back to CN matching and accept the certificate. Once accepted, the attacker can impersonate the expected endpoint and potentially read, modify, or inject data into the connection, subject to the application protocol and any additional authentication controls.

How to fix it

Upgrade GnuTLS to a vendor-fixed version once available for the affected operating system or distribution. Because no exact fixed versions were provided in the input, use the relevant Linux distribution, appliance, container base image, or software vendor advisory as the authoritative source for patched package versions. Rebuild and redeploy statically linked applications, containers, appliances, and embedded components that bundle GnuTLS rather than relying only on host package updates. Restart services and applications that load the GnuTLS library so they use the patched code. Where immediate patching is not possible, reduce exposure by enforcing certificate pinning where appropriate, using an alternate TLS stack not affected by this flaw, restricting outbound connections to trusted networks, disabling transparent TLS interception points that could be abused, and adding compensating controls such as strict DNS integrity, egress filtering, and application-layer authentication. Do not rely on CN fallback behavior for hostname identity; ensure applications and policies require SAN-based validation.

How to confirm the fix worked

Inventory systems for GnuTLS packages and libraries, including OS packages, container images, statically linked binaries, language runtime bindings, appliances, and embedded software. Confirm the installed GnuTLS version is at or above the fixed version specified by the relevant vendor advisory. On Linux systems, package-manager queries such as rpm, dpkg, apk, or distribution-specific vulnerability scanners can be used to verify patch status. Confirm running services were restarted after upgrade by checking process start times and loaded library mappings. For applications under direct control, test TLS validation against a certificate with malformed or oversized SAN content and a misleading CN; the connection should fail identity validation rather than succeeding via CN fallback. Also validate that hostname verification policies do not permit CN-only matching when SAN processing fails.

Typical attack path

1. Identify applications, agents, clients, or services that link against vulnerable GnuTLS versions for TLS certificate validation.
2. Prepare or acquire a certificate containing an oversized Subject Alternative Name that can trigger fallback behavior and a Common Name chosen to satisfy hostname matching.
3. Gain a position where victim TLS traffic can be intercepted or redirected, such as malicious DNS, rogue access point, transparent proxy, compromised gateway, or impersonated endpoint.
4. Initiate or wait for a victim connection to the targeted TLS service.
5. Present the crafted certificate during the TLS handshake.
6. Rely on the vulnerable GnuTLS validation behavior to accept CN-based identity despite SAN processing failure.
7. Impersonate the service, relay traffic, capture sensitive data, alter responses, or inject malicious content.

How to detect it

Detecting prior exploitation is difficult because successful exploitation may look like a normal TLS session unless certificate details are logged. Review TLS client, proxy, gateway, EDR, application, and network sensor logs for connections where the presented certificate had unusually large or malformed Subject Alternative Name fields, SAN parsing errors followed by connection success, CN/SAN hostname mismatches, unexpected certificate issuers, or certificate changes for known endpoints. Inspect logs from forward proxies, TLS inspection devices, API gateways, service meshes, package managers, update clients, and applications that use GnuTLS. Search for GnuTLS validation warnings, hostname verification anomalies, and certificate parsing errors near successful outbound or inbound TLS connections. If packet captures, Zeek logs, JA3/JA4 metadata, or certificate telemetry are available, look for oversized X.509 SAN extensions, abnormal certificate lengths, repeated certificate changes for the same destination, and certificates where CN matches the requested hostname but SAN is absent, malformed, oversized, or does not match. Correlate suspicious certificate events with DNS changes, proxy configuration changes, rogue gateway activity, unexpected routes, captive portals, VPN changes, or connections over untrusted networks. No named threat actors or active exploitation campaigns were provided for this CVE, and it is not listed in CISA KEV, so detection should focus on certificate anomalies and possible man-in-the-middle positioning rather than known campaign-specific artifacts.

• gnutls
• Subject Alternative Name
• subjectAltName
• SAN
• Common Name
• CN
• certificate validation
• hostname verification
• certificate verify failed
• certificate verification failed
• SAN parsing
• Subject Alternative Name parsing
• malformed SAN
• oversized SAN
• CN fallback
• Common Name fallback
• hostname mismatch
• certificate hostname mismatch
• The certificate is NOT trusted
• GNUTLS_E_CERTIFICATE_ERROR
• GNUTLS_E_X509_UNKNOWN_SAN
• GNUTLS_E_ASN1_DER_ERROR
• GNUTLS_E_ASN1_VALUE_NOT_FOUND
• GNUTLS_E_ASN1_DER_OVERFLOW
• GNUTLS_E_UNEXPECTED_PACKET_LENGTH

What your security team should do

• Prioritize patching systems that initiate or terminate sensitive TLS connections using GnuTLS, especially internet-facing clients, update mechanisms, package managers, API gateways, service meshes, identity integrations, and automation agents.
• Use software composition analysis and container scanning to identify direct and bundled GnuTLS usage across hosts, images, appliances, and third-party products.
• Track vendor advisories for exact fixed package versions and update base images promptly; rebuild dependent images and applications after the patched library is available.
• Restart or redeploy workloads after patching to ensure vulnerable GnuTLS code is no longer loaded in memory.
• Harden TLS validation policies to require SAN-based identity matching and reject certificates with malformed, oversized, or unprocessable SAN extensions.
• Increase monitoring for suspicious certificate validation failures, unexpected issuer changes, unusual CN/SAN mismatches, and TLS connections to newly observed infrastructure.
• Treat this as a high-impact integrity risk despite currently low EPSS and no KEV status, because successful exploitation can undermine trust in encrypted communications.