CVE-2026-67693: 
GnuTLS vulnerability analysis and mitigation

CVE-2026-67693 is an improper certificate validation vulnerability in GnuTLS v.3.8.13 that allows unauthenticated remote attackers to obtain sensitive information by presenting end-entity X.509 certificates with a contradictory combination of Key Usage (KU) and Extended Key Usage (EKU) extensions. GnuTLS fails to reject such certificates, effectively bypassing certificate validation enforcement. The vulnerability was publicly disclosed on October 8, 2026, and carries a CVSS v3.1 base score of 7.5 (High) (GitHub Advisory, Red Hat Bugzilla).

The root cause (CWE-295: Improper Certificate Validation) lies in GnuTLS treating a key_usage == 0 value as equivalent to the Key Usage extension being absent, thereby skipping enforcement entirely. Specifically, _gnutls_check_key_purpose() in lib/x509/verify.c (lines 1119–1178) only inspects EKU OIDs without cross-checking Key Usage bits, and _gnutls_check_key_usage_for_sig() in lib/tls-sig.c skips validation when key_usage == 0. An attacker can craft a certificate with a critical Key Usage extension that clears all usage bits (no digitalSignature, no keyEncipherment) while EKU still lists id-kp-serverAuth; both certtool and gnutls-cli verification paths accept such a certificate as trusted, violating RFC 5280. The issue was independently tracked upstream as GitLab issue #1642, which had been open without a fix since January 2026 at the time of disclosure (GitHub Gist, GitHub Advisory).

Successful exploitation allows an unauthenticated network attacker to bypass TLS certificate validation in systems relying on GnuTLS for authentication workflows, potentially enabling man-in-the-middle attacks and exposure of sensitive information transmitted over TLS. The confidentiality impact is rated High, with no direct integrity or availability impact. Deployments that enforce Key Usage policy through GnuTLS — such as enterprise or private CA environments — are most at risk, as a crafted certificate with contradictory KU/EKU extensions will be accepted as valid (GitHub Advisory, GitHub Gist).

There is no confirmed evidence of in-the-wild exploitation or a weaponized exploit kit at this time. The researcher published a proof-of-concept repository at https://github.com/lkloliver/poc/tree/main/CVE-2026-67693, though the disclosure was made without prior coordination with the GnuTLS security team (GitHub Gist). The EPSS score is approximately 0.11–0.19%, indicating low near-term exploitation probability. The vulnerability is not listed in the CISA KEV catalog, and NVD SSVC assessment notes exploitation as "none" with the attack being automatable (GitHub Advisory).

1. Craft a malicious certificate: Generate an end-entity X.509 certificate signed by a CA trusted by the target, where the critical Key Usage extension has all bits set to zero (no digitalSignature, no keyEncipherment) and the Extended Key Usage extension includes id-kp-serverAuth.
2. Deploy the certificate: Configure a TLS server (e.g., using OpenSSL or a custom server) to present this crafted certificate during the TLS handshake.
3. Target a GnuTLS client: Direct a client application using GnuTLS 3.8.13 for TLS peer verification (e.g., via gnutls-cli) to connect to the attacker-controlled server.
4. Bypass validation: GnuTLS's _gnutls_check_key_purpose() accepts the certificate because key_usage == 0 is treated as unrestricted, and the EKU check passes for serverAuth — the handshake completes successfully despite the contradictory KU/EKU combination.
5. Intercept sensitive data: With the TLS session established using the fraudulent certificate, the attacker can decrypt or intercept sensitive information transmitted by the client (GitHub Gist).

• Network: TLS connections to servers presenting certificates where the critical Key Usage extension has all bits cleared (value 0x00) while EKU includes id-kp-serverAuth; unexpected TLS handshake completions with certificates that should be rejected per RFC 5280.
• Certificate Artifacts: X.509 certificates with a critical Key Usage extension explicitly set to zero combined with an Extended Key Usage extension listing TLS purposes (e.g., serverAuth, clientAuth); detectable via certificate inspection tools such as openssl x509 -text or certtool --certificate-info.
• Logs: GnuTLS application logs showing successful certificate verification for certificates that contain contradictory KU/EKU combinations without any rejection or warning messages.

The primary remediation is to update GnuTLS to a version that properly validates and rejects X.509 certificates with contradictory KU and EKU extension combinations. The upstream fix is tracked in GnuTLS GitLab issue #1642; users should monitor the official GnuTLS release page for a patched release beyond 3.8.13. As a workaround, organizations can implement additional certificate validation at the application layer or use a different TLS library until a patched GnuTLS version is available. Red Hat has opened a tracking bug (BZ#2548190) and users of RHEL-based systems should monitor Red Hat Security Advisories for downstream patches (GitHub Advisory, Red Hat Bugzilla).

The disclosure drew criticism from the GnuTLS community due to the researcher's failure to follow responsible disclosure practices — a GnuTLS maintainer (t184256) publicly commented on the GitHub Gist urging the researcher to report security-sensitive issues privately before public disclosure. Another community member (samueloph) identified that the issue corresponds to the pre-existing upstream GitLab issue #1642, which had been open since January 2026 without a fix. The researcher acknowledged the oversight and committed to following GnuTLS's private security reporting policy for future findings (GitHub Gist).