CVE-2026-59844

What it actually does

CVE-2026-59844 is a denial-of-service flaw in libssh SFTP server handling. An authenticated SSH/SFTP client can send SSH_FXP_READ requests containing an excessively large requested read length. If the server trusts or inadequately bounds that length, it may attempt to allocate memory proportional to the attacker-controlled value. Repeated requests can drive excessive memory consumption, trigger allocation failures, degrade service, or terminate the process or host workload due to out-of-memory conditions. The issue requires network access to the SSH/SFTP service and valid authentication, but does not require user interaction and does not directly provide confidentiality or integrity impact.

Why it matters to the business

Systems exposing SFTP services backed by affected libssh versions may be vulnerable to service disruption by any authenticated account, including low-privileged or compromised accounts. Successful exploitation can interrupt file transfer workflows, automation pipelines, backups, data exchange with partners, and administrative access paths that depend on SFTP. The CVSS availability impact is high, but the currently low EPSS score, absence from CISA KEV, no known ransomware association, and no reported mature public exploit suggest prioritizing remediation based on exposure and business criticality rather than emergency response. Organizations with many downstream uses of libssh should account for embedded or packaged copies in appliances, applications, and Linux distributions.

How an attack unfolds

An attacker first obtains valid credentials for a service that exposes an SFTP subsystem implemented with a vulnerable libssh version. After establishing an SSH session and starting SFTP, the attacker sends crafted SSH_FXP_READ messages that specify an abnormally large length field instead of a realistic file-read size. The vulnerable server attempts to satisfy or prepare for the request by allocating excessive memory. By repeating the request, issuing concurrent sessions, or targeting large numbers of SFTP worker processes, the attacker can exhaust available memory, causing the SFTP service or surrounding process to become slow, fail allocations, crash, or be killed by the operating system out-of-memory manager. Because exploitation is authenticated, abuse may come from compromised accounts, malicious insiders, exposed test accounts, or automated integrations with weak credentials.

How to fix it

Upgrade affected libssh packages to a fixed release. For Red Hat libssh-main, apply RHSA-2026:42922 and update to libssh-main 0.12.1-4.hum1 or later. Restart services that link against libssh after updating so the patched library is loaded; where static linking or bundled libssh copies are used, rebuild or update the dependent application as well. If immediate patching is not possible, reduce exposure by limiting SFTP access to trusted networks, disabling unnecessary SFTP subsystems, enforcing strong authentication, removing unused accounts, applying per-user and per-service resource limits, constraining maximum sessions, and monitoring or rate-limiting abnormal SFTP read behavior. Consider memory cgroups, systemd limits, and process supervision to reduce blast radius, but treat these as mitigations rather than complete fixes.

How to confirm the fix worked

Confirm installed libssh packages are at or above the fixed version provided by the vendor advisory, specifically libssh-main 0.12.1-4.hum1 or later for the Red Hat package stream covered by RHSA-2026:42922. Verify that all SSH/SFTP daemons and applications using libssh have been restarted after patching by checking loaded library mappings or process start times. Inventory applications and appliances that bundle libssh separately from the operating system package manager. Validate exposure by confirming whether SFTP is enabled and reachable only from intended networks. In a controlled test environment, authenticated SFTP read requests with oversized length fields should no longer trigger abnormal memory growth, crashes, or out-of-memory events. Review system telemetry after remediation to ensure memory usage remains stable under normal SFTP workloads.

Typical attack path

1. Identify an SSH/SFTP service that uses an affected libssh SFTP server implementation.
2. Obtain valid SSH/SFTP credentials through compromise, reuse, weak authentication, or authorized-but-malicious access.
3. Authenticate to the SSH service and initiate the SFTP subsystem.
4. Send SSH_FXP_READ requests with an unusually large attacker-controlled length value.
5. Repeat the malformed read requests or open parallel sessions to amplify memory pressure.
6. Cause excessive memory allocation, allocation failures, process termination, or system-level out-of-memory conditions.
7. Maintain or repeat the activity to keep file transfer services unavailable.

How to detect it

Look for evidence of authenticated SFTP activity immediately preceding memory exhaustion, process crashes, or service restarts. Relevant sources include SSH authentication logs, SFTP subsystem logs, system journals, kernel logs, endpoint telemetry, process accounting, memory monitoring, and service manager logs. Focus on low-privileged or unusual accounts that authenticate successfully and then generate a high volume of SFTP read operations, especially if followed by rapid resident memory growth in the SSH/SFTP process. On Linux systems, review /var/log/secure, /var/log/auth.log, /var/log/messages, journalctl output for sshd or the application embedding libssh, kernel out-of-memory events, coredumps, and monitoring alerts for memory pressure. Since the flaw is protocol-level and the description does not define a unique payload byte pattern, detection is more reliable through behavioral correlation: successful SSH/SFTP login, SFTP subsystem start, abnormal memory allocation growth, allocation failures, SIGKILL or OOM-killer activity, and repeated service restarts from the same source user or IP. If packet capture or SFTP-aware network telemetry is available, inspect for SSH_FXP_READ messages with unusually large requested length fields after decryption or in controlled instrumentation; encrypted SSH traffic generally prevents network-only inspection without endpoint visibility.

• SSH_FXP_READ
• subsystem request for sftp
• subsystem request for sftp by user
• Accepted password for
• Accepted publickey for
• Out of memory
• oom-killer
• Killed process
• invoked oom-killer
• Cannot allocate memory
• std::bad_alloc
• malloc failed
• allocation failed
• sshd.service: Main process exited
• sshd.service: Failed with result
• sftp-server
• /var/log/auth.log
• /var/log/secure
• /var/log/messages
• /var/log/syslog
• /var/lib/systemd/coredump

What your security team should do

• Prioritize patching internet-facing, partner-facing, and business-critical SFTP services using libssh, especially where many users or automation accounts can authenticate.
• Apply RHSA-2026:42922 and upgrade Red Hat libssh-main to 0.12.1-4.hum1 or later; restart all dependent services after patching.
• Inventory both package-managed and bundled libssh instances, including appliances, embedded products, and applications that may statically link or ship their own libssh copy.
• Restrict SFTP access to trusted networks and remove unused or stale SSH/SFTP accounts to reduce the pool of users who could trigger the denial of service.
• Set resource controls such as memory limits, maximum sessions, and service restart policies for SFTP-facing processes to reduce operational impact while patches are deployed.
• Monitor for authenticated SFTP sessions followed by rapid memory growth, allocation failures, service crashes, or operating system out-of-memory killer events.
• Because this is not currently in CISA KEV, has no known ransomware use, and has low EPSS, schedule remediation according to exposure and criticality, but do not defer patching on externally reachable SFTP services.