CVE-2023-48795

What it actually does

This flaw is a protocol-level weakness in SSH transport negotiation, commonly known as the Terrapin attack. A network-positioned attacker can manipulate SSH handshake sequence numbers so that selected early handshake packets, especially SSH extension negotiation messages, are omitted without being detected by the client or server. When vulnerable implementations negotiate affected algorithms such as chacha20-poly1305@openssh.com or CBC ciphers with Encrypt-then-MAC MACs, the attacker may downgrade or disable negotiated security features. The issue does not directly provide authentication bypass, command execution, or credential theft, but it can weaken the integrity guarantees of the SSH session and remove protections that later parts of the connection assume are present.

Why it matters to the business

SSH is widely used for administration, automation, file transfer, network device management, developer tooling, and embedded products, so vulnerable clients and servers can exist across many operational areas. Successful exploitation requires a man-in-the-middle network position, but public exploit tooling exists and the EPSS score is very high, indicating a meaningful likelihood of attempted exploitation in exposed or high-value environments. The main business risk is that trusted administrative or file-transfer sessions may be silently downgraded, weakening security controls and potentially enabling follow-on attacks when combined with other SSH implementation weaknesses or credential-capture opportunities. The vulnerability is not currently listed in CISA KEV and is not known from the provided data to be ransomware-associated, but its broad ecosystem reach and weaponized status justify prioritized remediation.

How an attack unfolds

An attacker first gains the ability to observe and modify traffic between an SSH client and server, for example on an untrusted network, compromised router, malicious Wi-Fi segment, or other interception point. During the unauthenticated SSH key-exchange phase, the attacker carefully injects or suppresses packets and manipulates the SSH Binary Packet Protocol sequence accounting. Against vulnerable combinations of SSH implementations and algorithms, this allows the attacker to remove extension-negotiation messages such as SSH_MSG_EXT_INFO while keeping packet authentication checks consistent from the endpoints' perspective. The client and server then complete the SSH session believing the connection is valid, but with certain negotiated security extensions missing or downgraded. The attacker does not automatically obtain shell access, but the resulting weakened session may remove protections such as strict key-exchange behavior or other extension-based hardening and can create opportunities for chained attacks.

How to fix it

Upgrade SSH clients, servers, libraries, appliances, and applications embedding SSH libraries to versions that implement strict key exchange or otherwise fix Terrapin-style transcript truncation. For the products named in the input, apply fixed code at or after: openssh/openssh-portable commit 8f42e9b75a55401fa9dfdf14d49fbe5396c6ce92; libssh/libssh-mirror commit 10e09e273f69e149389b3e0e5d44b8c221c2e7f6; and connectbot/sshlib commit 5c8b534f6e97db7ac0e0e579331213aa25c173ab. In packaged environments, upgrade to vendor releases that include OpenSSH 9.6 or later, libssh 0.10.6 or later, PuTTY 0.80 or later, AsyncSSH 2.14.2 or later, Paramiko 3.4.0 or later, WinSCP 6.2.2 or later, FileZilla 3.66.4 or later, Bitvise SSH Server 9.32 or later, Bitvise SSH Client 9.33 or later, and other vendor-fixed versions applicable to the deployed product. Where immediate patching is not possible, reduce exposure by disabling vulnerable algorithm combinations, especially chacha20-poly1305@openssh.com and CBC ciphers with Encrypt-then-MAC MACs, on both clients and servers. Prefer patched implementations over configuration-only mitigations because SSH clients, automation tools, libraries, and embedded products may have independent algorithm policies.

How to confirm the fix worked

Confirm installed SSH server, SSH client, and SSH library versions against vendor-fixed releases rather than relying only on operating-system package names. Check OpenSSH versions with commands such as ssh -V and the platform-specific sshd version mechanism, and validate embedded dependencies through software composition analysis, lockfiles, SBOMs, or build manifests. Use a Terrapin-focused SSH scanner or protocol test to verify that exposed SSH endpoints advertise and enforce strict key exchange, typically including kex-strict-s-v00@openssh.com for servers and kex-strict-c-v00@openssh.com for clients where applicable. Validate that vulnerable algorithms are not negotiated by default by testing representative client-to-server connections with verbose SSH output and reviewing the selected cipher and MAC. A fixed or mitigated endpoint should either support strict key exchange or avoid affected algorithm combinations, and should reject malformed or unexpected packets during key exchange rather than completing a downgraded session.

