VLESS Vulnerability Exposed by Researcher | Generated by AI
Question: What is the GitHub repository Anonymous376c1d0cf28/VLESS-cracker?
Answer:
Overview
This is a GitHub repository created by an anonymous network security professional who claims to have discovered a critical vulnerability in the VLESS/XTLS/REALITY proxy protocol — a popular censorship-circumvention (VPN-like) protocol used mainly in China to bypass the Great Firewall (GFW).
Background: What is VLESS/XTLS/REALITY?
VLESS, XTLS, and REALITY are a family of anti-censorship proxy protocols developed by someone in the community known as RPRX. They are widely used by people in China to bypass internet censorship. RPRX has long claimed these protocols are superior to alternatives like Shadowsocks (SS), Trojan, Hysteria2, etc., and has been very vocal and aggressive in promoting them.
What the Repository Claims
The anonymous author — a self-described network security professional active since around 2010 — makes several serious allegations:
1. A Fatal Detection Vulnerability
The author claims they discovered, in under 10 minutes, a flaw in the VLESS/XTLS/REALITY protocol that allows the traffic to be detected with ~100% accuracy and very low false positive rates. This is far worse than other mainstream circumvention protocols, which can only be probabilistically detected by the GFW.
The critical implication: if a protocol’s traffic can be precisely identified, the user’s IP address and physical location can also be precisely identified — a massive personal security risk.
2. Technical Criticism of the Protocol Design
- Forward Secrecy: The author argues that RPRX falsely presents TLS-inherited forward secrecy as a unique innovation of REALITY, when it’s a standard property of all TLS-based protocols (Trojan, Hysteria2, etc.).
- Obfuscation (“TLS in TLS”): RPRX claims traditional TLS proxies have detectable “TLS in TLS” patterns. The author argues this characteristic is too weak to be used as a reliable detection signal in practice, and there is no evidence GFW actually uses it.
- The Backfire: By introducing a dual-stack TLS architecture to solve these “problems,” the author argues RPRX accidentally turned a weak, probabilistic fingerprint into a strong, deterministic one — making REALITY easier to detect, not harder.
3. Community and Ethical Criticism
- RPRX is accused of years of aggressive, bad-faith attacks on other protocol developers and projects.
- RPRX is accused of promoting fear around other protocols via fabricated or exaggerated threats to drive users to his own protocol.
- The author also notes RPRX has commercialized through NFTs, tokens, and VPN vendor sponsorships.
- This behavior is compared to the earlier “ShadowsocksR” era, where a similar pattern led to the original Shadowsocks author being questioned by authorities.
The Ultimatum / Disclosure Timeline
The author issued a 3-day ultimatum (deadline: UTC+8, May 11, 2026, 15:00):
- If RPRX publicly apologizes to the open-source community and retracts irresponsible past statements, the author will disclose the vulnerability privately to allow a fix.
- If RPRX does not apologize, the author will publicly release a Proof-of-Concept (PoC) exploit code in this repository that can:
- Be deployed on a router or sidecar network node
- Identify VLESS/REALITY proxy traffic in under 1 minute
- Extract both the client and server IP addresses
The author also advises current VLESS/REALITY users to migrate to other protocols immediately during this window.
Summary Assessment
| Aspect | Details |
|---|---|
| Type | Vulnerability disclosure / community call-out |
| Target | VLESS/XTLS/REALITY censorship circumvention protocols |
| Claimed Severity | 100% traffic detection accuracy — catastrophic for user anonymity |
| Current Status | Ultimatum issued; PoC not yet released (as of May 9, 2026) |
| Author | Anonymous network security researcher |
Important Note
This repository is politically and technically contentious. The vulnerability has not yet been independently verified by third parties, and no PoC code has been released at this time. Users of VLESS/REALITY-based proxies should monitor this situation closely and consider the author’s advice to evaluate alternative protocols.
References: