libssh: incorrect AES-GCM finalization removes integrity protection on SSH sessions

Impact

Builds of libssh using the OpenSSL backend do not correctly check AES-GCM finalization, so the authentication tag that is supposed to make tampering detectable effectively stops protecting the session. An in-path attacker can modify plaintext on the wire and the endpoints will not notice. That is a meaningful loss on a GPU fleet because libssh - not OpenSSH - is what libvirt, remote management tooling, automation agents and various vendor CLIs use to reach hypervisors, BMC-adjacent hosts and node management interfaces, often over a management VLAN that is trusted precisely because SSH was assumed to be integrity-protected. Confidentiality is not directly broken here; integrity is, which is what matters when the traffic being modified is a management command.

Who can reach it

An attacker positioned in the network path between a libssh client or server and its peer - no credentials needed, but a machine-in-the-middle position on the management or control network is required.

What to do

Update libssh from the vendor errata (Red Hat ships fixes in RHSA-2026:42922 and RHSA-2026:55855) and restart every service linked against it - libvirtd and any management or automation daemon that speaks SSH through libssh - since long-lived processes keep the vulnerable code loaded. Container images built on affected bases need rebuilding, not just a host package update.

References