Description

Server-side memory exhaustion in Apache MINA SSHD 1.0.0 to 2.19.0 and 3.0.0-M1 to 3.0.0-M5, component sshd-sftp, in the SFTP v6 check-file-name/check-file-handle extension. Apache MINA SSHD is a Java library for client-side and server-side SSH. Using a very small "block size" (for instance 256, which is the minimum) on a huge file generates many (file size / block size) hashes. The resulting SFTP reply message was accumulated fully in memory server-side, which could, with a suitably large (possibly sparse) file exhaust the server-side memory, taking down the server. Users are recommended to upgrade to version 2.20.0 or 3.0.0-M6, which fix this issue by imposing a maximum limit on the size of the reply. Many SFTP implementations have a general limit on the size of SFTP messages anyway; typically 256kB as in OpenSSH or also in Apache MINA SSHD.

Executive Summary

Technical Details

Mitigations

References

Additional Metadata

{
  "score": "6.5",
  "pubDate": "2026-09-30T10:17:18.010Z",
  "pubdate": "2026-09-30T10:17:18.010Z",
  "executiveSummary": "This vulnerability involves a server-side memory exhaustion issue within the sshd-sftp component of Apache MINA SSHD. The flaw arises from improper resource management when processing SFTP v6 check-file-name and check-file-handle extensions.\nBy specifying an exceptionally small block size against a large file, an attacker can force the server to calculate and accumulate a vast number of hash values within its internal memory buffer before transmitting the response. This behavior leads to uncontrolled heap allocation, potentially resulting in an OutOfMemoryError (OOME), which causes the application to crash and effectively denies service to legitimate users.\nThe vulnerability affects Apache MINA SSHD versions 1.0.0 through 2.19.0, as well as 3.0.0-M1 through 3.0.0-M5. Successful exploitation requires the ability to interact with the SFTP service, but does not necessarily require high-level administrative privileges, depending on the server's configuration. The primary risk is total service unavailability caused by resource exhaustion.\nThe remediation requires upgrading to version 2.20.0 or 3.0.0-M6, which introduces hard constraints on the maximum permissible size of SFTP reply messages, effectively preventing the accumulation of oversized responses.",
  "technicalDetails": "The root cause of this vulnerability lies in the design of the sshd-sftp component's implementation of the SFTP v6 check-file-name and check-file-handle extensions. The protocol allows a client to request integrity checks on file segments by specifying a block size. The implementation fails to validate or impose a ceiling on the total memory allocated for the server's response payload generated by these requests.\nExploitation is triggered when an attacker initiates an SFTP session and executes the check-file-name or check-file-handle command. By providing a block size set to the minimum allowed value (256 bytes) and targeting a significantly large file, the server is forced to compute a disproportionately large number of hash operations. The resulting SFTP reply, which contains the collection of these hashes, is serialized into a buffer held entirely in the server's memory.\nThe attack flow is as follows: First, the attacker identifies a large or sparse file on the remote filesystem accessible via SFTP. Second, the attacker sends a malformed or intentionally oversized request to the check-file-name or check-file-handle extension, setting the block size parameter to the minimum threshold. Third, the Apache MINA SSHD server processes this request by performing intensive hashing across the entire target file. Fourth, the server attempts to aggregate the cumulative hash data into a response packet before transmission. Because there is no existing limit on the total size of this response packet, the memory allocation scales linearly with the file size divided by the block size.\nIf the resulting object exceeds the available heap space allocated to the Java Virtual Machine (JVM) running the SSH server, an OutOfMemoryError is triggered. This incident results in immediate process termination or significant performance degradation, leading to a state of denial-of-service for all concurrent users of the SSHD instance. This vulnerability is particularly potent against large files, as the memory footprint required to handle the reply can quickly grow into gigabytes. The impact is significant because it allows a remote, potentially unauthenticated or low-privilege attacker to take down the server instance with minimal traffic volume, simply by leveraging the logic inherent in the server's response-generation mechanism."
}