Late last month, Progress Software disclosed CVE-2023-34362, a critical SQL injection vulnerability in its MOVEit Transfer managed file transfer platform. Within days, the Clop ransomware group had used it to compromise a growing list of organizations, including government agencies, financial institutions, and universities. By early June, the scope was still expanding.

This is not a story about one vulnerability in one product. This is a story about a structural problem in how enterprise software supply chains are secured, and why the current model of relying on vendors to protect their own code is not working.

What Happened

MOVEit Transfer is a widely deployed managed file transfer solution used by enterprises to move sensitive data between systems and partners. It handles payroll data, medical records, financial documents, and other regulated information. It sits at the intersection of business operations and data compliance, which makes it an exceptionally high-value target.

The vulnerability itself is a SQL injection flaw in the MOVEit Transfer web application. SQL injection has been on the OWASP Top 10 since the list was first published. It is among the most well-understood vulnerability classes in existence. That a critical SQL injection persisted in enterprise software in 2023 is not a technical mystery. It is an organizational failure.

Clop exploited the vulnerability to access MOVEit databases, exfiltrate data, and then extort the victim organizations. In a departure from typical ransomware operations, Clop did not deploy encryption in most cases. They skipped directly to data theft and shaming, listing victim organizations on their leak site and demanding payment to prevent publication.

A SQL injection in 2023 is not a sophisticated attack. The sophistication was in target selection: Clop understood that compromising a single file transfer platform would give them access to data from hundreds of organizations downstream.

The Supply Chain Pattern

MOVEit is the latest in a series of supply chain compromises that follow the same pattern. SolarWinds in 2020. Kaseya in 2021. Log4j in 2021 (disclosed December). 3CX in early 2023. Each incident differs in specifics, but the structure is consistent: a threat group identifies a piece of software that sits between many organizations and their sensitive operations, finds a vulnerability in that software, and uses it to compromise the downstream customer base at scale.

The economics favor the attacker. The cost of finding a zero-day in one product is orders of magnitude lower than the cost of defending against zero-days across all products in your supply chain. Clop invested time in understanding MOVEit's architecture and finding a single flaw. That single flaw gave them access to data belonging to organizations they had never heard of, in sectors they had never targeted directly.

This asymmetry is structural. No single vendor, regardless of their security investment, can guarantee the absence of zero-days in their software. And no single customer organization can audit every piece of third-party software they depend on. The current model, where vendors secure their code and customers trust that security, creates a single point of failure that is systematically exploited.

Why Patching Is Not Enough

Progress Software released a patch on May 31, 2023. By that point, Clop had been exploiting the vulnerability for at least several days, possibly longer. For many organizations, the damage was already done. Data had been exfiltrated. The clock on disclosure obligations had started.

Even for organizations that patched immediately, the incident raises questions that patching cannot answer. Was the instance compromised before the patch was available? What data was accessible through the MOVEit database? Which downstream partners received data that may have been exposed? What are the regulatory notification obligations in each jurisdiction where affected individuals reside?

Patching closes the vulnerability. It does not close the incident. And in a supply chain context, the gap between vulnerability discovery and patch application is often measured in weeks, not hours. Clop, like other sophisticated groups, exploits that gap deliberately.

The question is not whether your vendor will ship a vulnerable product. They will. The question is whether your security architecture assumes that they will, and limits the damage when they do.

The MOVEit Specifics Matter

Managed file transfer platforms are uniquely dangerous as attack surfaces because they combine three properties: they handle sensitive data, they are exposed to the internet by design, and they are trusted by the organizations that deploy them. MOVEit is not a behind-the-scenes utility. It is a web-facing application that users authenticate to directly, and its database contains credentials, file contents, and metadata about the data flows it manages.

This means a SQL injection in MOVEit is not equivalent to a SQL injection in a typical web application. In a typical app, you might extract user records or application state. In MOVEit, you can extract the actual documents being transferred, the authentication tokens for connected systems, and the operational metadata that tells you exactly what data flows through the organization and where it goes.

For the fintech startups we work with, the exposure is especially acute. Many use MOVEit or similar platforms to transmit financial data to banking partners, regulators, and payment processors. A compromise of the transfer platform is effectively a compromise of the data relationship between the startup and its entire financial ecosystem.

What We Recommend

1
Assume your supply chain will be compromised. Design your security architecture around this assumption. Segment network access so that a compromised vendor tool cannot reach systems it does not strictly need. Apply the principle of least privilege to vendor software with the same rigor you apply to your own.
2
Audit your third-party software as if it were your own. If a vendor product has access to your sensitive data, it should be in scope for your security assessments. Demand vulnerability disclosure records, penetration test summaries, and secure development lifecycle documentation from every vendor whose software touches regulated or sensitive data.
3
Reduce your dependency surface. Every piece of third-party software in your stack is an attack surface you do not control. Evaluate whether each vendor tool is necessary, whether a simpler alternative exists, and whether you can isolate the tool's access to limit the blast radius of a compromise.
4
Build incident response plans that account for supply chain compromises. Your IR plan should include a playbook for the scenario where a vendor discloses a zero-day. That playbook should cover immediate containment, data exposure assessment, regulatory notification triggers, and customer communication, all before the vendor provides technical details.
5
Monitor for exploitation, not just patches. Threat intelligence feeds, dark web monitoring, and CISA advisories often provide early warning of active exploitation before patches are available. If MOVEit is in your stack, you should have known about Clop's campaign from threat intelligence, not from Progress Software's advisory.

Need help assessing your supply chain risk or responding to the MOVEit incident? Get in touch with our team.