Fifteen years of Tor deanonymization cases share one pattern: the onion routing held, and the Firefox build sitting on top of it did not.
Operation Torpedo and the Flash era
The first well-documented case dates to 2012. In what the FBI called Operation Torpedo, agents took control of three hidden services running from a server in Nebraska and modified them to serve visitors a small Flash application derived from the Metasploit Decloaking Engine.
The application did not attack Tor at all. It simply opened its own network connection outside the proxy settings, which meant the request travelled straight from the visitor’s machine to a government server and carried the real IP address with it.
Browser plugins were the weak point, and Tor Browser eventually stopped loading them altogether. Anything able to open a socket on its own is a potential bypass, whatever the proxy settings say.
What the 2013 payload actually collected
In August 2013, sites hosted by Freedom Hosting began serving JavaScript that exploited CVE-2013-1690, a memory flaw in Firefox 17 ESR. Mozilla had already patched it in June.
The exploit only worked against Windows users still running an outdated Tor Browser Bundle, which turned out to be enough of them.
The payload collected the machine’s hostname and MAC address and sent both, along with the public IP, over the ordinary internet to a server in Virginia. The FBI acknowledged running the operation in a court filing the following month.
At the time, Tor Browser shipped with JavaScript enabled by default, a usability choice that made the whole chain possible.
That incident changed the question most practitioners ask. Whether Tor itself is broken matters less than what the browser is allowed to execute, and current setup guides are built around that shift.
A walkthrough Gizmodo published this month, for instance, treats the security slider as step two of the setup, and the placement is deliberate: the slider decides whether a page can run code at all.
Playpen and the patch that users never installed
In February 2015 the FBI seized Playpen, a hidden service distributing child abuse material, and kept it running from government servers for roughly two weeks while a network investigative technique (NIT) was served to visitors.
Court records later showed the operation reached more than 8,000 computers in 120 countries under a single warrant.
The exploit was never published. In 2017 the Justice Department moved to dismiss a prosecution in Washington State rather than disclose the code to the defense.
What remains visible is the structure: an exploit against the Firefox engine, a payload that gathered identifying data, and a callback outside Tor.
Defense lawyers argued in dozens of cases that one warrant could not authorize searches of computers whose location was unknown, and the federal rule governing such warrants was amended in December 2016.
Tor Browser follows Firefox’s extended support release, so a fix has to land upstream, get ported, and then reach users who actually restart the application. Each step adds days, and outdated installs stay exposed for months.
November 2016 replayed the script
A JavaScript exploit found on a hidden service called GiftBox in late November 2016 targeted CVE-2016-9079, a use-after-free bug in Firefox’s SVG handling.
Researchers who took it apart noted that the payload was almost identical to the 2013 one, except that it reported back to an IP address hosted by OVH in France rather than one in Virginia.
Mozilla shipped Firefox 50.0.2 on November 30, about a day after the code became public, and Tor Browser 6.0.7 followed.
Users who had set the security slider to its highest level were never at risk, because the exploit needed JavaScript to run. Two Firefox zero-days, three years apart, ended with the same data leaving the same kind of machine.
The pattern surfaced again this summer. CVE-2026-10702, a flaw in the SpiderMonkey JIT compiler, was fixed in Firefox on June 22, 2026 and in Tor Browser 15.0.19 on July 20.
For four weeks, a proof of concept existed for a bug that the Tor-specific build had not yet closed.
The one time the network itself was the target
There is a genuine counterexample. Between January 30 and July 4, 2014, around 115 relays joined the network and injected a traffic confirmation signal into Tor’s own protocol, aimed at people who operated or visited hidden services.
At their peak they made up about 6.4% of guard capacity.
The Tor Project’s July 2014 advisory on the “relay early” attack linked the relays to Carnegie Mellon researchers whose Black Hat talk had been cancelled weeks earlier. The fix required a protocol change and a new release.
The episode shows what a network-level attack costs. It took more than a hundred relays, months of continuous operation and a signal the Tor developers could detect once they looked for it.
A browser exploit, by comparison, requires one compromised page and one visitor who has not updated.
Isolation answered what the 2013 payload asked
The Freedom Hosting payload asked the operating system three questions: the name of the machine, the address of its network card and the route to the public internet.
Every answer came from the host rather than from Tor, which is why the response that followed was architectural as much as it was a patch.
Operating systems designed around this problem take a different route. Tails forces every connection through Tor and drops anything that tries to leave another way, while Whonix splits the browser and the Tor process into two virtual machines, so a compromised browser never sees the real network interface.
Against the 2013 payload, that design would have returned an internal address and a generic hostname.
Safest mode closes the door earlier in the chain. With JavaScript disabled on every site, the 2016 exploit had nothing to run on, and the same holds for the JIT flaw patched this summer, since a JIT compiler exists only to speed up scripts.
The cost is broken layouts and missing features on some onion services, a trade most threat researchers accept once they have read the case files.
What security teams can borrow from this record
Organizations that allow Tor for threat research tend to treat Tor Browser as a research tool rather than as software with a patch cycle.
The historical record suggests the opposite approach: track Firefox ESR advisories, enforce the highest security level on analyst machines, and run the browser inside a disposable virtual machine, so that any payload reading a hostname reads a throwaway one.
Blocking Tor at the perimeter solves a different problem and often pushes analysts toward personal devices, which is the worse outcome.
Arti, the Tor Project’s rewrite of the network client in Rust, is meant to remove whole classes of memory bugs from the routing code.
The browser remains built on Firefox, and if the past fifteen years are any guide, the next unmasking will start there.
