CVE-2026-59847

What it actually does

The flaw affects libssh builds that use the OpenSSL backend for AES-GCM. Because AES-GCM finalization and authentication-tag verification are handled incorrectly, encrypted SSH traffic may lose its expected integrity protection. A successful in-path attacker who can intercept and modify traffic between an SSH client and server could alter decrypted plaintext without the modification being detected by the protocol. The issue primarily impacts integrity, not confidentiality or availability, and exploitation requires a network-positioned attacker capable of manipulating the SSH session in transit.

Why it matters to the business

Systems and applications that rely on affected libssh versions for SSH-based administration, automation, file transfer, or embedded secure communications may be vulnerable to silent command or data tampering if an attacker can intercept traffic. The operational risk is highest where SSH sessions traverse untrusted or shared networks, jump paths, VPN edges, hosting networks, or network segments where a malicious insider or compromised device could act in-path. Although the EPSS score is low, there is no known public exploitation, and it is not listed in CISA KEV, the potential impact is significant because successful exploitation can undermine trust in supposedly secure administrative channels.

How an attack unfolds

An attacker first needs a position on the network path between a libssh-based SSH client and server, such as control of a routing point, compromised network appliance, malicious Wi-Fi access point, hostile hosting network, or privileged local network segment. The attacker then observes or relays SSH traffic using AES-GCM in an affected libssh/OpenSSL build. Due to the incorrect finalization checks, the attacker may be able to alter encrypted traffic so that modified plaintext is accepted without normal authentication failure. Depending on how libssh is used, this could allow tampering with commands, responses, transferred data, or protocol-level content while the session appears valid to both endpoints. Exploitation is considered high-complexity because it requires precise traffic manipulation and in-path access, and there is currently no reported mature exploit activity.

How to fix it

Upgrade affected libssh packages to a fixed version. For the listed Red Hat libssh-main package, update to 0.12.1-4.hum1 or later as provided by RHSA-2026:42922. After upgrading, restart or redeploy all services, applications, appliances, containers, or agents that dynamically or statically link against libssh so they load the corrected library. Where immediate patching is not possible, reduce exposure by ensuring SSH traffic using libssh does not traverse untrusted networks, prefer trusted management networks or VPNs with independent integrity protection, restrict access to SSH endpoints, and monitor for unexpected routing, proxying, or man-in-the-middle conditions. Avoid relying on cipher-level configuration alone unless vendor guidance confirms a safe temporary configuration for the affected build.

How to confirm the fix worked

Confirm package inventory shows libssh-main updated to 0.12.1-4.hum1 or later, or a vendor-provided fixed equivalent. Verify running processes have been restarted after the update by checking process start times and loaded library mappings where applicable. Confirm applications and appliances that embed libssh have been rebuilt or updated rather than only updating the system package. Review SSH client and server configurations to identify continued use of AES-GCM modes with vulnerable libssh builds before remediation. Validate through vulnerability scanners, package management queries, software composition analysis, or vendor advisory checks that no affected libssh/OpenSSL-backend versions remain in production images, containers, hosts, or firmware.

Typical attack path

1. Gain an in-path network position between a libssh-based SSH client and server.
2. Identify SSH sessions using affected libssh builds with the OpenSSL backend and AES-GCM cipher modes.
3. Intercept, relay, or manipulate encrypted SSH traffic in real time.
4. Abuse the flawed AES-GCM finalization behavior so modified ciphertext results in accepted modified plaintext.
5. Cause silent alteration of commands, responses, file contents, or application protocol data carried over the SSH session.
6. Avoid triggering normal SSH integrity failure indicators, making the tampering difficult to distinguish from legitimate session activity.

How to detect it

There are no reliable, vulnerability-specific indicators that prove exploitation because successful abuse may not generate authentication failures or distinctive endpoint artifacts. Detection should focus on evidence of possible in-path manipulation and anomalous SSH session behavior. Review SSH client and server logs for unexpected disconnects, rekeys, cipher negotiation changes, unusual session timing, and unexplained command or file-transfer discrepancies. Correlate network telemetry for route changes, ARP or neighbor-cache anomalies, duplicate IP or MAC activity, suspicious proxying, unexpected SSH relays, or traffic passing through unauthorized network devices. For high-value sessions, compare administrative command histories, file hashes before and after transfer, deployment artifacts, configuration changes, and audit logs to identify unauthorized modifications that occurred over SSH. If packet capture is available, examine SSH sessions involving AES-GCM for unusual retransmission, timing, or middlebox behavior, but note that encrypted content will generally prevent direct confirmation of plaintext tampering.

What your security team should do

• Inventory systems, applications, containers, and appliances that use libssh, prioritizing administrative, automation, backup, deployment, file-transfer, and embedded SSH use cases.
• Patch Red Hat libssh-main to 0.12.1-4.hum1 or later under RHSA-2026:42922, and apply equivalent vendor updates for any downstream or embedded libssh copies.
• Restart all affected services after patching and verify that running processes are no longer using the vulnerable library.
• Prioritize remediation for systems where SSH traffic crosses untrusted, shared, wireless, cloud-provider, partner, or externally routed networks.
• Until patched, limit libssh-based SSH access to trusted network paths and add compensating controls such as VPN tunneling, strict network ACLs, bastion hosts, and route-change monitoring.
• Review logs and network telemetry for signs of in-path interception, unexpected SSH disconnects, MAC or cipher negotiation anomalies, and unusual command or file-transfer outcomes around sensitive sessions.
• Add this issue to secure build and software composition checks so statically linked or vendored libssh copies are not missed.