CVE-2026-26994: 
Wolfi vulnerability analysis and mitigation

CVE-2026-26994 is a TLS 1.3 downgrade protection bypass vulnerability in uTLS (github.com/refraction-networking/utls), a Go fork of crypto/tls designed for TLS fingerprinting resistance. Affecting versions 1.6.7 and below, the flaw allows an active network adversary to downgrade TLS 1.3 connections to weaker protocol versions (e.g., TLS 1.2) without detection. The vulnerability was disclosed on February 20, 2026, with the fix released in version 1.7.0. It carries a CVSS v3.1 base score of 6.5 (Medium) (GitHub Advisory, Red Hat Bugzilla).

The root cause is a failure to implement the TLS 1.3 downgrade protection mechanism defined in RFC 8446 Section 4.1.3 (CWE-693: Protection Mechanism Failure; CWE-358: Improperly Implemented Security Check for Standard). When a uTLS ClientHello spec is used, the library did not validate the downgrade canary embedded in the last 8 bytes of the ServerHello random field. An active man-in-the-middle attacker can strip the SupportedVersions extension from the ClientHello, causing the server to respond with a TLS 1.2 ServerHello containing the downgrade canary — which uTLS silently ignores, accepting the downgraded connection. The fix (commit f889276) adds the missing canary check in u_handshake_client.go, mirroring the protection already present in Go's standard library (GitHub Commit, GitHub PR #337).

A successful attack forces the uTLS client to communicate over a weaker TLS version (e.g., TLS 1.2), potentially exposing the session to cipher suite downgrades and other protocol-level attacks that exploit weaker cryptographic guarantees. This results in partial confidentiality and integrity loss, as the negotiated cipher suite may be weaker than intended. Additionally, the same technique can be used by a passive or active network observer to fingerprint uTLS connections — undermining the library's primary purpose of fingerprinting resistance — which is particularly impactful for censorship-circumvention tools relying on uTLS (GitHub Advisory, Red Hat Bugzilla).

No public proof-of-concept exploit code is known to exist, and there is no evidence of in-the-wild exploitation at this time. The attack requires an active network adversary capable of intercepting and modifying TLS handshake traffic (man-in-the-middle position), which raises the practical bar for exploitation. The EPSS score is 0.012% (0.000120), reflecting a low probability of near-term exploitation. The vulnerability is not listed in the CISA Known Exploited Vulnerabilities (KEV) catalog (Feedly, GitHub Advisory).

1. Gain network position: Position as a man-in-the-middle between a uTLS client (running version ≤ 1.6.7) and a TLS server, using techniques such as ARP spoofing, BGP hijacking, or a rogue access point.
2. Intercept the ClientHello: Capture the outgoing TLS ClientHello message sent by the uTLS client, which includes the SupportedVersions extension advertising TLS 1.3 support.
3. Strip the SupportedVersions extension: Modify the intercepted ClientHello to remove the SupportedVersions extension before forwarding it to the server, causing the server to interpret the handshake as a TLS 1.2 (or lower) negotiation.
4. Relay the server's TLS 1.2 ServerHello: The server responds with a TLS 1.2 ServerHello containing the RFC 8446 downgrade canary in the last 8 bytes of the random field (TLS 1.3, I'm not going back). Forward this response to the uTLS client.
5. Client accepts downgraded connection: Because uTLS ≤ 1.6.7 does not check the downgrade canary, the client accepts the TLS 1.2 connection without raising an alert, completing the downgrade attack.
6. Exploit weaker session or fingerprint: The attacker can now observe or manipulate traffic under the weaker TLS 1.2 session, or use the observable handshake pattern to fingerprint the uTLS client (GitHub Advisory, GitHub Commit).

• Network: TLS handshakes from uTLS clients that negotiate TLS 1.2 (or lower) despite the client advertising TLS 1.3 support; absence of the SupportedVersions extension in ClientHello messages from hosts known to use uTLS.
• Network: ServerHello messages containing the RFC 8446 downgrade canary (444f574e47524401 for TLS 1.2 or 444f574e47524400 for TLS 1.1) in the last 8 bytes of the random field, followed by a completed handshake (indicating the client did not abort).
• Logs: Application or TLS library logs showing TLS 1.2 session establishment for connections expected to use TLS 1.3, without any downgrade alert or error.
• Network: Unexpected TLS version negotiation patterns on network segments where uTLS-based tools (e.g., censorship circumvention proxies) are deployed.

The primary remediation is to upgrade uTLS to version 1.7.0 or later, which adds the missing downgrade canary check in u_handshake_client.go (commit f889276) (GitHub PR #337). For environments where immediate patching is not feasible, network-level mitigations such as VPNs, network segmentation, or restricting traffic to trusted paths can reduce the risk of man-in-the-middle attacks. Downstream projects that depend on uTLS (e.g., Cloak, Xray-core, and others) should also update their dependency to v1.7.0 (GitHub Advisory).

The vulnerability was originally raised as a community issue in April 2023 (GitHub Issue #181) by the Hiddify project, which noted the missing downgrade protection while investigating TLS-related anomalies in Iran — highlighting the real-world relevance of this flaw for censorship-circumvention tools (GitHub Issue #181). The fix was merged by maintainer mingyech on April 20, 2025, and the security advisory was published on April 23, 2025. Several downstream projects (including Cloak, yuhaiin, and others) quickly issued automated dependency update PRs referencing the security fix, indicating broad awareness in the Go networking community (GitHub PR #337).