Here we are again.
Progress Software has disclosed a critical authentication bypass in MOVEit Automation. An unauthenticated attacker can access the administrative interface, read and modify automated transfer workflows, redirect file transfers, and review logs of all prior operations. The advisory recommends patching immediately. Security teams are scrambling to apply emergency maintenance windows. CISOs are drafting messages to their boards explaining why a product that was already in the news three years ago is in the news again.
The predictability of this moment should be the story. It is not.
The Pattern Is Not Coincidental
Let us be specific about what has happened to managed file transfer software in the last three years. MOVEit Transfer: critical SQL injection, 2,700 organisations compromised, the largest mass breach event of 2023. Fortra GoAnywhere: critical authentication bypass, exploited before most customers had patched. Accellion FTA: zero-day exploitation by a sophisticated threat actor against financial and government clients globally. Kiteworks: critical remote code execution. And now MOVEit Automation, which is a different product from MOVEit Transfer — same vendor, different codebase — with another critical authentication bypass.
This is not a run of bad luck. Managed file transfer platforms are exactly the kind of software that attracts concentrated attacker research. They are internet-accessible by design. They process the most sensitive files in an organisation’s workflow. They are trusted by firewalls and data loss prevention systems because they are legitimate. They frequently have direct access to regulated data stores — HR systems, financial databases, healthcare records. And critically, they are often forgotten: deployed, configured, and left to run for years without the patching and monitoring rigour applied to more visible infrastructure.
Threat actors understand this calculus better than most security programmes do.
The Emergency Response Model Is Not Working
After the 2023 MOVEit exploitation, the standard industry advice was to patch promptly. After GoAnywhere, patch promptly. After each new managed file transfer vulnerability, the security community publishes urgent advisories urging immediate patching — and many organisations do patch, and the cycle continues.
The problem with “patch promptly” as a security strategy is that it assumes the vulnerability disclosure timeline is favourable: that the patch arrives before exploitation, that organisations have enough notice to apply it, and that the window between disclosure and weaponised exploitation gives defenders time to act. The 2023 Cl0p campaign demonstrated that this assumption is wrong. Cl0p had likely been studying MOVEit for months before their mass exploitation campaign began. When they moved, they moved against thousands of targets simultaneously, and the window between public disclosure and mass exploitation was measured in hours, not days.
A patching programme that works when you have two weeks does not work when you have twelve hours.
What the Architecture Should Look Like
The correct model for internet-facing managed file transfer infrastructure is not “keep it patched.” It is “assume it is breached and design controls accordingly.”
What does that mean in practice?
Network access to MFT administrative interfaces should be restricted to management network IP ranges or VPN-only access. There is no operational reason for MOVEit’s administrative panel to be publicly accessible. Transfer endpoints can be internet-accessible — the file transfer function requires external connectivity — but the management plane does not.
MFT platforms should not have direct database access to core business systems. The architecture that makes MFT breaches so catastrophic is the one where the MFT server has read access to an HR system, write access to a financial data store, and is running service accounts with broad internal permissions. If the MFT platform can only read files from a dedicated staging area — and cannot reach production databases directly — compromise of the MFT platform is contained damage, not catastrophic exposure.
Logs from MFT platforms should be in SIEM continuously, not reviewed after the fact when an emergency warrants it. Transfer volume anomalies, unusual new task definitions, and new external destinations are all detectable in near-real-time if anyone is watching.
And MFT vendor software should be on a continuous security review cycle — not treated as infrastructure that gets patched when a critical advisory arrives. The track record of this product category suggests that critical vulnerabilities are a regularly recurring event, not an exceptional one.
The Harder Conversation
Here is the argument the security industry avoids having: some organisations that deployed managed file transfer platforms did so because it was the convenient path, not because it was the right architecture. The correct design for sensitive inter-organisational data exchange in a zero-trust model is not “run an internet-accessible file server with an administrative panel” — it is purpose-built APIs with fine-grained access controls, mutual TLS authentication, and data minimisation at the transfer layer.
MOVEit exists because organisations needed a practical solution for moving files in the 2000s and 2010s, and it works well for that purpose. The security model it was designed for — perimeter trust, network-level authentication, centralised file staging — is not the security model that survives sustained, sophisticated attacker focus in 2026.
The correct response to the third critical MOVEit vulnerability is not another emergency patch window. It is a strategic review of whether MFT platforms should remain internet-accessible at all, and what it would take to build the data exchange architecture that does not require them to be.
That review will not happen between now and the next disclosure. But it should be on the roadmap.
Share this article