In May 2023, ransomware gang CL0P exploited a SQL injection vulnerability in Progress Software's MOVEit Transfer tool.
The result was 96 million people’s data exposed on the web, 2,773 organizations effectively compromised, and a total cleanup cost of $15 billion globally.
More than a year later, huge data repositories were still leaking onto the web. And in 2025, Nuance, a Microsoft subsidiary, paid $8.5 million as part of a suit brought by plaintiffs who alleged the company had failed to take reasonable security precautions.
So how did one vulnerability in a single file transfer tool cause one of the largest data breaches in history?
MOVEit Transfer had a SQL injection vulnerability, but that is not usual. Thousands of software instances are likely to be vulnerable to this attack vector. What was different (but also scarily common) about MOVEit Transfer was that it had become a single point of failure in the trust chain for thousands of organizations.
In most organizations, there were no architectural constraints on what MOVEit Transfer could access once compromised, so an attacker could access anything that MOVEit Transfer could. In many cases, this translated to unrestrained access to sensitive IP and PII.
Below, we'll show you exactly what went wrong during the MOVEit Transfer breach from a secrets management point of view, so that you can avoid a similar situation in your organization.
Here's how the Moveit Transfer attack unfolded.
MOVEit Transfer had been granted the same flat level of trust as internal systems across thousands of organizations. This meant there were no architectural constraints on accessing and exfiltrating sensitive data. Once the application was compromised, Cl0p was free to access and exfiltrate sensitive data as if they were trusted insiders.
The easy, but wrong, way to think about the MOVEit transfer breach is that better third-party vendor risk evaluation by thousands of organizations would have stopped or mitigated it.
In reality, very few organizations will ever have full visibility into their third-party software supply chain, nor do they have the capacity to red team every app deployed in their environment or to fully analyze SBOMs.
The real reason the MOVEit Transfer breach was so damaging was that most organizations lack architectural third-party access control, instead relying on policy or procedure.
Most (70%+) organizations experience some kind of third-party incident each year. This means you have to expect that third parties will be exploited in some way and have controls in place that physically prevent a compromised tool or vendor from accessing data and secrets that, if exposed, would cause irreversible damage.
In December 2020, attackers compromised the SolarWinds Orion build system and injected malicious code into a routine software update distributed to approximately 18,000 organizations.
Government agencies and Fortune 500 companies were breached because they had trusted a network management tool with broad access to their infrastructure.
The attack path was identical. A trusted third-party tool had been granted broad access without architectural constraints. When the tool was compromised, the trust it had been granted became the attack vector.
As we saw with MOVEit, unlimited trust creates the potential for almost unlimited exposure to risk. Without an architectural constraint on access, the only protection from breach exposure at a fundamental level is policy and procedure.
Most security controls are reactive. You cannot rely on them to reduce your breach exposure when the data at stake exposes you to regulatory fines and lawsuits by default.
With that said, we can take three lessons from the MOVEit breach.
When one tool holds unconstrained access across thousands of organizations, its compromise becomes everyone's breach.
Trust must be constrained architecturally and not assumed at onboarding.
MOVEit was authenticated and authorized. The problem was that once trusted, it could access everything.
Controls on sensitive data need to govern what a trusted identity can do and be split among identities.
The organizations that suffered most had granted third-party tools direct access to sensitive data with no independent protection.
The boundary between your security and your vendor's security disappears when secrets are shared.
Had SplitSecure privileged access management (PAM) been in use to protect access to sensitive data stores, no single identity would have held a complete secret and been able to authorize full access.
SplitSecure prevents incidents like the MOVEit Breach across three layers with:
No single point of failure
Separation of duties is enforced by architecture
Every request is logged automatically
In 2023, the CL0P ransomware group exploited a SQL injection vulnerability in Progress Software's MOVEit Transfer to steal data from 2,773 organizations, affecting 96 million individuals. The estimated global cost reached $15 billion.
MOVEit Transfer was a trusted tool with unconstrained access to sensitive data across every organization that used it. When the tool was compromised, attackers could access all the data it was trusted to handle, including data from organizations that had no direct relationship with MOVEit.
By distributing credentials across multiple devices, so no single tool, vendor, or system holds a complete secret. SplitSecure uses Shamir Secret Sharing to split credentials into fragments distributed across devices you control. Even if a trusted tool is compromised, it cannot reconstruct usable secrets.
See how SplitSecure's distributed secrets architecture prevents single-point-of-failure attacks through your most trusted tools and vendors.
Our Blog
