Attackers hijacked 333 Tor exit relays in early October and redirected SSH connections through 12 interception servers, creating a narrow but serious opportunity to steal passwords from users who connected through the Tor network. The findings were reported by a researcher known as kaba, who scanned roughly 3,000 Tor exits with exitmap on October 2 and alerted the Tor Project’s network health team.
The campaign relied on unauthorized changes to relay configuration files. The attackers enabled SSH traffic on 342 relays that had previously blocked port 22 and turned 24 non-exit relays into exits. A separate analysis of public Tor directory data identified 377 relays operated by 59 organizations that advertised the same exit policy, although that match is evidence of coordinated configuration changes rather than proof that every host was compromised. At its peak, the affected relays represented 7.46% of Tor’s exit capacity.
Users were exposed only if they connected to an SSH server through Tor between October 1 and the afternoon of October 5, reached an affected exit, accepted the interceptor’s host key and authenticated with a password. The interception server could then relay the session to the intended destination while capturing the credential. Public-key authentication could not be relayed in the same way because SSH signatures are bound to an individual session. Users who accepted an unfamiliar or changed key during that period should treat the associated password as compromised and rotate it, along with any credentials reused elsewhere.
The Tor Project began flagging the relays on October 4, and directory authorities applied BadExit and MiddleOnly protections before rejecting affected relays from the network. The project’s operator guidance, circulated through the tor-relays mailing list, tells administrators to inspect torrc and included files for unexpected ExitPolicy, ExitRelay, ContactInfo, MyFamily or Nickname changes, as well as unauthorized NAT rules, processes, users, SSH keys, cron jobs and systemd units.
In one documented case, a compromised relay host contained Ebury 1.8.3, a Linux OpenSSH backdoor and credential stealer. The implant was disguised as a setuid libkeyutils library and survived a reboot; its version was newer than the indicators in ESET’s earlier public detection material. Operators who find evidence of compromise should take the relay offline, preserve forensic data, rebuild rather than clean the host, generate new relay identities and rotate every credential and key stored there. The Tor Project forum post recommends checking from rescue media or an offline disk image where possible. No CVE, CVSS score, public proof of concept or confirmed threat-actor attribution has been associated with the incident; the attacker’s identity remains unknown.
