Hijacked Tor Exit Relays Captured SSH Passwords From Users Logging In

A Tor exit relay SSH hack quietly turned hundreds of volunteer-run servers into interception points in early October 2026. Anyone who logged into a Linux server over Tor and typed a password during that window may have handed it to the attackers. Researcher kaba published the investigation on October 20, but the Tor Project had already removed the affected relays by October 5, according to CyberInsider.

The first clue was an ordinary warning. On October 2, an SSH connection routed through Tor reported that the destination server's identity had changed. Alerts like that are easy to click past, and this one led investigators to a campaign that reached about one exit relay in ten.

How the Tor exit relay SSH hack worked

Tor sends traffic through a chain of volunteer-run relays. The final hop, called the exit relay, is where traffic leaves the network and reaches the public internet. A malicious exit can therefore see or alter anything that is not encrypted end to end.

SSH normally guards logins through host-key verification. The first time you connect to a server, your client records its key, and later connections should match it. Researchers who studied malicious Tor exits in a 2014 arXiv paper on Spoiled Onions warned that an attacker could run a man-in-the-middle attack against SSH, and that a changed host key is the warning sign. The weak points are a user's first connection to a new server and a user who accepts a changed key anyway.

Kaba tested about 3,000 Tor exit relays. About a dozen returned a wrong SSH host key, and more than 300 forwarded connections through the same interception infrastructure, as Cybersecurity News reported. Traffic from affected relays went to one of 12 interception servers, which presented fake host keys. SC World described the same setup.

The attackers also changed relay configuration files. A secondary report from fzaoint.org says they opened port 22 on relays that had blocked SSH, and converted some non-exit relays into exits. That site also puts the count of port 22 openings at 342 relays and the count of converted non-exit relays at 24. It adds that the campaign closed encrypted mail ports and opened unencrypted IMAP and POP3 ports on most affected relays. Because that site is less established than the others, its exact figures need confirmation.

The interception system did more than listen. It could relay commands to the real server while opening a second connection to install the Ebury Linux backdoor, according to CyberInsider.

Timeline and scale of the Tor relay intercepts

The reported numbers vary by source. The table below lists the dates that appear consistently across reports and flags the figures that rest on a single site.

The scale is still large. The researcher counted 333 relays, and other coverage cites more than 300. By one count, roughly one in ten of the approximately 3,000 exit relays were involved. Most Tor users do not pick their exit relay, so a compromised exit can catch anyone whose circuit happens to run through it.

Why password logins were the real exposure

Key-based authentication was not the weak point. The attack worked against users who accepted the substituted key and then logged in with a password. Those passwords went straight to the attackers.

That distinction matters for anyone who still allows password logins on servers they run. A stolen password works anywhere the same credential is reused. A private key never leaves the client, so a captured login is far less useful to an attacker. Switching to keys also gives you a stronger signal, because a changed host key can then be treated as a hard stop rather than a prompt to click through.

Ebury backdoor and what investigators found

Investigators found that attackers had gained access to the underlying Linux servers in August and installed Ebury 1.8.3. The reports describe it as an OpenSSH backdoor and credential stealer. Ebury is a long-running Linux backdoor, and a separate report cited in the coverage says it infected more than 400,000 Linux servers in earlier campaigns.

That history changes the response. A password change closes one door, but a backdoor on a server can survive it. Administrators should look for unexpected processes and modified SSH components. The advice in the reports is to reinstall compromised hosts from scratch rather than clean them in place.

The available reporting does not name a threat actor, so there is no public attribution to tie this campaign to a known group.

What to do if you logged in over Tor

If you used SSH over Tor between October 1 and 5, 2026, work through these steps:

• Make a list of every server you reached over Tor during that window.
• If you saw a new or changed host key and typed a password anyway, treat that password as exposed. Change it on the server and anywhere else you used it.
• Rotate SSH keys and any other secret you typed into those sessions, including API tokens. Teams that have dealt with a similar scramble can compare notes with our Railway breach coverage.
• Check the servers you logged into for the Ebury backdoor or unexpected processes, or ask an administrator to do it.
• Switch to key-based authentication, disable password logins where you can, and verify host fingerprints through a separate channel before you accept them.

If you run a Tor relay, the advice is to audit your system, reinstall any compromised host from scratch, rotate all credentials and review your SSH policies. Operators who manage hosted infrastructure may also want to read about the Zeabur breach, which exposed accounts and led to a platform shutdown.

Who is exposed and what remains unknown

The affected group is broad. It includes US developers, system administrators, researchers, journalists and privacy-focused users who connected to Linux servers over Tor between October 1 and 5, 2026, using a password. No count of American victims has been published.

Several gaps remain. Reporting has not established how many users were actually intercepted, or whether attackers used any captured passwords. It does not say whether US government or enterprise systems were affected. It also does not say whether the attackers still control other relays.

Because the counts differ between reports, readers who need exact figures should check the Tor Project's own advisory before repeating them.

What to watch next in the Tor relay investigation

The next useful signals will come from the researcher and the Tor Project. A fuller technical account could confirm the relay counts, identify which servers were compromised and show whether the interception infrastructure is still running. Any Ebury samples that surface in new campaigns would show whether the operation is still active.

For SSH users, the lesson predates this campaign. A changed host key is a warning, not a formality, and the safest response is to stop, verify the key through another channel and avoid sending a password until you have.