OpenSSH 10.6 disables LZ77 compression and rejects shell metacharacters in usernames to close two holes

October 6, 2026. OpenSSH 10.6 shipped, and the maintainers are upfront about it: this release deliberately breaks two behaviors that used to work. SSH compression loses its LZ77 coder and becomes less effective, and usernames containing $ or \ are now rejected on the command line. Why it matters: both breaks close a plaintext leak and a shell injection — two bug classes that AI-assisted security research has surfaced against SSH in a matter of weeks.

SSH compression was leaking plaintext

The first change targets compression. SSH can carry several things over one encrypted connection — an interactive shell, port forwarding, a dynamic SOCKS proxy. When compression is enabled, all those channels share the same compression state. Crucially, OpenSSH ships with compression off by default, so the attack only works on setups that turned it on explicitly.

That shared state is exactly the problem. Researchers Fabian Bäumer and Marcus Brinkmann of the Ruhr University Bochum demonstrated it in their paper “Crossing the Streams: SSH Plaintext Recovery via a Common Compression Context in Multiplexed Channels”. An attacker who can feed chosen plaintext into one channel, then watch the resulting encrypted traffic, can use the compression to recover secrets moving through another channel in the same session.

The leak comes from LZ77’s memory. Instead of re-encoding a byte sequence it has already seen, the algorithm points back to the earlier occurrence. Because OpenSSH shared that history across channels, attacker-controlled data could change how a secret elsewhere in the session got compressed. When a guess matched part of that secret, the traffic became slightly shorter — one more bit of information for the attacker.

The chosen fix is blunt: remove the shared dictionary entirely. The Deflate format uses LZ77 to find repeated chunks and Huffman coding to represent frequent values in fewer bits. OpenSSH 10.6 disables the LZ77 part in both ssh and sshd while keeping Huffman. Compression still works, just not as well, and OpenSSH now recommends moving compression to the application layer, where it will both perform better and stay immune to this attack.

Most interactive sessions will not notice the difference. Automated jobs that push large, compressible volumes over constrained links — backups, database syncs — will need to revisit their configuration after upgrading.

Concretely, the application-layer switch is usually painless: rsync has its own -z, tar combines with gzip or zstd before sending, and backup tools like Borg or Restic already compress and encrypt before opening the SSH session. Those who compressed at the tunnel level to save bandwidth come out ahead: application-layer compression understands the data structure, so it compresses better, and it is immune to the leak because a secret is never mixed with attacker-influenced content in a shared dictionary.

The practical exposure is larger than it looks. ControlMaster and ControlPersist are common in automation — they multiplex many sessions over one connection, which is precisely the shared-channel condition the attack requires. A jump host or a build server that both compresses and multiplexes traffic is a textbook target, even when each individual transfer looks small. Disabling compression closes the hole regardless of how many channels are in flight.

The second real-world takeaway concerns where secrets flow. SSH is often used as a transport for credentials — tokens over a dynamic SOCKS proxy, database dumps, API keys in scp transfers. Any of those, compressed and multiplexed, becomes recoverable in principle. The paper’s proof-of-concept implementations, built with Claude Code, cover all three attack scenarios, which is why OpenSSH treated the finding as release-blocking rather than a footnote.

A cousin of CRIME and BREACH

This leak is not an isolated case: it belongs to the family of compression oracle attacks, long documented against TLS. CRIME, disclosed in 2012, and BREACH, in 2013, exploited the same principle — compression shared between attacker-controlled data and secrets — to recover session cookies and authentication tokens. What changes here is the vector: SSH, a protocol long considered safe because its compression is rarely enabled.

The parallel yields a general security rule: any compression shared between influenceable content and a secret is suspect, regardless of protocol. That is why browsers disabled compression on TLS streams carrying secrets, and why OpenSSH’s recommendation — compress at the application layer, where the data is already protected elsewhere — echoes the lesson of history.

Shell metacharacters in usernames

The second change targets commands built from external input. An internal tool, a CI job, or an agent might run something like ssh "$INPUT_USER@host". That username can later end up inside ProxyCommand, Match exec, or another directive handed to the shell, where characters such as $ and \ suddenly become shell syntax instead of part of the name.

This is not the first time the project has tightened this path. Version 10.3 fixed a related bug where command-line usernames were checked too late, after they could already be expanded through ssh_config. With 10.6, $ and \ are now rejected in usernames passed on the command line. The restriction does not apply to the name set by the User directive in an SSH config file: legitimate accounts containing those characters still work that way, but scripts and agent tooling that pass them directly will have to change.

The other breaks: post-quantum keys and scp -R

Two more changes can trip up automation. The hybrid post-quantum signature algorithm ssh-mldsa44-ed25519 drops its experimental @openssh.com suffix, so keys created with the earlier implementation need to be regenerated or removed. The release also begins phasing out scp -R for remote-to-remote copies — it still works in 10.6, but now emits a warning and will eventually be ignored.

The pace is deliberate. OpenSSH sees more security research conducted with AI models, and those models are getting better at finding exploitable flaws. The project warns that adversaries who do not report what they find “are likely to be able to discover these bugs too,” and for now plans to ship fixes more often rather than wait for its usual release schedule.

What to check before upgrading

Three checks cover a typical fleet. First, find who enables compression: ssh -G <host> | grep -i compression returns the effective per-host value, and the Compression yes directive in /etc/ssh/ssh_config or ~/.ssh/config is the setting to look for. Second, audit scripts that build user@host: any username sourced from a variable, a webhook, or user input is an injection candidate, even if it does not yet contain $ or \. Third, list your post-quantum keys: ssh-keygen -l -f <key> prints the algorithm, and any ssh-mldsa44-ed25519 key created before 10.6 must be regenerated.

These checks are fast and non-destructive, and they turn a potentially breaking upgrade into a verifiable operation. For an environment that does not compress and uses no metacharacters in its usernames, the upgrade is transparent.

Verdict

If you enable SSH compression for large, compressible transfers, move it to the application layer before or right after upgrading — it is both OpenSSH’s recommendation and the protection against the plaintext leak. If your automation builds usernames from variables or external input, audit them now for $ and \: 10.6 will reject them, and letting a script break in production is the scenario to avoid. If you use ssh-mldsa44-ed25519 keys, regenerate them immediately. For everything else — interactive sessions, default configurations — the upgrade is transparent, since compression is off by default and most fleets are not exposed to the leak.

References

• The New Stack — OpenSSH 10.6 deliberately breaks two features in the name of security (October 7, 2026)
• LWN — OpenSSH 10.6 released (October 6, 2026)
• OpenSSH — Release notes
• Bäumer & Brinkmann, Ruhr University Bochum — Crossing the Streams: SSH Plaintext Recovery via a Common Compression Context in Multiplexed Channels