CVE-2026-53994 in ProFTPDinfo

Summary

by MITRE • 07/18/2026

ProFTPD mod_sftp contains a heap-based buffer overflow reachable by an authenticated SFTP user. The fxp_packet_read() function accepts the attacker-supplied 32-bit big-endian SFTP packet length without a minimum sanity check. A value of 0 causes an unsigned subtraction elsewhere in the read path to underflow to approximately 4 GB. That oversized request reaches the core memory allocator, where the rounded size is computed in size_t but passed to new_block() as a 32-bit int; the low 32 bits of 0x100000000 are 0, so new_block() returns a small (~512-byte) block while the caller is told it received ~4 GB. The subsequent fill loop then streams attacker-controlled bytes past the end of the 544-byte allocation, producing an attacker-controlled heap buffer overflow. An authenticated user can crash the per-connection ProFTPD session child on demand with a single malformed SFTP packet (packet_len=0 followed by a body greater than approximately 544 bytes), producing reliable authenticated remote denial of service. Depending on heap layout and adjacent allocations, heap metadata corruption and further consequences beyond denial of service may be possible, though only denial of service is demonstrated by the supplied proof of concept.

If you want to get best quality of vulnerability data, you may have to visit VulDB.

Analysis

by VulDB Data Team • 07/19/2026

The vulnerability in ProFTPD mod_sftp represents a critical heap-based buffer overflow that arises from inadequate input validation within the fxp_packet_read() function. This flaw exists specifically within the SFTP subsystem where the function processes 32-bit big-endian packet length values without performing minimum sanity checks. The vulnerability is particularly dangerous because it requires only authenticated access to exploit, making it accessible to users who have established valid SFTP connections. When an attacker sends a packet with a length field set to zero, the subsequent unsigned subtraction operation in the read path causes an underflow that results in an approximately 4 gigabyte request being processed by the memory allocator. This mathematical underflow creates a scenario where the system allocates memory based on a truncated 32-bit value while the calling code expects a much larger allocation size.

The technical implementation of this vulnerability stems from a fundamental mismatch in data type handling within the memory allocation process. The system computes the rounded size using size_t data types which can accommodate large values, but then passes this value to new_block() as a 32-bit integer. This conversion results in the loss of significant bits where the low 32 bits of the 0x100000000 value become zero, causing new_block() to return a small memory block of approximately 544 bytes instead of the expected ~4 gigabytes. The subsequent fill loop then proceeds to stream attacker-controlled data beyond the bounds of this small allocation, creating a heap buffer overflow condition that can be precisely controlled by the malicious user.

The operational impact of this vulnerability extends beyond simple denial of service to potentially enable more sophisticated exploitation techniques. An authenticated SFTP user can reliably crash any ProFTPD session child process with a single malformed packet consisting of a zero-length header followed by data exceeding approximately 544 bytes. This capability provides an attacker with a reliable means of conducting authenticated remote denial of service attacks against the FTP server. The vulnerability's accessibility through standard SFTP authentication makes it particularly concerning for environments where multiple users maintain valid accounts, as any compromised or malicious user could exploit this weakness to disrupt services.

The heap corruption potential associated with this vulnerability aligns with CWE-121 heap-based buffer overflow categories and represents a classic example of memory safety issues in C/C++ applications. The attack vector follows patterns commonly seen in the ATT&CK framework under techniques related to privilege escalation and denial of service through memory corruption. While the current proof of concept only demonstrates denial of service, the underlying heap manipulation could potentially be leveraged for more advanced exploitation if attackers can predict or control heap layout. The vulnerability's design flaw in handling unsigned integer underflows combined with improper type conversion creates a pathway for attackers to manipulate memory allocation behavior and subsequently corrupt adjacent heap metadata.

From a defensive perspective, this vulnerability highlights the importance of proper input validation and memory safety practices in network service implementations. Organizations should prioritize immediate patching of affected ProFTPD installations and implement monitoring for suspicious SFTP activity patterns that might indicate exploitation attempts. The vulnerability also underscores the need for comprehensive testing of boundary conditions in network protocol implementations, particularly when dealing with unsigned integer operations and memory allocation routines that may be susceptible to underflow or overflow scenarios. System administrators should consider implementing additional access controls and logging mechanisms around SFTP services to detect and respond to potential exploitation attempts more effectively.

The severity classification of this vulnerability places it among the most critical security issues requiring immediate attention, as it provides authenticated remote code execution capabilities with minimal prerequisites for exploitation. The combination of low attack complexity, high impact, and accessible attack surface makes this vulnerability particularly dangerous in production environments where ProFTPD serves as a primary file transfer service. Security teams should conduct comprehensive assessments of their SFTP infrastructure to identify all potentially affected systems and implement appropriate mitigations while monitoring for any signs of exploitation attempts in their network traffic logs.

Responsible

VulnCheck

Reservation

06/11/2026

Disclosure

07/18/2026

Moderation

accepted

CPE

ready

EPSS

0.00000

KEV

no

Activities

medium

Sources

Do you want to use VulDB in your project?

Use the official API to access entries easily!