CVE-2026-66033: 
Wolfi Analyse et atténuation des vulnérabilités

CVE-2026-66033 is a pre-authentication integer underflow vulnerability in libssh2 versions through 1.11.1, affecting the ssh2_cipher_crypt() function in src/openssl.c. A malicious SSH server can crash any connecting libssh2 client by negotiating AES-GCM ciphers during the SSH handshake, before any authentication occurs. The vulnerability was disclosed on July 24, 2026, and is fixed in commit a2ed82d. It carries a CVSS v3.1 score of 7.5 (High) and a CVSS v4.0 score of 8.7 (High) (Github Advisory, VulnCheck).

The root cause is an integer underflow (CWE-191) combined with an out-of-bounds read (CWE-125) in the ssh2_cipher_crypt() function. In non-debug builds, the expression cryptlen = blocksize - aadlen - authenticationtag was computed without bounds validation, meaning that if aadlen + authenticationtag exceeded blocksize, the result would wrap around to a near-SIZE_MAX value. This underflowed value was then passed as the length argument to a memcpy call, triggering an out-of-bounds read and immediate process crash. The fix (PR #2401, commit a2ed82d) replaces the debug-only assert statements with runtime bounds checks that validate blocksize >= aadlen + authenticationtag before computing cryptlen (libssh2 PR #2401, libssh2 commit a2ed82d).

Successful exploitation results in an immediate crash of the libssh2 client process, causing a denial of service. Because the crash occurs during the SSH handshake before any authentication, no credentials or user interaction are required from the victim beyond initiating an SSH connection to a malicious server. There is no impact on confidentiality or integrity — the vulnerability is purely an availability issue affecting any application or system that uses libssh2 to establish SSH connections (Github Advisory, VulnCheck).

1. Set up a malicious SSH server: Configure a rogue SSH server that advertises and negotiates AES-GCM ciphers (e.g., aes128-gcm@openssh.com or aes256-gcm@openssh.com) during the SSH handshake.
2. Redirect victim connections: Position the malicious server to intercept or redirect SSH connections from a target using libssh2 (e.g., via DNS spoofing, ARP poisoning, or by hosting a service that victims are expected to connect to).
3. Initiate handshake: When the libssh2 client connects, the malicious server negotiates AES-GCM as the cipher suite during the key exchange phase.
4. Trigger the underflow: The vulnerable ssh2_cipher_crypt() function computes cryptlen = blocksize - aadlen - authenticationtag without bounds validation; with attacker-controlled cipher parameters, this expression underflows to a near-SIZE_MAX value.
5. Crash the client: The underflowed cryptlen is passed to memcpy, triggering an out-of-bounds read and causing the libssh2 client process to crash immediately, before any authentication occurs (libssh2 PR #2401, Github Advisory).

• Logs: Unexpected SSH client process crashes or segmentation faults logged in system logs (e.g., /var/log/syslog, /var/log/messages) immediately after initiating an SSH connection, with no authentication phase recorded.
• Network: SSH connections to unfamiliar or unexpected server IP addresses that terminate abruptly during the handshake phase; cipher negotiation logs showing AES-GCM selection followed by connection failure.
• Process: Abnormal termination of applications embedding libssh2 (e.g., curl, git, custom SSH clients) with signals such as SIGSEGV or SIGABRT during SSH connection establishment.

The fix is available in commit a2ed82d40964bbc0d64cd717aa0a5a892117d2e6 in the libssh2 repository; users should upgrade to a build containing this commit or any subsequent release. As a workaround, restrict SSH connections to trusted, known-good servers only, and consider configuring libssh2-based applications to exclude AES-GCM cipher suites if the library version supports cipher preference configuration. Monitor for unexpected SSH client crashes as a detection measure until patching is complete (libssh2 commit a2ed82d, VulnCheck).

The vulnerability was reported by Vladimir Eli Tokarev and addressed by libssh2 maintainer vszakats via PR #2401. VulnCheck published an advisory documenting the issue. No significant broader media coverage or notable community debate has been observed at the time of disclosure (libssh2 PR #2401, VulnCheck).