Terrapin Attack

Due to the widespread adoption of affected cipher modes, patching Terrapin (CVE-2023-48795) is notoriously difficult. To make matters worse, "strict kex" requires both peers, client and server, to support it in order to take effect. A wide variety of SSH implementations started adopting "strict kex" since public disclosure. This site is an attempt to capture affected products, and their patched release versions (if any).

All implementations marked with an asterisk were contacted as part of our responsible disclosure. You may also find the reasoning for this selection further down below.

We advise users of Win32-OpenSSH (the SSH implementation built into Windows 10 / 11 / Server 2019 / 2022) to update their implementations to manually as Microsoft stated that they won't be delivering this update through Windows Update. While it is true that the impact on Win32-OpenSSH is limited (and obviously doesn't hit Microsoft's bar for servicing), we must stress that "strict kex" requires both peers to support it. Microsoft's decision consequently allows unknown server-side implementation bugs to remain exploitable in a Terrapin-like attack, even if the server got patched to support "strict kex".

This list may not be complete. If you find any implementation that is not listed but has released support for "strict kex", feel free to open up a PR over on GitHub.

Implementation Affected Versions Patched Version(s)
AbsoluteTelnet* 11.38 and earlier 12.11
Apache MINA SSHD* 2.11.0 and earlier 2.12.0
AsyncSSH* 2.14.1 and earlier 2.14.2
Bitvise SSH* 9.31 and earlier 9.33
ConnectBot* 1.9.9 and earlier 1.9.10
CrushFTP 10.5.6 and earlier 10.6.0
CycloneSSH* 2.3.2 and earlier 2.3.4
Dropbear* 2022.83 and earlier 2024.84
Erlang/OTP SSH* OTP 26.2 and earlier
OTP and earlier
OTP and earlier
OTP 26.2.1
FileZilla Client 3.66.1 and earlier 3.66.4
Forgejo 1.21.2 and earlier 1.21.3
Gitea 1.21.2 and earlier 1.21.3
Golang x/crypto/ssh* 0.16.0 and earlier 0.17.0
JSch (Fork)* 0.2.14 and earlier 0.2.15
Lancom LCOS* 10.80 RU1 and earlier
10.72 RU6 and earlier
10.50 RU12 and earlier
10.42 SU12 and earlier
10.80 RU2
10.72 RU7
10.50 RU13
10.42 SU13
Lancom LCOS FX* 10.13 RU2 and earlier
10.12 RU4 and earlier
10.11 RU3 and earlier
10.13 RU3
Lancom LCOS LX* 6.14 Rel and earlier
5.36 RU3 and earlier
6.14 RU1
Lancom LCOS SX* 5.20 RU6 and earlier
4.20 RU2 and earlier
Lancom LANConfig* 10.80 RU2 and earlier 10.80 RU3
libssh* 0.10.5 and earlier
0.9.7 and earlier
libssh2* 1.11.0 and earlier To be released
Maverick Legacy* 1.7.55 and earlier 1.7.56
Maverick Synergy* 3.0.21 and earlier (Hotfix)
3.0.10 and earlier (OSS)
MobaXterm 23.5 and earlier 23.6
Nova 11.7 and earlier 11.8
OpenSSH* 9.5 / 9.5p1 and earlier 9.6 / 9.6p1
Paramiko* 3.3.1 and earlier 3.4.0
phpseclib 3.0.34 and earlier
2.0.45 and earlier
1.0.21 and earlier
PKIX-SSH* 14.3 and earlier 14.4
podman 4.8.2 and earlier 4.8.3
ProFTPD* 1.3.8a and earlier 1.3.8b
PuTTY* 0.79 and earlier 0.80
Russh* 0.40.1 and earlier 0.40.2
SecureCRT* 9.4.2 and earlier 9.4.3
SecureFX* 9.4.2 and earlier 9.4.3
SFTP Gateway 3.4.5 and earlier 3.4.6
SFTPGo 2.5.5 and earlier
2.4.5 and earlier
ssh2* 1.14.0 and earlier 1.15.0
sshj* 0.37.0 and earlier 0.38.0
Tectia SSH* 6.6.2 and earlier 6.6.3
Tera Term* 5.0 and earlier
4.107 and earlier
Thrussh* 0.34.0 and earlier 0.35.1
TinySSH 20230101 and earlier 20240101
Transmit 5.10.3 and earlier 5.10.4
trilead-ssh2 (Jenkins CI) build-217-jenkins-274
and earlier
VShell* 4.9.0 and earlier 4.9.1
WinSCP 6.1.2 and earlier 6.2.2 beta
XShell 7* Build 0142 and earlier Build 0144

There are also open issues for the following SSH implementations referencing Terrapin (CVE-2023-48795). Note that listing an implementation here does not imply that Terrapin will affect the implementation. Instead, this is meant to keep track of implementations, which might implement "strict kex" in the future.

Aside from the SSH implementations marked with an asterisk, we included the following implementations, vendors, and CERTs in our responsible disclosure process. Due to the lack of proper security contacts and response, we were not able to disclose our findings to some of them.

The selection of SSH implementations contacted during responsible disclosure was based on several factors. We aimed to achieve a decent coverage of "strict kex" on public disclosure by focusing on the underlying SSH implementations. We gathered all SSH implementations listed in publicly available resources (Wikipedia SSH clients, Wikipedia SSH servers, Quendi SSH implementation comparison) as a baseline. We complemented these with potentially vulnerable implementations from our internet-wide SSH scans and some implementations that were well-known to us and not included in either of these lists. Based on this dataset, we contacted all implementations that fulfilled the following criteria:

  1. Not based on another implementation already included, or heavily modified.
  2. Supports chacha20-poly1305@openssh.com or any -etm@openssh.com algorithm.
  3. Supports SSH extension negotiation (RFC8308).