CVE-2026-26994: refraction-networking utls · Protection Mechanism Failure
Affects refraction-networking utlsSource CVE Database V5
Not known to be exploited · CVSS 6.5 Medium : upgrade to 1.7.0 when convenient.
Data as of 25 Oct 2026, 19:02 UTC
- EPSS
- 0.3% chance of exploitation in 30 days – higher than 22% of CVEsExploit Prediction Scoring System: the likelihood attackers will use this flaw soon.
- Patch
- Available – fixed in 1.7.0
CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:L/I:L/A:NExploitation evidence
Disclosed: evidence found.
CVE published 20 Feb 2026
Detectable: no evidence on record.
No public nuclei template indexed
Weaponised: no evidence on record.
No public exploit code indexed in Metasploit or Exploit-DB
Exploited in the wildExploited: no evidence on record.
Not in CISA KEV and no source reports exploitation
Observed by OffSeq MirageSeen by Mirage: no evidence on record.
No attack traffic recorded by OffSeq Mirage sensors
A missing step is not evidence of safety. Sources: cve.org (opens in a new tab), the Metasploit, Exploit-DB and nuclei-templates index as of 2026-10-25.
What to do
Upgrade refraction-networking utls to 1.7.0.
Affected software
| Product | Affected | Fixed in |
|---|---|---|
| refraction-networkingutls | Affected
| Fixed in
|
AI-suggested
The primary mitigation is to upgrade all uTLS deployments to version 1.7.0 or later, where the downgrade protection mechanism is correctly implemented. For organizations unable to upgrade immediately, deploying network-level protections such as TLS interception detection and anomaly monitoring can help identify downgrade attempts. Implementing strict TLS version policies on servers to refuse connections below TLS 1.3 can reduce the attack surface. Additionally, monitoring network traffic for unusual ClientHello modifications or absence of SupportedVersions extensions may help detect active downgrade attacks. Security teams should audit their software dependencies to identify usage of vulnerable uTLS versions, especially in privacy-sensitive or security-critical applications. Educating developers and administrators about the importance of TLS downgrade protections and proper ClientHello handling is also recommended to prevent similar issues in custom TLS implementations.
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.
References
- github.com/refraction-networking/utls/security/advisories/GHSA-pmc3-p9hx-jq96 (opens in a new tab)
- github.com/refraction-networking/utls/issues/181 (opens in a new tab)
- github.com/refraction-networking/utls/pull/337 (opens in a new tab)
- github.com/refraction-networking/utls/commit/f8892761e2a4d29054264651d3a86fda83bc83f9 (opens in a new tab)