CVE-2026-77638: состояние гонки на rendezvous point может позволить злонамеренному реле выдавать себя за ваш onion-сайт
A quietly serious vulnerability landed in the advisory databases on August 20, 2026: CVE-2026-77638, a race condition in C Tor that could let a malicious rendezvous point impersonate the very onion service a client was trying to reach. The fix ships in Tor 0.4.9.11, and with the 0.4.8 series scheduled to stop working on the network entirely after September 1, there has rarely been a clearer case for updating immediately.
What the bug actually is
According to the GitHub advisory database entry, Tor before 0.4.9.11 is prone to a race condition in which, in just the right circumstances, a rendezvous point could man-in-the-middle the onion service that the client was trying to reach. The weakness is classified as CWE-362, an improper synchronization between concurrent operations, and carries a CVSS v3 score of 8.9 out of 10, rated High severity. Two details matter when weighing real-world risk. First, the attack complexity is rated High: the attacker needs to win a narrow timing window, which is why this stayed theoretical rather than becoming a routine exploit. Second, the scope is marked as Changed with High ratings for both confidentiality and integrity, meaning that if the race is won, the attacker does not merely observe traffic but can fully substitute content as if they were the legitimate service.Why the rendezvous point sits in a sensitive spot
Every onion service connection passes through a rendezvous point chosen by the client. The service builds a circuit to that relay and hands over the session, and from that moment the rendezvous point relays cells in both directions without being able to read them, because end-to-end encryption between client and service protects the payload. The design assumes the rendezvous point is untrusted but honest about its role: it forwards opaque blobs, nothing more. The CVE breaks that assumption at the seam where the circuit gets stitched together. If two handshake steps complete in an unexpected order, a rendezvous point acting in bad faith can insert itself into the path instead of shuffling ciphertext back and forth. In practice that turns a component the protocol deliberately treats as disposable into a full interception position against one specific client connection. Operators who want a refresher on how introduction points, descriptors, and rendezvous relays fit together can revisit our earlier coverage of the onion service handshake.The 0.4.8 deadline makes patching non-optional
The timing compounds the urgency. The Tor Project announced in June that it intends to actively stop compatibility with 0.4.8 and earlier C Tor versions after September 1, 2026 (Tor Project blog). Unlike a normal end-of-life, where old versions simply stop receiving patches, this sunset means those versions will no longer function on the network at all. The change clears out obsolete directory fields such as TAP onion keys so clients can bootstrap faster and so the Rust-based Arti implementation can move forward. For onion service operators the arithmetic is simple: any service still pinned to 0.4.8 on September 1 goes dark regardless of whether it was ever exposed to CVE-2026-77638, and every version below 0.4.9.11 within the supported series remains vulnerable to the race condition. Upgrading to 0.4.9.11 or later resolves both problems in one restart. After you update, confirm your descriptor is publishing and your introductions are landing with our onion status checker, since a botched package upgrade often shows up first as a site that looks online locally but resolves nowhere.A network recentralizing around cheap hosting
The advisory arrives during a broader conversation about where the network's trust actually lives. Speaking at DEF CON 34 in Las Vegas, Tor Project cofounder Roger Dingledine argued that centralization, not surveillance, is now the network's biggest structural threat. Cheap virtual private servers have made running a relay effortless, and operators cluster on the same few providers. As Dingledine put it: "Everybody's like, I'll run mine on Hetzner also, and then suddenly Hetzner is 20% of the Tor network" (Network World). That concentration interacts uncomfortably with bugs like this one. A race-condition attack requires controlling a relay positioned in the right place at the right moment, and every relay that shares a provider, a jurisdiction, or a subpoena channel with its neighbors shrinks the diversity the protocol relies on. Load-balancing algorithms that favor fast European relays make the feedback loop worse: the network optimizes for speed while drifting away from its original goal of spreading traffic across many jurisdictions.Practical steps for operators and users
For service operators the checklist is short:- Upgrade C Tor to 0.4.9.11 or later before the September 1 cutoff.
- If your host bundles Tor as a dependency, verify which version it actually ships rather than trusting the package name.
- Diversify infrastructure where possible; if you run OnionBalance backends, avoid placing all of them on one provider.