CVE-2026-53994: ProFTPD mod_sftp Heap Buffer Overflow
TL;DR - Authenticated SFTP users can crash vulnerable ProFTPD
mod_sftpsessions with a malformed packet. - Patch is available upstream, but the fixed release number is not confirmed in the available source data. - Prioritize internet-exposed or multi-tenant SFTP services and restrict access until updated.
Vulnerability at a Glance
| Field | Value |
|---|---|
| CVE ID | CVE-2026-53994 |
| CVSS Score | 7.5 (High) |
| Attack Vector | Remote over SFTP, after authentication |
| Privileges Required | Authenticated SFTP access |
| Patch Available | Yes, upstream fix commit is available |
This is a heap-based buffer overflow in ProFTPD’s mod_sftp module. Based on the NVD description, the flaw is reachable by an authenticated SFTP user sending a malformed SFTP packet. The documented, confirmed outcome is reliable remote denial of service against the per-connection ProFTPD session child.
For defenders, the practical takeaway is straightforward: this is not an unauthenticated internet wormable bug, but it is still dangerous in shared SFTP environments, partner portals, managed file transfer systems, and any deployment where semi-trusted users can log in. Because the vulnerable path is exercised through normal SFTP connectivity, exposure depends primarily on whether mod_sftp is enabled and accessible to users you do not fully trust.
What Is This Vulnerability?
CVE-2026-53994 is a memory corruption issue in ProFTPD mod_sftp, specifically tied to how SFTP packet length values are handled in the read path. According to the NVD description, the fxp_packet_read() function accepts an attacker-supplied 32-bit big-endian packet length without a minimum sanity check. If that length is set to 0, later arithmetic in the processing path underflows, producing an effective size close to 4 GB.
The bug does not stop at the underflow. The oversized allocation request is rounded using size_t, but is then passed into new_block() as a 32-bit int. That truncation means a value equivalent to 0x100000000 loses its high bits, effectively becoming 0. The allocator then returns a small block, around 512 bytes according to the NVD description, while the caller proceeds as if a much larger buffer were allocated. When attacker-controlled packet data is copied into that buffer, the write overruns the actual allocation, creating a heap-based buffer overflow.
The documented trigger pattern is especially important for defenders because it is concrete. NVD states that a malicious authenticated user can send a packet with packet_len=0 and a body larger than about 544 bytes, causing an attacker-controlled overflow of a 544-byte allocation. That provides enough detail to understand why this is a reliable crash issue even without a public exploit chain for code execution.
At present, the confirmed impact from the available source material is denial of service. The NVD text explicitly says that crashing the per-connection ProFTPD child is reliable and on-demand. More serious outcomes may be possible depending on heap layout and adjacent allocations, but those outcomes are not confirmed in the available data and should not be assumed as proven.
Who Is Affected?
The confirmed affected component is ProFTPD mod_sftp. This matters because not every ProFTPD deployment uses SFTP support, and not every file transfer service running on a host is necessarily exposed through this module. If your ProFTPD instance does not load mod_sftp, this specific issue should not be reachable.
The challenge is version scoping. The source material provided for this article does not include a verified vendor-published affected version range, and it does not confirm a tagged fixed release number. The NVD entry confirms the product and the upstream fix commit, but not exact release boundaries. Because the instruction here is to avoid inventing details, the safest statement is that affected versions are not explicitly confirmed in the retrieved primary-source text.
What defenders should do in the absence of exact version ranges is assume any ProFTPD deployment with mod_sftp enabled may be affected until they verify otherwise against the upstream fix. Specifically, organizations should compare their installed source package or distribution package against the upstream patch commit 7342836fa98e36209660a4c5805c801476f63936. If your vendor package has backported that fix, you may already be protected even if the visible version number appears older.
A practical exposure check starts with configuration review. If your deployment offers SFTP through ProFTPD to customers, partners, internal users, contractors, or automation accounts, and mod_sftp is enabled, treat the system as in scope. Multi-tenant and externally reachable SFTP services should be prioritized because authenticated access is the only prerequisite called out in the vulnerability description.
Technical Notes
Check whether mod_sftp is loaded in ProFTPD:
grep -R "mod_sftp" /etc/proftpd /usr/local/etc/proftpd 2>/dev/null
Example configuration indicators:
LoadModule mod_sftp.c
<IfModule mod_sftp.c>
SFTPEngine on
Port 22
</IfModule>
If ProFTPD was built from source, compare your tree to the upstream fix commit:
git log --oneline --decorate --all | grep 7342836fa98e36209660a4c5805c801476f63936
CVSS Score Breakdown
The base score is 7.5, which places the issue in the High severity range. The exact CVSS vector string was not returned in the source data used for this article, so individual metric values such as Attack Complexity or Availability impact cannot be authoritatively reproduced here. Still, the score aligns with the documented properties: remote reachability, memory corruption, and a reliable service crash path.
A key nuance is privileges required. The bug is not described as unauthenticated. An attacker needs valid SFTP access, which generally lowers severity relative to a pre-auth remote vulnerability. On the other hand, requiring only ordinary SFTP authentication still leaves many real-world deployments exposed, especially where users are numerous, weakly trusted, or externally managed.
The observed impact weighs heavily toward availability because the NVD description confirms reliable denial of service against the per-connection session child. Confidentiality and integrity impacts are less clear from the available evidence. Because a heap overflow exists, defenders should assume the possibility of broader impact until patching is complete, but they should not state confirmed remote code execution or data compromise without stronger evidence.
From an operational standpoint, a 7.5 score here should be interpreted as “high priority if exposed to untrusted authenticated users.” In a tightly controlled internal automation environment, urgency may be lower than a high-severity unauthenticated bug. In a hosted SFTP service or partner exchange system, the practical risk is much closer to urgent because a normal user account may be enough to trigger repeated crashes.
Exploitation Status
Based on the available sources, there is no confirmation of in-the-wild exploitation. The CISA Known Exploited Vulnerabilities catalog does not list CVE-2026-53994 at this time. That means there is no public CISA-backed assertion that this CVE is currently being exploited in active campaigns.
However, that should not be mistaken for low exploitability. The NVD description includes detailed trigger mechanics, including the packet length condition and the approximate body size needed to overflow the allocation. In practice, that often makes proof-of-concept reproduction easier for researchers or attackers with protocol familiarity. In addition, NVD references a third-party technical advisory from VulnCheck, which increases the likelihood that the issue is already reproducible outside the vendor.
The current evidence-based status is:
- Public PoC: Not directly confirmed from the provided primary-source text.
- PoC-style trigger details: Yes, sufficient details are described in NVD.
- Active exploitation in the wild: Not confirmed.
- CISA KEV listing: No.
Defenders should assume opportunistic testing is plausible soon after disclosure, especially against internet-exposed SFTP services. Even if no exploit kit or public exploit repository is yet known, a reliable authenticated crash is often enough to motivate abuse by disgruntled users, tenants, or low-sophistication attackers who already have credentials.
How to Detect It
Detection should focus on two layers: service instability and malformed SFTP traffic. Because the documented effect is a crash of the per-connection ProFTPD child, the most reliable early signal may be repeated session terminations or segmentation faults tied to SFTP activity. If your environment forwards ProFTPD logs and system logs into a SIEM, correlate user sessions with abrupt child exits.
At the network layer, the described trigger condition is unusual enough to support protocol-aware detection if you inspect decrypted SFTP at a proxy or have instrumented testing environments. The standout behavior is an SFTP packet where the attacker-controlled 32-bit big-endian packet length is 0, followed by a body larger than roughly 544 bytes. Not every environment can inspect SSH-encrypted payloads, so host-level telemetry may be more realistic.
Technical Notes
Example Linux log hunting for ProFTPD child crashes:
journalctl -u proftpd --since "24 hours ago" | egrep -i "segfault|signal|crash|child"
dmesg | egrep -i "proftpd|segfault"
grep -R -iE "fatal|segfault|signal|child.*exit" /var/log/proftpd* /var/log/messages /var/log/syslog 2>/dev/null
Example generic log patterns to watch for:
proftpd[PID]: child PID exited with signal 11
kernel: proftpd[PID]: segfault at ...
mod_sftp/... connection closed unexpectedly
Example Splunk query for host crash signals:
(index=os OR index=linux OR index=app) (proftpd OR mod_sftp)
("segfault" OR "signal 11" OR "child" OR "core dumped")
| stats count by host, user, sourcetype
Example Sigma-style logic concept:
title: ProFTPD mod_sftp Crash Indicators
logsource:
product: linux
detection:
selection:
Message|contains:
- "proftpd"
- "mod_sftp"
keywords:
Message|contains:
- "segfault"
- "signal 11"
- "core dumped"
- "child"
condition: selection and keywords
If you operate SSH-aware monitoring in a lab or controlled appliance environment, investigate SFTP requests with a packet length field of zero and subsequent oversized body data. If you cannot inspect payloads, repeated crashes tied to a single authenticated account should be treated as suspicious and worth immediate containment.
Mitigation and Patching
A patch is available upstream through ProFTPD commit 7342836fa98e36209660a4c5805c801476f63936. The exact fixed release number is not confirmed in the source data provided for this article, so do not assume a specific release tag unless your vendor or the ProFTPD project explicitly states it. The safest remediation guidance is to upgrade to the first ProFTPD release that includes that commit, or apply the upstream patch if you maintain source-based builds.
If you cannot patch immediately, reduce exposure by disabling mod_sftp where business requirements allow. This is the most direct workaround because the vulnerable component is the SFTP module itself. If SFTP must remain available, limit access to fully trusted users, reduce the number of enabled accounts, monitor for repeated crashes, and consider rate limiting or access control changes around externally reachable SFTP endpoints.
Be careful with distribution packages. Enterprise Linux and BSD package maintainers often backport security fixes without changing the upstream version string in an obvious way. That means “running an older release” does not necessarily imply vulnerability, and “running a newer version” does not guarantee the package includes the exact patch. Verify with your vendor changelog or by checking whether the patch commit has been incorporated.
Technical Notes
If you build ProFTPD from source, update to a tree containing the upstream fix:
git fetch origin
git cherry-pick 7342836fa98e36209660a4c5805c801476f63936
make
make install
If you deploy from packages, use your platform package manager to move to the vendor-fixed build once available:
sudo apt update && sudo apt install --only-upgrade proftpd-basic
sudo dnf update proftpd
sudo yum update proftpd
If you need an immediate workaround, disable mod_sftp in configuration and restart ProFTPD:
# Comment out or remove:
# LoadModule mod_sftp.c
# Or disable SFTP engine in applicable blocks:
<IfModule mod_sftp.c>
SFTPEngine off
</IfModule>
Then reload or restart the service:
sudo systemctl restart proftpd
After patching or disabling the module, validate that SFTP behavior matches your intended state and monitor for any continued child crashes. If crashes persist, investigate whether another package instance, chrooted service, or alternate ProFTPD binary is still in use.
References
The most authoritative starting point is the NVD entry for CVE-2026-53994, which provides the vulnerability description used here, including the authenticated trigger condition and the documented denial-of-service impact. That NVD record also points to the upstream ProFTPD fix commit and a third-party technical advisory with additional context.
Because exact affected version ranges and the fixed release number were not confirmed in the provided source material, defenders should use the upstream commit and vendor package advisories as their source of truth when scoping and patching. In environments with strict change control, record both the CVE and the specific commit hash in remediation tickets so teams can verify backports accurately.
- NVD entry for CVE-2026-53994
- ProFTPD upstream repository:
https://github.com/proftpd/proftpd - Upstream fix commit:
https://github.com/proftpd/proftpd/commit/7342836fa98e36209660a4c5805c801476f63936 - ProFTPD
mod_sftpdocumentation:http://www.proftpd.org/docs/contrib/mod_sftp.html - VulnCheck advisory referenced by NVD:
https://www.vulncheck.com/advisories/proftpd-mod-sftp-heap-buffer-overflow-via-unsigned-integer-underflow-and-size-truncation
For further reading on related topics, check our articles on what is pharming and what is secrets management.
This article may contain affiliate links. We earn a commission on qualifying purchases at no extra cost to you.