AIKIDO-2026-829968

dartssh2 is vulnerable to Prefix Truncation Attack

Prefix Truncation Attack Pre-CVE Published 4 days ago

Medium Risk

This Affects:

dartssh2

0.0.1 - 3.0.2

Fixed in 3.1.0

Are you affected? Scan for Free

TL;DR

Affected versions of dartssh2 have no Terrapin countermeasure (CVE-2023-48795). The client never advertises or negotiates strict key exchange (kex-strict-c-v00@openssh.com), so an on-path attacker can inject SSH_MSG_IGNORE and related packets during the handshake to desynchronize sequence numbers and truncate the prefix of the secure channel—for example dropping extension negotiation or weakening session integrity when ChaCha20-Poly1305 or CBC with Encrypt-then-MAC is used. Default algorithm preferences also favored weaker choices: aes128-cbc ahead of stronger CTR/GCM modes, truncated 96-bit MACs ahead of Encrypt-then-MAC, AES-GCM omitted despite being implemented, and broken algorithms such as diffie-hellman-group1-sha1, hmac-md5, and hmac-sha2-*-96 remaining in the default lists. Version 3.1.0 adds automatic strict key exchange when the server supports it, resets sequence numbers after every SSH_MSG_NEWKEYS, rejects ignore/unimplemented/debug messages during key exchange, requires the first KEXINIT to be the first packet, and hardens the default cipher, MAC, and host-key preference order.

Who does this affect?

You are affected if you are using a version that falls within the vulnerable range and your application uses dartssh2 as an SSH or SFTP client, especially when connecting over networks where a man-in-the-middle can interfere with the handshake.