CVE-2026-42012: GnuTLS Information Disclosure Flaw

CVE-2026-42012 Overview

A flaw in GnuTLS allows a remote attacker to bypass proper certificate validation using crafted X.509 certificates. The certificate must contain Uniform Resource Identifier (URI) or Service (SRV) Subject Alternative Names (SANs). When such SANs are present, GnuTLS incorrectly falls back to matching DNS hostnames against the certificate Common Name (CN). This behavior contradicts RFC 6125, which deprecates CN-based hostname matching when SANs are present. Attackers can leverage this gap to spoof legitimate Transport Layer Security (TLS) services or intercept sensitive traffic.

Critical Impact
Improper Certificate Validation [CWE-295] enables service impersonation and interception of TLS-protected communications by attackers presenting crafted certificates.

Affected Products

GnuTLS library (versions shipped by Red Hat, see RHSA-2026:20611)
Red Hat Enterprise Linux distributions bundling the affected GnuTLS package
Downstream applications relying on GnuTLS for X.509 hostname verification

Discovery Timeline

2026-05-26 - CVE-2026-42012 published to the National Vulnerability Database (NVD)
2026-05-27 - Last updated in NVD database

Technical Details for CVE-2026-42012

Vulnerability Analysis

The weakness resides in the GnuTLS X.509 hostname verification routine. When a server certificate includes one or more URI or SRV Subject Alternative Names but no dNSName SAN, GnuTLS reverts to comparing the client-requested hostname against the certificate Common Name. Modern TLS guidance forbids this fallback because CN values are not authoritative identity bindings. An attacker who can obtain a certificate from any trusted issuer, using only URI or SRV SANs, can place arbitrary hostnames in the CN field. GnuTLS will then accept that certificate as valid for DNS hostnames the issuer never intended to authorize. The flaw is tracked under CWE-295: Improper Certificate Validation.

Root Cause

The root cause is incorrect SAN-type handling during hostname matching. GnuTLS treats the absence of a dNSName SAN as authorization to consult the CN, even when other SAN types are present. RFC 6125 requires implementations to stop matching once any SAN of the relevant type exists, or to fail when none does, instead of consulting the CN.

Attack Vector

The attack is network-based and requires user interaction, such as visiting an attacker-controlled host or accepting a connection mediated by an attacker in a privileged network position. The adversary presents a certificate containing URI or SRV SANs and a CN populated with the target DNS hostname. Vulnerable GnuTLS clients accept the certificate, enabling impersonation and machine-in-the-middle interception of subsequent TLS traffic. No verified public proof-of-concept code is available; refer to the Red Hat CVE record and Red Hat Bug 2467441 for technical specifics.

Detection Methods for CVE-2026-42012

Indicators of Compromise

Server certificates containing URI or SRV SANs combined with a CN that encodes a DNS hostname unrelated to the SAN values.
TLS sessions where the negotiated peer certificate lacks a dNSName SAN yet the client connected by DNS name.
Unexpected certificate issuers appearing in trust chains for high-value internal hostnames.

Detection Strategies

Inspect captured TLS handshakes with tooling such as openssl x509 -text or tshark to flag certificates whose CN is treated as a DNS identity.
Compare certificate transparency log entries against the inventory of expected certificates for internal services.
Alert on GnuTLS-linked applications that establish TLS sessions to hosts whose presented certificate omits dNSName SANs.

Monitoring Recommendations

Forward TLS metadata, including SAN types and CN values, into a central analytics pipeline for anomaly review.
Track installed GnuTLS package versions across the fleet and correlate against the fixed builds in RHSA-2026:20611.
Monitor outbound TLS traffic for unexpected certificate issuers, especially on hosts running GnuTLS-based clients.

How to Mitigate CVE-2026-42012

Immediate Actions Required

Apply the GnuTLS update from RHSA-2026:20611 or the equivalent advisory from your distribution.
Inventory all software dynamically linked against libgnutls and schedule restarts after patching.
Rotate any certificates issued with URI or SRV SANs whose CN encodes a DNS hostname.

Patch Information

Red Hat has published fixed packages through RHSA-2026:20611. The fix aligns GnuTLS hostname verification with RFC 6125 by removing the CN fallback when any SAN is present. Operators should consult the Red Hat CVE Details page for the full list of affected and fixed package versions.

Workarounds

Configure applications to perform hostname verification at the application layer using libraries that strictly enforce SAN matching.
Restrict trusted certificate authorities to internal issuers that do not mint certificates with URI or SRV SANs for externally reachable services.
Enforce certificate pinning for high-value endpoints until patched GnuTLS packages are deployed.

bash

# Verify installed GnuTLS version and patch status on Red Hat systems
rpm -q gnutls
dnf updateinfo info RHSA-2026:20611
sudo dnf upgrade --advisory=RHSA-2026:20611