A Tor exit-relay campaign that Kaba dated to October 2, 2026, redirected SSH connections through 12 interception servers. In an account published October 20, the Tor volunteer said his scan found 333 affected relays among roughly 3,000 exits tested. The findings concern a portion of Tor’s exit relays.
What Kaba’s 333-relay scan measured
A Tor exit relay is the last relay in a Tor circuit, forwarding a connection to a destination outside the network. Kaba used exitmap and two test servers to check SSH host-key fingerprints and where connections appeared to come from. He reported 333 relays redirecting SSH traffic to 12 interception servers.
A separate directory-data analysis reported by The Hacker News counted 377 relays whose exit policies matched the attacker’s pattern. That measures policy matches, not scan-confirmed SSH redirects.
| Measurement | Relay count | Method | What the figure describes |
| Kaba’s SSH redirection scan | 333 | Tested roughly 3,000 exits with exitmap, checking SSH fingerprints and connection sources | Relays that redirected SSH to 12 interception servers |
| Directory-policy analysis reported by The Hacker News | 377 | Identified relays matching an exit-policy pattern in directory data | Policy matches, not proof of SSH redirection |
How the SSH route could expose a password
The reported interception targeted SSH connections leaving Tor through an affected exit relay. A server’s host key identifies the server to an SSH client. If a key the client has already seen changes, SSH warns about it; on a first connection, the user may instead see the ordinary prompt to accept a new key.
In the described attack, password theft depended on accepting the interceptor’s host key and then entering a password. Kaba reported that an interceptor presented an ED25519 fingerprint of SHA256:6baCZCPsl+AfQuujUS81fMEE/C7UeJ+AwjrImqmDB3E.
Public-key authentication works differently: the client’s signature is tied to that SSH session, so the interceptor could not simply replay it to the real server. That addresses this specific password-capture route, not other risks such as a stolen private key or malware on a user’s device.
SSH to an onion service does not pass through an exit relay. The reported risk concerned connections leaving Tor for non-onion destinations.
What the mail-port changes and Ebury findings cover
Zimmer, an operator who investigated two Quetzalcoatl servers, reported that the altered policy on two Switzerland2 relays blocked mail ports 25, 465, 587, 993 and 995 while allowing plaintext-capable POP3 and IMAP ports 110 and 143. The configuration created a potential path to downgrade mail connections; a successful downgrade or message capture has not been established.
Zimmer’s account says an attacker accessed the operator’s Contabo management server on August 28, 2026, using a reused password, and gained root access within five minutes. The same password had also been used for sudo and backup encryption, and SSH password authentication was enabled on the internet-facing management server. Zimmer reported Ebury 1.8.3 on that server and on Switzerland2. His findings cover those two hosts.
What the Tor Project told relay operators to do
On October 4, the Tor Project reported SSH interception by some compromised relay operators and said affected relays were being flagged and rejected by directory authorities. Its October 5 notice advised Linux relay operators to audit Tor configuration and host activity, including relay policies, port 22 network rules, processes, users, keys, scheduled jobs and system services.
For a suspected compromise, the Tor Project recommended taking the relay offline, preserving disks and logs, reinstalling the system, replacing the relay identity and rotating credentials present on the host. Zimmer said his two Ebury-infected servers lacked several listed indicators, including NAT redirects and modified Tor binaries; package checks did not detect the implant.
