For five days in early October, 333 Tor exit relays were under someone else's control. They were used to redirect SSH connections to 12 interception servers and to push email onto plaintext ports. The Tor Project had them out of the consensus by the afternoon of 5 October, but the window was long enough that anyone who logged into an SSH server over Tor with a password and accepted a changed host key should assume that password is compromised.
The scale is what makes this one stand out. Tor has roughly 3,000 exits, so 333 is about a tenth of them. At the peak on 4 October, the relays carrying the attacker's exit policy made up 7.46% of Tor's exit capacity by consensus weight. That is not a misconfigured relay here and there. It was a coordinated takeover of a meaningful slice of the network's boundary.
What a hijacked exit can actually see
An exit relay is the last hop in a Tor circuit, where traffic leaves the network for the open internet. It knows the destination and it carries the traffic, but it does not know where the connection came from. That is the whole point of Tor. It also means the exit is the one place where the anonymity layer stops and ordinary network security starts.
Encrypted web traffic was not made readable. HTTPS stayed HTTPS, and the attackers did not get a magic window into TLS sessions. The damage was narrower and more specific. The compromised exits rewrote their exit policies to allow port 22, the SSH port, including on 342 relays that had previously blocked it. Another 24 relays that were not exits at all were turned into exits.
When someone connected to an SSH server through one of those exits, the connection went to an interception server instead. That server presented its own host key. If the user had connected before, OpenSSH showed the familiar "remote host identification has changed" warning. If it was a first connection, it showed the usual prompt to accept a new key. Anyone who accepted the key and typed a password handed it over. The interceptor then connected to the real server, so the session worked and the user had no obvious reason to be suspicious.
Key-based logins were not exposed in the same way. Under the SSH authentication protocol, the client's signature is tied to a unique session identifier, so a signature made for the interceptor is useless against the real server. The interceptor could accept a key login and show a fake shell, but it could not use that key to reach the real host. Passwords were the weakness, and only password logins made through Tor in that window, after accepting the key, were at risk. There is no public count of victims.
Email was the other target. The same policy rewrite closed the encrypted mail ports, IMAPS and POP3S, and on most relays opened the plaintext-capable ones, POP3 and IMAP. A Tor client only picks an exit that allows the destination port, so those relays stopped carrying encrypted mail and started carrying plaintext mail. Why the encrypted ports were closed is not visible in the public data. The effect is easy enough to guess.
How the relays were taken
The compromise did not start with a Tor exploit. It started with a reused password. On 28 August, someone logged into the Quetzalcoatl relay family's management server at Contabo using the operator account's password on the first try, had root within five minutes, and installed Ebury, an OpenSSH backdoor and credential stealer that has been around since 2009. A little over an hour later the same access reached a FranTech VPS called Switzerland2, which ran two of the exits.
The operator, Zimmer, published a post-mortem. The root cause was his: one password reused for SSH login, sudo and the backup passphrase, stored in plaintext on both servers, with SSH password authentication left enabled on an internet-facing management server. The family's supposed offline master keys were not offline either. Copies sat in the workstation backup on the management server, encrypted with the password the attacker already had.
The implant was a single setuid library file, /usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, with the libkeyutils.so.1 symlink pointed at it. The packaged library was untouched, so package verification tools did not catch it, and sshd, sudo and PAM passed their checks. It survived a reboot. Ebury's backdoor logins left no record, which is how the exit configurations were rewritten without a login, sudo command or cron job in the logs. On Zimmer's two relays the attacker's policy stayed live for about 52 hours, moving roughly 3.4 TiB a day.
The wider pattern points to one actor with access to a lot of hosts. Directory data counted 377 relays run by 59 operators that switched to the attacker's exit policy between 1 and 4 October. That is a policy match, not proof that every one of those hosts was compromised, but 40 relays belonging to 21 operators changed within five and a half minutes on 1 October, most by a configuration reload. That looks like one hand on the switch. The geographic concentration is also hard to ignore: 71 of the 101 affected relays hosted on FranTech Solutions, the network behind BuyVM, switched policy, against 13 of 9,054 hosted elsewhere.
How the other 58 operators were breached is still the main open question. A compromised hosting provider, or a login from a host already running Ebury, are the leading theories. Ebury has infected an estimated 400,000 servers since 2009, according to ESET, so there is no shortage of possible upstream infections.
The cleanup
The researcher who publishes as kaba found the problem on the morning of 2 October, when an SSH connection over Tor returned a changed-key warning. He used exitmap to test every exit in turn and found 333 redirecting SSH to the same 12 interception servers. He reported it to the Tor Project's network health team that evening.
The health team was already seeing the policy change in its own monitoring. On 4 October it contacted Zimmer, who confirmed the change was not his and asked for the relays to be marked bad. Directory authorities began voting the BadExit and MiddleOnly flags at 18:00 UTC, and the flags were in the consensus by 21:00. By 17:00 UTC on 5 October, no relay with the attacker's policy was in the consensus. Forty-one relays were still publishing it on 9 October, but they were not listed, so clients were not using them.
Tor Metrics' exit count fell by about 370 between 3 and 5 October and had not recovered by 18 October. The Tor Project's notice to operators asks them to check Relay Search for an exit flag or policy they did not set, and to inspect torrc and included files for changed ExitRelay, ExitPolicy, ContactInfo, MyFamily or Nickname lines. It also lists NAT rules on port 22, unknown processes, new users, authorized_keys entries, cron jobs, systemd units and a tor binary that fails its package check. Zimmer's servers showed none of those host-level signs. A clean check does not rule this out.
If you used SSH over Tor that week
The exposure window is 1 to 5 October. If you connected to an SSH server over Tor in that period, landed on one of the hijacked exits, accepted an unfamiliar or changed host key, and logged in with a password, treat that password as stolen. Change it, and check the server for the Ebury indicators in the Tor Project notice and Zimmer's post-mortem. An OpenSSH client that accepted the key saved it in known_hosts, so you can check what you accepted.
Do not type a password into a server you suspect while checking it. Ebury captures it. Log in with a key, or inspect the disk from a rescue system or an offline image. Zimmer's advice for getting past the userland rootkit is to start a shell with H=1 I=1 LD_PRELOAD=":" LD_DEBUG=":" bash before running detection scripts. Reinstalling matters because the implant survived a reboot on his server.
What it means
This is not evidence that Tor is broken. It is evidence that an exit relay is a trust boundary, and that the people running exits are volunteers with varying security practices. Tor hides where you came from. It does not make the server on the other end trustworthy, and it does not protect a password from the machine terminating the connection.
The practical lessons are old ones. Use key-based SSH authentication. Pay attention to host-key warnings instead of clicking through them. Keep mail encrypted end to end rather than relying on the port. And treat a relay operator's security as part of your threat model, because in this case a single reused password on a management server was enough to put a tenth of the exit capacity under someone else's control.
The Tor Project is also moving on the structural side. Its 2026 exit-relay lifecycle proposal adds a staging period for new exits specifically to raise the cost of this kind of takeover and create more chances to catch it early. That will not stop a compromised host, but it narrows the window in which a fresh exit can be useful to an attacker.