Why MFT Breaches Keep Producing Years of Data
Managed file transfer has produced more mass-exploitation events than almost any other software category of comparable size. Accellion's legacy File Transfer Appliance in 2020 and 2021. Fortra's GoAnywhere in early 2023. Progress MOVEit in May 2023. Cleo's Harmony, VLTrader and LexiCom in late 2024. CrushFTP three separate times across 2024 and 2025. Wing FTP in mid-2025.
Different vendors. Different codebases. Different bug classes: authentication bypass, deserialization, null-byte and Lua injection, AS2 validation failure. One extortion group, Clop, has built a substantial portion of its business on the pattern.
The usual reading is that these vendors have a quality problem. That reading is convenient and mostly wrong. Six independent engineering teams did not simultaneously forget how to write software.
What they share is a shape. A vulnerability with a six-day window between disclosure and patch does not expose six days of files. It exposes whatever the appliance was holding, which is frequently years.
The window governs how long the door was open. The architecture governs what was behind it.
Why do MFT servers keep getting breached?
Three properties, none of them defects, that compound.
They must be reachable from the internet. The entire point is that outside parties send you files. Partners, payers, correspondents, labs. That means a listening service on a public address, and it means Shodan can enumerate them. ReliaQuest documented exactly this progression with CrushFTP: a publicly discoverable instance identified by scan, then targeted directly at the login endpoint.
They accumulate. An MFT appliance is a transfer mechanism that became a repository, because nobody wrote a retention policy for a thing they thought of as a pipe. The file you sent a vendor in 2022 is very likely still on it.
They hold standing credentials. Partner accounts, service accounts, SSH keys, integration credentials. Long-lived by design, because the alternative is a rotation calendar nobody can finish.
Each of those is a reasonable engineering decision in isolation. Together they describe a single internet-reachable system holding years of sensitive files, with durable credentials pointed at it.
What actually turns a bug into a breach?
The gap between the two is blast radius, and blast radius is an architectural property rather than a code quality one.
Consider what a critical vulnerability in this category actually yields. CrushFTP's CVE-2025-54309 scored 9.8 and granted remote unauthenticated administrative control. The Hacker News summary of the consequences is worth reading closely: a compromised instance lets an attacker exfiltrate data, inject backdoors, or pivot into internal systems that rely on the server for trusted exchange.
Note the third one. The appliance is not just holding data. It is a trusted node that other systems authenticate to. Compromising it yields the archive and a foothold.
Now add accumulation. This is the multiplier, and it is the reason relatively ordinary bugs keep producing extraordinary headline numbers. The severity of the vulnerability sets the probability of compromise. The contents of the appliance set the cost.
Those are independent variables, and only one of them is addressed by patching.
Why doesn't a DMZ solve this?
It helps, sometimes more than the argument usually allows. It still does not change the shape.
Be fair to the DMZ here, because the record is better than critics of it tend to admit. Both of CrushFTP's 2025 authentication flaws are scoped, in their own CVE descriptions, to deployments that were not running the proxy: CVE-2025-31161 allows takeover of the crushadmin account "unless a DMZ proxy instance is used," and CVE-2025-54309 mishandles AS2 validation "when the DMZ proxy feature is not used." Customers running the proxy were genuinely carved out of both.
That is the vendor scoping two particular bugs, not a property you can count on for the third. When CVE-2025-54309 landed, Rapid7's contemporaneous advice was to patch regardless rather than trust the carve-out, and that instinct is the right one: whether the hop protects you is decided by the shape of the next vulnerability, not by your architecture.
The reason a DMZ is only partial is that it relocates the reachable surface without removing it. Something still listens on a public address, something still holds the files, and something still accepts the credentials. You have added a hop, which is genuinely useful against some attack paths and irrelevant against others.
The same logic applies to IP allowlists and admin-interface restrictions. Good hygiene. They reduce the probability of reaching the vulnerability. They do not reduce what the vulnerability yields once reached.
What would a different shape look like?
Three properties, each the inverse of one above. Not because inverting a list is clever, but because each of the three independently reduces what a successful exploit reaches.
Nothing durable to steal. If access is short-lived and expires on its own, a credential captured today is worthless next week. The attacker who obtains one inherits a window, not a key. This also removes the rotation calendar, which is the thing nobody completes anyway.
Nothing accumulated to take. If the exchange layer does not become the archive, a compromise yields what is currently in flight rather than what has passed through since 2022. Retention becomes a deliberate decision somewhere else instead of an accident here.
Nothing to authenticate to. The pivot risk exists because internal systems trust the appliance. Remove the standing trust relationship and the foothold does not extend.
None of these are exotic. They are the same principles that moved human identity away from standing credentials over the last decade: ephemeral access, least privilege, no implicit trust between components. They arrived late to file exchange because file exchange was treated as plumbing rather than as an access control surface.
Does this mean managed file transfer is the wrong answer?
No, and it is worth being straight about that.
MFT platforms solve real problems. Scheduling, protocol translation, partner onboarding, retry logic, format conversion. A bank moving files to forty correspondents on six protocols needs something to manage that, and a general-purpose exchange layer is not a substitute for it.
The argument is about shape, not about category. An MFT deployment that does not accumulate history, does not hold standing credentials, and is not the trust anchor for internal systems has a substantially smaller blast radius than one that does, regardless of vendor. Some deployments are already configured that way. Most are not, because the defaults do not push you there and nothing forces the question until an advisory lands.
It is also worth saying plainly that no vendor in this space is immune, including the ones arguing about architecture. A design with fewer durable secrets has a smaller blast radius. It does not have none.
What can you actually do about it?
Four things, in rough order of impact.
Find out what is on the appliance. Not what should be, what is. The gap between the retention policy and the actual contents is the single largest variable in what a compromise would cost you, and most organizations have never measured it.
Make expiry the default for partner access. Every partner credential that outlived its engagement is a durable secret with no owner. This is the most tractable of the four and the one most often deferred.
Map what trusts the appliance. The pivot path is the part that turns a data breach into an intrusion. If internal systems authenticate to it, write down which ones before you need the list under time pressure.
Decide what the exchange layer is for. If it is a pipe, it should not be an archive. If it is an archive, it needs archive controls: retention, access review, and a reason for every file still on it.
Does a different architecture actually help?
Partly, and the honest answer is narrower than the pitch usually is.
MnemoShare is a file exchange platform built without a standing user credential to rotate. Access tokens are short-lived and expire on their own, and a stolen one replays into a revoked family rather than a live session. Every exchange produces a hash-chained audit record that an auditor can verify independently.
That addresses the first and third properties above. It does not manage your retention policy for you, and it is not a replacement for an MFT platform doing protocol translation and partner orchestration. Several of our deployments sit alongside one.
If the useful version of this is a conversation rather than a pitch, the MFT exposure review is thirty minutes and four questions, and you keep the map either way.
Related reading: the SSH keys no scanner can inventory and what SFTP logging actually captures.
The short version
Six products, six mass-exploitation events, six different bug classes. The constant is not code quality. It is a design where one internet-reachable system holds accumulated history and durable credentials, so any sufficiently severe vulnerability yields years of data and a pivot path.
Patching addresses the bug. Nothing about patching addresses the arithmetic.
The question worth asking is not whether your file transfer platform is patched. It is what a successful exploit against it would actually reach, and whether you could answer that today without opening the appliance.
Sources
- Cybersecurity Dive, Critical vulnerability in CrushFTP file transfer software under attack - CVSS 9.8 authentication bypass, Shadowserver unpatched counts (reported as CVE-2025-2825, since rejected by NVD as a duplicate of CVE-2025-31161)
- The Hacker News, Hackers Exploit Critical CrushFTP Flaw to Gain Admin Access - CVE-2025-54309 consequences, CISA KEV addition July 22 2025
- Rapid7, CrushFTP Zero-Day Exploited in the Wild - DMZ guidance assessment
- ReliaQuest, Threat Spotlight: CVE-2025-54309 - Shodan discovery to compromise progression
- Huntress, Wing FTP Server RCE CVE-2025-47812 Exploited in the Wild - null byte and Lua injection detail
- BankInfoSecurity, Hackers Target Zero-Day Vulnerability to Exploit CrushFTP - Clop campaign timeline across Accellion, GoAnywhere, MOVEit, Cleo