CVE-2026-26994
uTLS ServerHellos are accepted without checking TLS 1.3 downgrade canaries
In short
uTLS did not properly validate downgrade protection in TLS 1.3 connections, allowing attackers to downgrade the connection to older, weaker TLS versions without detection. This weakens security and allows fingerprinting of uTLS users.
Technical detail
uTLS versions ≤1.6.7 fail to check RFC 8446 downgrade canaries in ServerHello random fields when using custom ClientHello specs. An active network adversary can strip the SupportedVersions extension from ClientHello to force downgrade to TLS 1.2; the client accepts the modified ServerHello without validating the canary, enabling version downgrade attacks and client fingerprinting.
Summary generated and translated by AI from the official description.
uTLS is a fork of crypto/tls, created to customize ClientHello for fingerprinting resistance while still using it for the handshake. In versions 1.6.7 and below, 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. This issue has been fixed in version 1.7.0.
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:N
Affected products
refraction-networking · utlsWant to know if your infrastructure is exposed to this?
Talk to TrueHacking →