Attackers took control of more than 300 Tor exit relays in early October and used them to redirect SSH connections to servers that stole login passwords, according to a researcher who publishes as kaba and who was cited by The Hacker News. Exit relays are the last hop in a Tor circuit, where traffic leaves the network for its destination. The attackers rewrote the relays’ exit policy to allow port 22 (SSH), and kaba’s October 2 scan of Tor’s roughly 3,000 exits found 333 sending SSH to the same 12 interception servers. At the peak on October 4, the relays carrying the attacker’s policy made up 7.46% of Tor’s exit capacity, according to an analysis of public directory data posted to the tor-relays mailing list.
The interceptors presented their own host key, then connected on to the real server so the session still worked while a password typed by the user was captured. The Tor Project began flagging the relays on October 4, directory authorities voted the BadExit and MiddleOnly flags that evening, and by October 5 no relay with the attacker’s policy was left in the consensus (the list Tor clients use). The largest affected group, the Quetzalcoatl relay family, was compromised through servers running Ebury, a long-running backdoor for OpenSSH; its operator, Zimmer, said the root cause was one password reused for SSH login, sudo and a backup passphrase, stored in plaintext. How the other 58 operators’ hosts were entered is still an open question; 71 of 101 relays hosted at FranTech Solutions (the network behind BuyVM) switched to the attacker’s policy, against 13 of 9,054 hosted elsewhere.
How to check if you’re affected
Affected users are people who connected to an SSH server over Tor between October 1 and the afternoon of October 5, 2026, using a password login. To be exposed, the connection had to land on one of the hijacked exits, be intercepted, and the user had to accept the interceptor’s host key and type a password. No count of victims exists.
- If you accepted an unfamiliar or changed host key over Tor in that window, treat the password you typed as stolen: change it and check that server. Look in your
known_hostsfile for a key you do not recognize; the interception server kaba analysed used an ED25519 key with the fingerprintSHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E, though other interception servers may have used different keys. - Key-based SSH logins could not be relayed to the real server this way, because the client’s signature is tied to the individual session. Password logins are the exposed case.
- If you run servers that were reachable over SSH from Tor, or you operate a relay, check for Ebury: this version is a single setuid library file,
/usr/lib/x86_64-linux-gnu/libkeyutils.so.1.10.2, with thelibkeyutils.so.1symlink pointed at it. Package checks such asdpkg -Vanddebsumsdo not catch it. Marc-Etienne Léveillé, who co-wrote ESET’s Ebury research, said version 1.8.3 has been around since at least June 2026 and posted an updated copy of ESET’s detection script that covers it. - Turn off SSH password authentication on internet-facing servers where you can, which is the other lesson Zimmer drew from his own compromise.