CVE-2026-59848

What it actually does

The flaw is in libssh SFTP client handling. A malicious or compromised SFTP server can send protocol responses containing request IDs that the client did not issue or no longer recognizes. Instead of promptly discarding those unexpected responses, affected libssh clients can keep them queued indefinitely, allowing the server to drive unbounded memory growth in the client process. The result is client-side denial of service through excessive memory consumption, potentially leading to process termination by the operating system, application instability, or broader resource pressure on the host running the libssh-based client.

Why it matters to the business

Organizations using applications or automation built on affected libssh versions may experience outages or failed file-transfer workflows when those clients connect to malicious, compromised, or untrusted SFTP servers. The likely consequence is availability disruption rather than data theft or data modification. Because the issue affects a commonly embedded SSH/SFTP library, exposure may exist indirectly through tools, appliances, agents, or custom applications that depend on libssh. This issue is not currently listed in CISA KEV, is not known to be used in ransomware campaigns, and has a low EPSS score, so prioritization should focus on systems that initiate SFTP connections to third-party, internet-facing, or otherwise untrusted servers.

How an attack unfolds

An attacker operates or compromises an SFTP server that a vulnerable libssh-based client will connect to. After the SSH/SFTP session is established, the attacker sends crafted SFTP responses that reference unknown request IDs. The vulnerable client retains these unexpected responses in memory rather than releasing them. By repeatedly sending such responses, the attacker causes the client process memory usage to grow until the process becomes unstable, is killed by the operating system, or causes degraded performance on the host. Exploitation does not require authentication to the client, but it does require the vulnerable client to connect to an attacker-controlled or malicious SFTP server, or for an attacker to influence the SFTP endpoint being contacted.

How to fix it

Upgrade affected libssh packages to a fixed version. For Red Hat libssh-main, update to 0.12.1-4.hum1 or later as provided by RHSA-2026:42922. Rebuild or redeploy any statically linked applications, containers, appliances, or bundled software that include vulnerable libssh code. Where immediate patching is not possible, reduce exposure by limiting libssh-based SFTP clients to trusted servers, enforcing allowlists for SFTP destinations, monitoring memory consumption for SFTP client processes, applying process memory limits where operationally safe, and avoiding automated connections to unknown or user-supplied SFTP endpoints.

How to confirm the fix worked

Confirm the installed package version is fixed, specifically libssh-main 0.12.1-4.hum1 or later for the Red Hat advisory path. Verify that applications and containers actually load the updated libssh library rather than an older bundled or statically linked copy. Review software bills of materials, package manifests, and runtime library linkage for libssh usage. Exercise representative SFTP workflows against trusted servers after patching to confirm normal operation. If feasible in a controlled test environment, validate that clients no longer exhibit unbounded memory growth when receiving malformed or unexpected SFTP responses with unknown request IDs.

Typical attack path

1. Identify an application, job, integration, or automation task that uses an affected libssh SFTP client implementation.
2. Cause or wait for the vulnerable client to connect to an attacker-controlled, compromised, or malicious SFTP server.
3. Complete enough of the SSH/SFTP interaction for the client to process SFTP protocol responses.
4. Send repeated SFTP responses containing unknown or unexpected request IDs.
5. Trigger indefinite queuing of those responses in the vulnerable client process.
6. Exhaust client-side memory, causing degraded performance, process crash, failed file transfers, or operating-system out-of-memory termination.

How to detect it

To determine whether exploitation may already have occurred, review endpoint, application, and system logs for libssh-based SFTP clients that experienced abnormal memory growth, crashes, or operating-system out-of-memory termination during or shortly after SFTP sessions. Correlate OOM events with outbound SSH/SFTP connections, especially to newly observed, external, partner-managed, or untrusted servers. Useful log sources include Linux system journals, kernel logs, container runtime logs, process supervisor logs, application logs for SFTP integrations, EDR telemetry, NetFlow or proxy/firewall logs for outbound TCP/22, and crash/core-dump records. Look for repeated transfer failures, client process restarts, memory-limit kills in containers, and unusual long-lived or high-volume SFTP sessions. There are no known public attacker-specific indicators for this CVE; detection should focus on behavioral evidence of client-side memory exhaustion following SFTP communication with suspicious servers.

• Out of memory: Killed process
• oom-killer
• Memory cgroup out of memory
• Killed process
• systemd-coredump
• segmentation fault
• core dumped
• TCP/22
• sftp
• libssh

What your security team should do

• Inventory systems, applications, containers, and appliances that use libssh for SFTP client functionality.
• Prioritize patching for systems that initiate SFTP connections to external, partner-managed, internet-facing, or user-configurable destinations.
• Apply the vendor fix: libssh-main 0.12.1-4.hum1 or later for Red Hat packages covered by RHSA-2026:42922.
• Rebuild and redeploy software that statically links or bundles libssh, since host package updates may not remediate embedded copies.
• Restrict outbound SFTP connections to approved destinations and block or alert on connections to newly observed or untrusted SFTP servers.
• Add monitoring for abnormal memory growth, repeated SFTP client crashes, and operating-system out-of-memory events associated with libssh-based applications.
• Investigate recent unexplained failures of SFTP automation, especially where failures involved high memory use or OOM termination after connecting to unfamiliar SFTP servers.