libssh CVE-2026-59847

Requires an active man-in-the-middle / in-path position on an established SSH connection AND that the session negotiate an AES-GCM cipher (aes128-gcm@openssh.com or aes256-gcm@openssh.com) handled by a libssh build using the OpenSSL backend. No credentials or SSH authentication are needed (PR:N), and no user interaction is required, but exploitation is strictly limited to attackers who already control a network hop between the two endpoints - it is not exploitable by a remote attacker who merely reaches an open port. It is further limited to OpenSSL-backend libssh builds; deployments using a different crypto backend or non-GCM ciphers are not affected. This is why raw CVSS AV:N overstates reach: the in-path prerequisite is the dominant limiting factor.

This is a moderate, not top-tier, priority. The CVSS 3.1 score of 7.5 (I:H, with C:N/A:N) reflects a pure integrity impact, and the vendor vector's AC:L arguably understates the real precondition: exploitation requires an active in-path/MITM position on a live SSH session, which is a meaningful barrier - supporting an assessed AC:H (3.1) / AT:P (4.0). Corroborating this, EPSS is low at 0.28% (20th percentile), CISA SSVC lists Exploitation: none and Technical Impact: partial, and there is no KEV listing and no known POC. The one signal pointing upward is SSVC Automatable: yes, meaning that once an attacker holds an on-path position the tampering can be scripted at scale. Note a signal conflict worth flagging: the source tags label this 'Information Disclosure,' but the description and CVSS (C:N/I:H) describe an integrity/tamper issue, not a confidentiality leak - treat the disclosure tag with skepticism and rely on the I:H characterization.

An attacker who can intercept and relay traffic between an SSH client and server (e.g., via ARP spoofing on a shared LAN, a rogue router, or a compromised upstream hop) lets a session negotiate an AES-GCM cipher, then flips or substitutes ciphertext bytes; because the GCM tag is not properly verified, the modified plaintext is delivered to the peer as if authentic. This could corrupt a transferred file, alter a command in an automated SSH-driven pipeline, or tamper with tunneled protocol data. No public exploit code has been identified, and the attack presupposes a persistent on-path position rather than remote unauthenticated reach against an exposed port.