Listen to this Post
The vulnerability stems from an incorrect removal of the padding extension in the uTLS library when generating the non-Post-Quantum (non-pq) variant of the Chrome 120 fingerprint. Real Chrome browsers implement a padding mechanism that adds extra bytes to the initial ClientHello message if its total length is less than 512 bytes. This is done to prevent network equipment from rejecting unusually small packets, a problem known as protocol ossification. uTLS, in its attempt to mimic the Chrome 120 fingerprint, failed to replicate this specific padding behavior for the non-pq version. Consequently, the ClientHello messages generated by affected uTLS versions are shorter than any genuine Chrome 120 ClientHello packet would ever be. This creates a distinct and observable fingerprint on the network. A passive observer, such as a firewall or a traffic analysis system, can simply measure the length of the TLS ClientHello packet. If it receives a packet that perfectly mimics Chrome 120’s other parameters but is under 512 bytes, it can infer with high confidence that the traffic originates from a tool using the vulnerable uTLS library, not a real Chrome browser, thus identifying it as proxy or bot traffic. The issue is specific to the `HelloChrome_120` fingerprint preset. Newer Chrome fingerprints include post-quantum key shares, which alter the packet size and structure, while older ones included the padding, making this a unique regression for this particular fingerprint version.
dailycve form:
Platform: uTLS
Version: 1.6.0 to 1.8.1
Vulnerability : Missing Padding Extension
Severity: Low
date: 2026-02-17
Prediction: 2026-02-18
What Undercode Say
Analytics
This vulnerability allows for the passive, deterministic identification of traffic using the affected uTLS fingerprint. By simply inspecting the raw length of the TLS ClientHello packet, a deep packet inspection (DPI) system can flag traffic as non-browser. The detection rate is significant:
For domain-fronted requests, the single-packet detection probability is approximately 25% for the padding bug alone.
For direct IP connections, this probability jumps to around 50%.
When combined with a previously disclosed ECH (Encrypted Client Hello) bug, the detection rate for a single connection increases to 62.5% for domain requests and 75% for IP connections.
Crucially, because a typical proxy client establishes numerous TCP connections, the cumulative probability of the user’s traffic being detected approaches 100%. The vulnerability affects `HelloChrome_120` from December 2023 to January 2026, and default Chrome fingerprints from December 2023 to May 2025.
Exploit
The “exploit” is a passive traffic analysis technique. An attacker or surveillance system does not need to send malicious packets; it only needs to observe network traffic. The following bash script using `tcpdump` and `tshark` can identify potentially vulnerable clients on a network by capturing ClientHellos shorter than 512 bytes that are masquerading as Chrome 120.
!/bin/bash Capture TLS ClientHello packets on port 443 and filter by length. Note: This identifies traffic using the vulnerable fingerprint. sudo tcpdump -i any -s 0 -c 100 -w capture.pcap port 443 Analyze the capture with tshark to find ClientHellos under 512 bytes. A successful find indicates a potential use of the vulnerable fingerprint. tshark -r capture.pcap -Y "tls.handshake.type == 1 && frame.len < 512" -V
A more targeted test using a Go program with the vulnerable uTLS version would look like this:
package main
import (
"fmt"
"github.com/refraction-networking/utls"
)
func main() {
// This uses the VULNERABLE fingerprint (uTLS < v1.8.2)
config := tls.Config{ServerName: "example.com"}
conn, _ := tls.Dial("tcp", "example.com:443", &config)
defer conn.Close()
fmt.Println("TLS connection attempted with potentially vulnerable fingerprint.")
// The resulting ClientHello packet would be under 512 bytes.
}
Protection from this CVE
Protection involves updating the uTLS library and modifying client configurations.
1. Update uTLS:
Ensure your project or dependency uses uTLS version 1.8.2 or higher, which contains the fix commit 8fe0b08e9a0e7e2d08b268f451f2c79962e6acd0.
In your Go module go get github.com/refraction-networking/[email protected]
2. Change Fingerprint:
If an immediate update is not possible, stop using the `HelloChrome_120` fingerprint. Switch to a different, unaffected fingerprint like Firefox.
// Instead of utls.HelloChrome_120 conn := tls.UClient(tcpConn, &config, tls.HelloFirefox_Auto)
3. Disable uTLS (if applicable):
Some projects, like Xray-core, allow disabling uTLS fingerprinting as a temporary measure, though this may impact other functionality like Reality.
Impact
The primary impact is the loss of anonymity and bypass capabilities for tools relying on uTLS for censorship circumvention or web scraping. Traffic that was intended to blend in with normal Chrome browsers becomes trivially identifiable by sophisticated firewalls like the Great Firewall of China (GFW). This can lead to:
Blocking of proxy traffic: Connections are reset or throttled, rendering the proxy useless.
User identification: The source IP addresses of users employing vulnerable tools can be cataloged with high confidence.
Automation failure: Web scrapers and bots that depend on uTLS to avoid fingerprinting will be detected and blocked by target websites.
Long-term exposure: Users and software that have not updated since late 2023 have had their traffic potentially exposed and logged for over two years.
🎯Let’s Practice Exploiting & Learn Patching For Free:
Sources:
Reported By: github.com
Extra Source Hub:
Undercode
