Most of the vulnerabilities that make headlines are implementation bugs, one project's mistake in one function. CVE-2023-48795, the Terrapin attack, is rarer and more interesting: a flaw in the SSH transport protocol specification itself, which meant it affected essentially every SSH implementation at once. It is the first practically exploitable prefix-truncation attack against SSH, and the NVD rates it CVSS 3.1 5.9 (Medium). That medium score is appropriate, Terrapin is not a one-shot remote code execution, but it undermines the integrity guarantee that SSH users take for granted, and fixing it required coordinated changes across the entire ecosystem.
Timeline and impact
Researchers Fabian Bäumer, Marcus Brinkmann, and Jörg Schwenk at Ruhr University Bochum disclosed Terrapin on December 18, 2023, with a paper, a project site, and a detection tool released simultaneously. Because the root cause was in the protocol, the coordinated response spanned many vendors: OpenSSH, PuTTY, libssh, and numerous other implementations shipped fixes in lockstep.
The practical impact depends on what an active person-in-the-middle can strip from a connection. In the general case, Terrapin lets an attacker downgrade the connection by deleting the extension-negotiation message, which can disable security features that were negotiated during the handshake, for example turning off keystroke-timing countermeasures that defend against traffic analysis of typed passwords. In some third-party implementations the consequences were more serious, including flaws that combined with Terrapin to enable authentication bypass. The attack requires an active network position between client and server, which raises the bar, but on untrusted networks that position is achievable.
Root cause
SSH protects the integrity of its encrypted channel using message authentication that incorporates a per-message sequence number. The subtle problem is where the sequence counter starts: it begins counting during the initial, unencrypted handshake, before the secure channel is fully established.
An active man-in-the-middle exploits this in two steps. First, during the unencrypted handshake, it injects a number of ignorable messages (SSH_MSG_IGNORE packets, which are valid and simply discarded). Second, once the key exchange completes and encryption begins, it deletes exactly the same number of messages from the start of the secure channel. Because the injected and deleted counts match, the sequence numbers on both ends still line up, so the message authentication does not detect that anything is missing. The attacker has effectively truncated the beginning of the secure conversation without tripping the integrity check. The two SSH modes that made this practical are the ChaCha20-Poly1305 cipher (chacha20-poly1305@openssh.com) and Encrypt-then-MAC (-etm@openssh.com) when used with a CBC cipher.
The fix, called "strict key exchange" (strict kex), changes the handshake so that the sequence numbers are reset after the first key exchange and so that no unexpected non-handshake messages are tolerated during the handshake, which removes the attacker's ability to silently inject and later delete messages.
Which implementations were affected
Because Terrapin is a protocol-level flaw, it affected OpenSSH before 9.6 and a broad set of other SSH software, including PuTTY, libssh, and many embedded and commercial SSH stacks, whenever a vulnerable mode (ChaCha20-Poly1305 or CBC-based Encrypt-then-MAC) was negotiated. Both endpoints must support strict kex for a connection to be protected, so a patched client talking to an unpatched server (or vice versa) can still be vulnerable.
Detection
- Use the Terrapin vulnerability scanner published by the researchers, which safely probes a client or server to determine whether it negotiates a vulnerable mode and whether it supports strict kex.
- Inventory your SSH software everywhere it runs: servers, jump hosts, developer machines, CI runners, network appliances, and any application that embeds an SSH library.
- Check both ends. Protection requires strict kex support on both client and server, so a scan of servers alone is incomplete.
- Review negotiated algorithms; connections using ChaCha20-Poly1305 or CBC-based Encrypt-then-MAC are the ones the attack targets.
Remediation and patched versions
Update OpenSSH to 9.6/9.6p1 or later, which implements strict kex, and update every other SSH implementation to the release that added strict-kex support (PuTTY, libssh, and others published fixes in the same December 2023 window). Since both endpoints must support strict kex, patch clients and servers together rather than one side in isolation.
As a defense-in-depth measure independent of patch level, you can disable the specifically affected algorithms in your SSH configuration, removing the ChaCha20-Poly1305 cipher and the CBC-based Encrypt-then-MAC MACs so a vulnerable mode is never negotiated. This is useful for endpoints you cannot immediately patch, but it can affect interoperability, so the primary remediation remains upgrading to versions that support strict kex.
How Safeguard helps
Terrapin is easy to miss in an inventory because SSH is everywhere and often embedded: a vulnerable libssh or SSH client library can be buried deep in an application's dependency tree or a container image, far from the obvious OpenSSH daemon. Safeguard's software composition analysis resolves those transitive and vendored SSH libraries and flags versions that predate the strict-kex fix, so you find the copies you did not know you shipped. Container scanning surfaces vulnerable OpenSSH and SSH libraries baked into image layers, and when a patched release exists, autonomous auto-fix opens a tested pull request to move you to it. Developers can run the same checks locally with the Safeguard CLI before code ever lands, and policy gates can hold back an artifact that ships a known-vulnerable SSH component.
Protocol-level flaws touch everything at once, complete inventory is how you make sure nothing is missed. Get started free or read the documentation.
Frequently Asked Questions
How serious is the Terrapin attack really?
Its CVSS 3.1 score of 5.9 (Medium) is a fair reflection: Terrapin is not a one-shot remote code execution, and it requires an active man-in-the-middle position between client and server. What it does is undermine SSH's integrity guarantee, letting an attacker silently truncate the start of the secure channel and downgrade negotiated security features. In some third-party implementations it combined with other flaws for more serious outcomes, so it is worth fixing everywhere even though it is not a critical-severity bug on its own.
Which SSH versions fix CVE-2023-48795?
Update OpenSSH to 9.6/9.6p1 or later, which introduced "strict key exchange." PuTTY, libssh, and many other implementations shipped strict-kex support in the same December 2023 coordinated disclosure. Because the flaw is in the protocol, both the client and the server must support strict kex for a given connection to be protected, so patch both ends rather than assuming one side is sufficient.
Which SSH algorithms does Terrapin target?
The attack is practical against the ChaCha20-Poly1305 cipher (chacha20-poly1305@openssh.com) and against Encrypt-then-MAC (-etm@openssh.com) when it is used with a CBC cipher. As a stopgap on endpoints you cannot patch immediately, you can disable these specific algorithms so a vulnerable mode is never negotiated, though upgrading to versions that support strict kex is the durable fix.
Do both the client and server need to be patched?
Yes. Strict key exchange is negotiated, so a connection is only protected when both the client and the server support it. A patched client connecting to an unpatched server, or a patched server accepting an unpatched client, can still negotiate a vulnerable mode. That is why an inventory limited to servers is incomplete, developer machines, CI runners, jump hosts, and embedded SSH clients all need to be updated as well.