github.com/refraction-networking/utls
Fork of the Go standard TLS library, providing low-level access to the ClientHello for mimicry purposes.
View on Github
Activity
- Latest release
- 8mo ago
- Total releases
- 53
- Cadence
- ~7 days
- Last 12 months
- 2
Reach
- Stars
- 2.5k
Details
- First release
- Jul 13, 2021
| Version | Released | |
|---|---|---|
v1.8.2
patch
|
v1.8.2
patch
Dependencies (5)
|
|
v1.8.1
patch
1 CVE
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev |
v1.8.1
patch
Dependencies (5)
|
|
v1.8.0
minor
2 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev |
v1.8.0
minor
Dependencies (5)
|
|
v1.7.3
patch
2 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev |
v1.7.3
patch
Dependencies (6)
|
|
v1.7.2
patch
2 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev |
v1.7.2
patch
Dependencies (6)
|
|
v0.0.2
patch
|
v0.0.2
patch
Dependencies (6)
|
|
v0.0.1
initial
|
v0.0.1
initial
Dependencies (6)
|
|
v1.7.1
minor
2 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev |
v1.7.1
minor
Dependencies (6)
|
|
v1.7.0
minor
2 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev |
v1.7.0
minor
Dependencies (6)
|
|
v1.6.7-chrome-133-fix
pre
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.7-chrome-133-fix
pre
Dependencies (6)
|
|
v1.6.7-chrome-133-support
pre
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.7-chrome-133-support
pre
Dependencies (6)
|
|
v1.6.7-go1.24
pre
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.7-go1.24
pre
Dependencies (6)
|
|
v1.6.7-chrome-131-support
pre
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.7-chrome-131-support
pre
Dependencies (6)
|
|
v1.6.7-wasm
pre
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.7-wasm
pre
Dependencies (6)
|
|
v1.6.7
patch
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.7
patch
Dependencies (6)
|
|
v1.6.6-wasm
pre
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.6-wasm
pre
Dependencies (6)
|
|
v1.6.6
patch
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.6
patch
Dependencies (6)
|
|
v1.6.5-wasm
pre
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.5-wasm
pre
Dependencies (6)
|
|
v1.6.5
patch
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.5
patch
Dependencies (6)
|
|
v1.6.4-wasm
pre
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.4-wasm
pre
Dependencies (6)
|
|
v1.6.4
patch
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.4
patch
Dependencies (6)
|
|
v1.6.3-wasm
pre
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.3-wasm
pre
Dependencies (7)
|
|
v1.6.3
patch
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.3
patch
Dependencies (7)
|
|
v1.6.2-wasm
pre
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.2-wasm
pre
Dependencies (7)
|
|
v1.6.2
patch
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.2
patch
Dependencies (7)
|
|
v1.6.1
patch
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.1
patch
Dependencies (7)
|
|
v1.6.0
minor
3 CVEs
CVE-2026-26995
GO-2026-4512
GHSA-rrxv-pmq9-x67r
Feb 24, 2026
Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from missing padding extension for Chrome 120 in github.com/refraction-networking/utls Fixed in
1.8.2
References Updated Mar 23, 2026 · Source: OSV.dev
CVE-2026-27017
GO-2026-4509
GHSA-7m29-f4hw-g2vx
Feb 24, 2026
Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fingerprint vulnerability in uTLS from GREASE ECH mismatch for Chrome parrots in github.com/refraction-networking/utls Fixed in
1.8.1
References Updated Feb 24, 2026 · Source: OSV.dev
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.6.0
minor
Dependencies (7)
|
|
v1.5.4
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.5.4
patch
Dependencies (8)
|
|
v1.5.3
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.5.3
patch
Dependencies (8)
|
|
v1.5.2
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.5.2
patch
Dependencies (8)
|
|
v1.5.1
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.5.1
patch
Dependencies (8)
|
|
v1.5.0
minor
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.5.0
minor
Dependencies (8)
|
|
v1.5.0-beta.4
pre
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.5.0-beta.4
pre
Dependencies (8)
|
|
v1.5.0-beta.3
pre
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.5.0-beta.3
pre
Dependencies (8)
|
|
v1.5.0-beta.2
pre
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.5.0-beta.2
pre
Dependencies (8)
|
|
v1.5.0-beta.1
pre
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.5.0-beta.1
pre
Dependencies (8)
|
|
v1.4.3
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.4.3
patch
Dependencies (7)
|
|
v1.4.2
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.4.2
patch
Dependencies (7)
|
|
v1.4.1
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.4.1
patch
Dependencies (7)
|
|
v1.4.0
minor
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.4.0
minor
Dependencies (7)
|
|
v1.3.3
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.3.3
patch
Dependencies (6)
|
|
v1.3.2
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.3.2
patch
Dependencies (5)
|
|
v1.3.1
minor
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.3.1
minor
Dependencies (4)
|
|
v1.2.2
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.2.2
patch
Dependencies (4)
|
|
v1.2.1
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.2.1
patch
Dependencies (4)
|
|
v1.2.0
minor
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.2.0
minor
Dependencies (4)
|
|
v1.1.5
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.1.5
patch
Dependencies (4)
|
|
v1.1.4
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.1.4
patch
Dependencies (4)
|
|
v1.1.3
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.1.3
patch
Dependencies (4)
|
|
v1.1.2
patch
1 CVE
CVE-2026-26994
GO-2025-3638
GHSA-pmc3-p9hx-jq96
Apr 24, 2025
ServerHellos are accepted without checking TLS 1.3 downgrade canaries in github.com/refraction-networking/utls 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. Fixed in
1.7.0
References Updated Feb 18, 2026 · Source: OSV.dev |
v1.1.2
patch
Dependencies (4)
|