Skip to main content
CVE-2026-26994VulnerabilityPublished

CVE-2026-26994: refraction-networking utls · Protection Mechanism Failure

Affects refraction-networking utlsSource CVE Database V5

0

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

CVSS 3.1 base score
6.5Medium
How severe the flaw is on the 0–10 CVSS scale.
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:N

Exploitation evidence

  1. Disclosed: evidence found.

    CVE published 20 Feb 2026

  2. Detectable: no evidence on record.

    No public nuclei template indexed

  3. Weaponised: no evidence on record.

    No public exploit code indexed in Metasploit or Exploit-DB

  4. Exploited in the wild: no evidence on record.

    Not in CISA KEV and no source reports exploitation

  5. Observed by OffSeq 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

ProductAffectedFixed in
refraction-networkingutlsAffected
  • <1.7.0
Fixed in
  • 1.7.0

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

Community reviews

Loading reviews…