CVE-2026-88647: 
GnuTLS vulnerability analysis and mitigation

CVE-2026-88647 is a hostname verification bypass vulnerability in GnuTLS v3.8.13 that allows unauthenticated network attackers to circumvent the Common Name (CN) fallback mechanism via a crafted certificate, enabling eavesdropping on encrypted communications. The flaw was published on October 8, 2026, and is classified as Critical with a CVSS v3.1 base score of 9.1 (Github Advisory, Red Hat Bugzilla). It specifically affects GnuTLS version 3.8.13 and is rooted in improper certificate validation logic introduced or exposed by a prior fix (CVE-2026-42012) (GitHub Gist).

The vulnerability is classified under CWE-295 (Improper Certificate Validation) and CWE-297 (Improper Validation of Certificate with Host Mismatch). The root cause lies in gnutls_x509_othername_to_virtual() in lib/x509/virt-san.c, which only recognizes an SRV otherName SAN entry when its value decodes as an IA5String; if the value is encoded as an OCTET STRING (ASN.1-valid but non-conformant), decoding fails and the entry retains the generic type GNUTLS_SAN_OTHERNAME (type 5) rather than GNUTLS_SAN_OTHERNAME_SRV. The PRECLUDES_CN_FALLBACK macro in lib/x509/hostname-verify.c covers OTHERNAME_SRV but not the generic OTHERNAME type, so the CN fallback executes normally and a certificate with an attacker-chosen CN matching the victim hostname is accepted. A proof-of-concept demonstrating end-to-end bypass using gnutls-serv and gnutls-cli with a CA-signed chain has been published (GitHub Gist, GnuTLS Issue).

Successful exploitation allows an unauthenticated network attacker to present a CA-signed certificate containing a malformed SRV otherName SAN and a victim hostname in the CN field, causing GnuTLS-based clients to accept the TLS session as trusted. This enables interception and eavesdropping on encrypted communications (high confidentiality impact) and potential manipulation of data in transit (high integrity impact). Availability is not directly affected, but any application or service relying on GnuTLS for TLS hostname verification — including those on Linux distributions shipping GnuTLS 3.8.13 — is exposed to man-in-the-middle attacks (Github Advisory, Red Hat Bugzilla).

A proof-of-concept (PoC) is publicly available on GitLab and GitHub demonstrating the hostname verification bypass with concrete reproduction steps (GnuTLS Issue, GitHub Gist). The vulnerability requires no authentication and no user interaction, and exploitation is automatable over the network. The EPSS score is approximately 0.11–0.21%, and there is no evidence of active in-the-wild exploitation at this time; it has not been added to the CISA KEV catalog (Github Advisory).

1. Obtain a CA-signed certificate: Acquire or arrange issuance of a certificate from a trusted CA that contains an SRV otherName SubjectAltName (SAN) entry whose value is encoded as an OCTET STRING (non-conformant but ASN.1-valid) rather than an IA5String, and whose Subject CN field contains the victim's target hostname.
2. Set up a rogue TLS server: Configure a server (e.g., using gnutls-serv) to present the crafted certificate on the target port, positioned via DNS spoofing, ARP poisoning, or BGP hijacking to intercept connections intended for the victim hostname.
3. Intercept client connections: Route victim client traffic (using GnuTLS 3.8.13 for TLS) to the rogue server. The client calls gnutls_x509_crt_check_hostname2() for hostname verification.
4. Trigger the bypass: GnuTLS fails to decode the OCTET STRING SRV otherName as IA5String, leaving the SAN type as generic GNUTLS_SAN_OTHERNAME; PRECLUDES_CN_FALLBACK does not suppress CN fallback for this type, so the CN is matched against the victim hostname and accepted.
5. Eavesdrop or manipulate traffic: The TLS handshake completes successfully from the client's perspective; the attacker can now decrypt, read, or modify the encrypted session data (GitHub Gist, GnuTLS Issue).

• Network: Unexpected TLS handshakes completing to servers presenting certificates with SRV otherName SANs encoded as OCTET STRING; anomalous certificate chains where the SAN type does not match the CN hostname; unusual intermediate proxies or unexpected IP addresses resolving for known hostnames.
• Logs: TLS library logs or application logs showing successful certificate validation for connections where the SAN and CN do not conventionally align; GnuTLS debug output (GNUTLS_DEBUG_LEVEL) indicating GNUTLS_SAN_OTHERNAME type without suppression of CN fallback.
• File System: Presence of PoC artifacts such as poc.zip, canonical.sh, or files from https://github.com/lkloliver/poc/tree/main/CVE-2026-88647 on systems under investigation.
• Process: Unexpected gnutls-cli or gnutls-serv processes; certificate inspection tools (e.g., certtool, openssl) run against suspicious certificates revealing OCTET STRING-encoded SRV otherName SAN entries (GitHub Gist, GnuTLS Issue).

Update GnuTLS to a patched version that correctly handles OCTET STRING-encoded SRV otherName SAN entries and properly suppresses CN fallback in all cases. Apply updates referenced in the Red Hat advisory and GitHub advisory as appropriate for your distribution (Red Hat Bugzilla, Github Advisory). Until a patch is applied, consider disabling or restricting applications that rely on GnuTLS hostname verification for sensitive communications, and monitor for anomalous TLS certificate presentations. Prioritize patching given the high CVSS score (9.1) and public PoC availability.

Red Hat has tracked the vulnerability as high severity in its Bugzilla system and assigned it to the Product Security DevOps Team for remediation (Red Hat Bugzilla). Microsoft also acknowledged the CVE in its Security Response Center update guide (Microsoft). The vulnerability was noted in the context of Microsoft's October 2026 Patch Tuesday coverage, which addressed a record number of flaws (BleepingComputer).