GitHub Advisoryadvisory · Go

GHSA-pmc3-p9hx-jq96 uTLS ServerHellos are accepted without checking TLS 1.3 downgrade canaries

MEDIUM Published 2025-04-23 Modified 2026-02-20 Official page ↗
Aliases
CVE-2026-26994
Ecosystem
Go
Packages
github.com/refraction-networking/utls
Severity
Moderate
CVSS vector
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Weaknesses
CWE-693
Reviewed
2025-04-23

Affected packages

• Go github.com/refraction-networking/utls: < 1.7.0 → fixed in 1.7.0

Description

Description Before version 1.7.0, utls did not implement the TLS 1.3 downgrade protection mechanism specified in RFC 8446 Section 4.1.3 when using a utls ClientHello spec. This allowed an active network adversary to downgrade TLS 1.3 connections initiated by a utls client to a lower TLS version (e.g., TLS 1.2) by modifying the ClientHello message to exclude the SupportedVersions extension, causing the server to respond with a TLS 1.2 ServerHello (along with a downgrade canary in the ServerHello random field). Because utls did not check the downgrade canary in the ServerHello random field, clients would accept the downgraded connection without detecting the attack. This attack could also be used by an active network attacker to fingerprint utls connections. Fix Commit or Pull Request refraction-networking/utls#337, specifically refraction-networking/utls@f8892761e2a4d29054264651d3a86fda83bc83f9 References • https://github.com/refraction-networking/utls/issues/181

Related

Alias · CVE (1)

  • CVE-2026-26994 uTLS is a fork of crypto/tls, created to customize ClientHello for fingerprinting resistance while still using it for the handshake. vulnerability

Weakness · CWE (1)

  • CWE-693 Protection Mechanism Failure weakness

References