Typical attack path

1. Identify SSH clients or servers that support vulnerable SSH transport behavior and affected algorithms such as chacha20-poly1305@openssh.com or CBC with Encrypt-then-MAC MACs.
2. Obtain a network man-in-the-middle position between the SSH client and server before or during session establishment.
3. Observe the SSH protocol version exchange and key-exchange negotiation to confirm that a vulnerable algorithm combination is selected.
4. Manipulate early handshake traffic and sequence numbers so that selected extension-negotiation packets are omitted without causing the connection to fail.
5. Allow the SSH session to complete with downgraded or disabled security features.
6. Use the weakened SSH session as an enabler for further attacks, where applicable, rather than as a standalone remote compromise primitive.

How to detect it

Reliable post-compromise detection is difficult because the attack targets the SSH handshake and, if successful, the resulting session can appear normal in standard authentication logs. Focus on network telemetry, packet captures, Zeek logs, SSH debug logs, endpoint process telemetry, and configuration/version evidence. Look for SSH sessions that negotiate affected algorithms, especially chacha20-poly1305@openssh.com or CBC ciphers with Encrypt-then-MAC MACs, and lack expected extension-negotiation behavior. In packet captures or protocol metadata, investigate connections where SSH_MSG_EXT_INFO is absent despite both sides normally supporting it, where sequence behavior during key exchange is abnormal, or where unexpected SSH_MSG_IGNORE-style traffic appears during the handshake. Review verbose client logs, if available, for negotiated cipher/MAC combinations and missing strict key-exchange extensions. Because exploitation requires active interception, correlate suspicious SSH handshake anomalies with network path changes, ARP spoofing, rogue Wi-Fi, unexpected gateway changes, duplicate IP/MAC events, VPN concentrator anomalies, or IDS alerts for man-in-the-middle behavior. Detection should be treated as best-effort; absence of evidence in auth logs such as successful logins does not rule out attempted or successful downgrade.

• chacha20-poly1305@openssh.com
• -etm@openssh.com
• hmac-sha2-256-etm@openssh.com
• hmac-sha2-512-etm@openssh.com
• hmac-sha1-etm@openssh.com
• aes128-cbc
• aes192-cbc
• aes256-cbc
• 3des-cbc
• SSH_MSG_EXT_INFO
• SSH_MSG_IGNORE
• kex-strict-c-v00@openssh.com
• kex-strict-s-v00@openssh.com
• OpenSSH_9.5
• OpenSSH_9.4
• OpenSSH_9.3
• OpenSSH_9.2
• OpenSSH_9.1
• OpenSSH_9.0
• PuTTY_Release_0.79
• AsyncSSH_2.14.1
• Paramiko_3.3
• libssh_0.10.5
• WinSCP 6.2.1
• FileZilla_3.66.3

What your security team should do

• Prioritize externally reachable SSH services, bastion hosts, managed file-transfer systems, network/security appliances, CI/CD runners, developer workstations, and automation systems that initiate SSH connections.
• Inventory both SSH servers and SSH clients, including embedded SSH libraries in applications, SFTP products, mobile clients, backup tools, orchestration platforms, and network-management tooling.
• Patch to vendor-fixed releases first; use algorithm disablement only as a temporary compensating control where patching is delayed.
• Disable or de-prioritize chacha20-poly1305@openssh.com and CBC cipher suites with Encrypt-then-MAC MACs on vulnerable systems until fixed versions are deployed.
• Run Terrapin-specific scanning against internet-facing and high-trust internal SSH endpoints, then track remediation by endpoint and product owner.
• Review network paths where SSH traffic traverses untrusted or shared networks, because exploitation requires an active interception position.
• Ensure vulnerability management covers package dependencies such as golang.org/x/crypto, Paramiko, libssh, libssh2, Apache MINA sshd, sshj, jsch, AsyncSSH, Ruby net-ssh, Node.js ssh2, and Rust SSH crates where used.
• Do not treat absence from CISA KEV as low risk; the vulnerability is weaponized, has a high EPSS score, and affects a broad SSH ecosystem.