Tor Browser 15.0.6 Ships New Circuit Encryption

Tor Browser 15.0.6 dropped on February 16, 2026, and if you are running anything older, you are carrying a high-severity vulnerability in your video codec and you are missing the single largest cryptographic upgrade to Tor relay encryption since the protocol launched in 2003.

The headline fix is CVE-2026-2447, a heap buffer overflow in libvpx, the library Firefox uses to decode VP8 and VP9 video. Security researcher jayjayjazz found it, Mozilla rated it high-severity, and the practical impact is that a malicious website serving crafted video content could execute arbitrary code on your machine. The patch lands via Firefox ESR 140.7.1, which serves as the base for this release across Windows, macOS, and Linux.

Now the bigger story is underneath that Firefox patch. Tor Browser 15.0.6 bundles Tor 0.4.9.5, the first stable release in the 0.4.9.x series, and it ships two features that fundamentally change how the network operates: Counter Galois Onion encryption and Happy Families relay management.

Ok so CGO matters because of how Tor circuits have worked since the very beginning. Every circuit has used a relay encryption scheme internally called "tor1" that relies on AES-CTR with no hop-by-hop authentication, and the only authentication it had was a 4-byte SHA-1 digest giving attackers a one-in-four-billion chance of forging a valid cell. That sounds like a big number until you look at the real vulnerability, which is malleability, meaning an attacker who controls a relay on your circuit can XOR a pattern into the encrypted cell at one end, watch for that same pattern to appear at the other end, and if it does, they have just confirmed they control both points of your circuit. That is a tagging attack, and it has been a known weakness in Tor's design for years.

Counter Galois Onion, designed by cryptographers Jean Paul Degabriele, Alessandro Melloni, Jean-Pierre Münch, and Martijn Stam, eliminates this class of attack entirely. CGO uses a construction called a Rugged Pseudorandom Permutation built on top of UIV+, and the practical effect is that any modification to any bit of an encrypted cell makes the entire cell and every subsequent cell on that circuit unrecoverable garbage. An attacker who tries to tag a cell gets nothing back because the wide-block encryption ensures that tampering destroys the entire message rather than producing a predictable output.

CGO also delivers immediate forward secrecy by destroying decryption keys after every single cell, so even if an adversary compromises your current keys, they still have zero access to any traffic that already passed through the circuit. The old tor1 scheme kept the same AES keys for the entire lifetime of a circuit, which meant that a key compromise at any point exposed everything that ever traversed it. The authentication upgrade matters too because CGO replaces that 4-byte SHA-1 digest with a 16-byte authenticator using modern cryptography, making forgery computationally impractical rather than merely unlikely.

The cost of all this is computational overhead. Building a wide-block cipher that prevents tagging attacks requires at least two passes over the data, and the Tor blog notes that such designs generally need on the order of 6 encryptions and 6 hashes per cell on a 3-hop circuit compared to tor1's 3 encryptions and 1 hash. CGO uses a Rugged Pseudorandom Permutation instead of a full Strong Pseudorandom Permutation, which gives it a performance edge over those generic constructions while maintaining the same security guarantees. Optimization work continues in both the C codebase and Arti, Tor's Rust implementation.

The second major feature in Tor 0.4.9.5 is Happy Families, implementing proposal 321 and completely overhauling how relay families declare themselves on the network. Relay families exist to prevent an honest operator's relays from appearing in the same circuit, which would create a traffic correlation opportunity. The old system required every relay in a family to list every other relay in its configuration, creating an O(N-squared) scaling problem where 85% of all microdescriptor space was consumed by family declarations alone. Happy Families replaces those massive lists with a shared cryptographic key that proves family membership through a signed certificate, making microdescriptor downloads approximately 80% smaller once enough relays and clients adopt the new system. Once legacy family lists and old TAP onion keys are fully deprecated, microdescriptors shrink to roughly 25% of their current size, which means the total data needed to bootstrap a fresh Tor connection will fall to about half of what it is today.

Beyond the headline features, this release includes NoScript 13.5.13.1984, an updated Go toolchain at version 1.24.13 for Windows, Linux, and Android builds, and fixes for an issue where metamask.io failed to load on the Safer security level due to WASM blocking that was propagating into web workers when it should have stayed contained to the main thread.

From what I found looking at the full 15.0.x release history, this update sits in an interesting spot because the previous release, 15.0.5, was an unscheduled patch to fix Vietnamese text that had been vandalized by a malicious contributor in the Android translations, which shipped in 15.0.4. That incident prompted the Tor Project to review their translation acceptance process, and while the vandalized text had zero security impact, it highlighted a recurring problem across the entire Tor ecosystem: verifying that the entities participating in your system are legitimate, which is exactly the kind of trust problem Happy Families addresses for relay operators.

The 15.0.x series is also the last to support x86 Linux, x86 Android, and Android versions 5.0 through 7.0. When Tor Browser 16.0 arrives around mid-Q3 2026 based on Firefox ESR 153, those platforms get cut, and the alpha channel already moved to Firefox Rapid Release instead of ESR starting with Tor Browser 16.0a1, which means faster feature delivery at the cost of less testing time.

Go update, because the libvpx vulnerability alone justifies it and you get a completely rebuilt cryptographic foundation on top of that.