By Xray-core, the open-source proxy tool used by millions to circumvent censorship in China, Iran, and Russia, quietly patched a critical Xray-core certificate vulnerability in February 2026 — and said nothing publicly for five months. Users who thought their traffic was protected against man-in-the-middle interception were running exposed. The full timeline surfaced this week in a detailed GitHub post-mortem, and it reached Hacker News on October 5.
What Broke and How
In January 2026, the Xray-core team removed the existing certificate pinning option (pinnedPeerCertificateChainSha256) and introduced a replacement: pinnedPeerCertSha256. Users migrated on the maintainers’ recommendation. The new option had a flaw they did not mention.
The flawed implementation always sets InsecureSkipVerify = true, which disables standard TLS certificate validation and relies entirely on the custom pinning logic. However, if ServerName is empty in the TLS configuration — which is the case in the Hysteria dialer and gRPC paths — DNSName also becomes empty, so hostname verification is skipped entirely. An attacker who can obtain any certificate from the CA you’ve pinned, or from any trusted root CA in the system store, can then successfully intercept the connection. The certificate defence has completely collapsed at that point.
The severity is rated 7.6 HIGH (CVSS v4.0). Affected versions span v26.1.13 through v26.7.10 — from January 13 to July 10, 2026. The advisory is tracked as GHSA-5wf9-h793-w73c on OSV.
The Xray-core Certificate Vulnerability Timeline
A security researcher discovered and privately reported the vulnerability on February 6, 2026. Xray-core maintainers patched it the same day. The commit message read: “simplify the code.” No security advisory was issued. No CVE was assigned. No changelog entry mentioned a vulnerability fix. No user notification of any kind.
For nearly five months, users running the affected versions had no way to know their certificate pinning was silently broken. The public advisory was only issued on July 10, 2026 — after a community member independently discovered the silent fix and forced disclosure through a GitHub Security Advisory. The fix was formally tagged in v26.7.11.
“The fix commit never called it a vulnerability,” one Hacker News commenter noted. That is the entire problem in one sentence.
Why This Is Not Just Another CVE
Certificate pinning is not a nice-to-have for Xray-core users. The VLESS protocol it implements is, by most accounts, the default tunneling protocol for people bypassing state censorship in China, Russia, and Iran. In those environments, the threat model includes network operators who hold valid CA-issued certificates and actively perform traffic interception. Certificate pinning exists specifically to defeat that attack — not as a compliance checkbox, but as protection for users operating in genuinely adversarial conditions.
The irony is difficult to overstate: the maintainers removed a working pinning option and introduced a broken replacement. Users who followed the migration path ended up less protected than before — and had no mechanism to discover this. When the flaw was reported privately and silently fixed, the appearance of security was preserved while the underlying protection was gone. Xray-core counts 41,900 GitHub stars and 3.85 million Docker container pulls. A significant number of those users were relying on certificate pinning to work as documented.
What To Do Now
If you run Xray-core, update to v26.7.11 or later immediately. Check whether your configuration uses pinnedPeerCertSha256 — if it does, and you were on any version between v26.1.13 and v26.7.10, your certificate pinning was not functioning as intended. The fix is in commit 64fada32b5b9 (PR #6472) if you want to review exactly what changed.
For certificate pinning going forward: prefer self-signed certificates over CA-issued ones. A self-signed cert pinned by its own hash gives an attacker no CA-chain attack surface. A pinned CA cert is only as useful as your confidence that no one else can get a cert from that CA — which, in a world of state-level adversaries, is not a safe assumption. The Go vulnerability database tracks this at golang/vulndb issue #6651 for dependency auditing purposes.
Silent Patches Are Not Responsible Disclosure
Silent security patches happen across open source. What makes this case worth discussing is the context: a tool specifically designed for users operating under active surveillance, where a certificate bypass can matter beyond a typical data breach scenario. When the developer knows their tool is used by people facing real interception risks and patches a certificate verification bypass with a commit message about simplifying code, the project’s reputation has been placed above user safety.
Responsible disclosure gives users time to understand what happened and update before public exploitation — but it requires actually disclosing. Five months of silence is not a strategy. It is a choice with consequences for users who had no way to make an informed decision.
