Incidents
MOVEit mass breach (2023) — how a SQL injection zero-day reached 2,700+ orgs, and how to defend
A SQLi zero-day (CVE-2023-34362) in MOVEit, mass-exploited by Cl0p before a patch — 2,700+ orgs, ~93.3M people, most hit through a vendor. The attack chain as a defense map, and the fixes that matter.
We read real public incidents not as news reruns, but through "how would you defend against this". This article is based on public records (agencies, vendor advisories, threat intelligence, reporting), cited at the end. No attack steps or payloads.
- Target
- MOVEit Transfer (Progress Software's file-transfer product) and the orgs and clients using it
- Exploitation began
- around May 27, 2023 (US Memorial Day weekend)
- Class
- a public web app SQL injection zero-day → web shell → data theft from the backing DB, plus extortion
- Scale
- 2,700+ organizations, ~93.3M individuals (later estimates higher)
- Root cause
- unknown SQLi flaw + mass exploitation before a patch + a web tier that could read the whole backing DB + spread via vendors
- Real fixes
- KEV fast-patching, minimize exposure, web↔DB least privilege and segmentation, vendor inventory and data minimization
What happened (in plain terms)
MOVEit Transfer is a product for securely handing files between organizations, and many ran it exposed to the internet. Its public web interface had a SQL injection zero-day — a flaw where input rewrites the meaning of a database query.
The Cl0p group exploited it before a fix existed to plant a web shell (a malicious program for remote control, named "LEMURLOOT" in public records) on exposed MOVEit instances. With that, they bulk-read the files and user information stored in the database behind the product and exfiltrated it. Cl0p then claimed responsibility on a leak site and demanded ransom, threatening to publish the data.
A 'file-transfer appliance' is a treasure map to an attacker
File-transfer products, by their nature, concentrate sensitive data from many organizations and tend to be exposed to the internet for business use. To an attacker that's a high-value target: "break one, reach a lot of data." So this kind of public appliance must be defended on the assumption it will be among the first things hit the moment a zero-day appears.
The attack chain is also a defense map
What matters is that this was a chain of four hops, and each hop had a place to stop it. Read it not as an attack recipe but as where it could have been cut.
1. Entry: SQLi zero-day in the public web app
an unknown SQL injection flaw in an internet-facing interface.
⊘ stop: minimize exposure (behind VPN/IP allowlist)
2. Web shell planted
the flaw is used to install a remote-control program.
⊘ stop: KEV fast-patching (close the active hole in hours-days)
3. Data stolen from the backing DB
the web tier bulk-reads stored data from the database.
⊘ stop: web↔DB least privilege, segmentation, bulk-read detection
4. Spread to thousands via vendors
from vendors who used MOVEit, on to their clients' data.
⊘ stop: vendor inventory + minimize the data you hand over
The disclosed timeline
2023-05-27
Cl0p begins mass-exploiting the MOVEit Transfer zero-day (US Memorial Day weekend).2023-05-31
Progress Software discloses CVE-2023-34362 and ships an emergency patch.2023-06-02
CISA adds CVE-2023-34362 to the KEV (Known Exploited Vulnerabilities) catalog.2023-06-06
Cl0p claims responsibility on its leak site and begins extortion.2023-06-07
CISA/FBI publish the #StopRansomware joint advisory (AA23-158A).2023→
Counts of affected orgs and people keep rising as vendor-route impact surfaces.
The root cause wasn't "one mistake" but layers failing
Filing this under "MOVEit had a bug" guarantees a repeat. In reality several layers failed in sequence.
The setup that failed (at the time)
- an appliance concentrating sensitive data, widely exposed to the internet
- mass-exploited in the zero-day, pre-patch window
- a web tier that could read the whole backing DB (weak segmentation/privilege)
- no visibility into vendors' practices, so the spread couldn't be stopped
The defended setup (prevention)
- minimize exposure (behind VPN/IP allowlist; close unused features)
- KEV fast-patching (apply actively-exploited fixes first)
- segment and least-privilege web↔DB + bulk-read detection
- vendor inventory + data minimization to shrink blast radius
Supply chain: your safety depends on 'whoever you handed it to'
The defining feature of this breach is that most victims didn't use MOVEit themselves. Because a vendor or provider they had entrusted data to (payroll, pensions, insurance) used MOVEit, their clients were dragged in down the chain (the same shape appears in the Codecov supply-chain incident). So when you hand data to a third party, ask both "what is their vulnerability practice?" and "does this data need to be handed over at all?"
Preventing a repeat in your environment
Priority-ordered fixes that work at any scale. If you have even one "internet-facing admin/file-transfer feature" or "relationship where you hand data to a third party," this is about you.
Minimize exposure (reduce the target)
Don't expose admin and file-transfer features directly to the internet where avoidable. Put them behind a VPN or IP allowlist, and close/isolate unused features and old appliances. Shrinking what an attacker can touch is the first move.
Patch KEV-listed flaws first (fast-patching)
When a product you run lands on the actively-exploited (KEV) list, apply the fix within hours to days. You can't prevent the zero-day, but slamming the post-patch window shut avoids the bulk of the damage (→ the practice of vulnerability response, the threat alerts feed).
Segment the web app from the backing DB, least privilege
So a breached public web app is contained, restrict privileges so the web tier can't read the whole backing DB, and segment the network. The real SQLi fix is placeholders, but segmentation and least privilege shrink the blast radius if something slips.
Inventory vendors and minimize the data you hand over
List who holds your data (vendors, SaaS, providers) and keep a contact path for major incidents. And minimize the data you hand over in the first place — data you never sent can't leak when they're breached.
Where this overlaps with this site's design
This site, too, is built on minimizing exposure and machine-monitoring actively-exploited (KEV) flaws to patch them fast (via its own dependency audit and threat feed). This incident is the most eloquent example of why the principles we hold in the product — narrow what you expose, kill KEV flaws first, separate layers to shrink blast radius, minimize the data you hand over — actually matter. You can't avoid the zero-day itself, but a practice that slams the post-patch window shut and a design that contains the damage when breached are implementable by anyone, at any scale.
Sources (public record)
The facts here are based on the following public information. No attack reproduction or payloads — only the defensive lessons.
- CISA / FBI, "#StopRansomware: CL0P Ransomware Gang Exploits CVE-2023-34362 MOVEit Vulnerability" (AA23-158A, 2023) — cisa.gov
- Progress Software official advisory, "MOVEit Transfer Critical Vulnerability (CVE-2023-34362)" (2023) — community.progress.com
- Mandiant (Google Cloud), "Zero-Day Vulnerability in MOVEit Transfer Exploited for Data Theft" (2023) — cloud.google.com
- Rapid7, "CVE-2023-34362: MOVEit Vulnerability Timeline of Events" (2023) — rapid7.com
Read next
- Glossary: what SQL injection is (this breach's entry, with the real fix)
- Incident: the Codecov supply-chain incident (leaking through whoever you trusted)
- In practice: the practice of vulnerability response (patch KEV first)
- Preparedness: backup and recovery (ransomware-ready)
FAQ
QWhat was the root cause of the MOVEit breach?
An unknown (zero-day) SQL injection vulnerability (CVE-2023-34362) in the internet-facing MOVEit Transfer product. Attackers exploited it to plant a web shell (a malicious remote-control program) and bulk-read stored file data from the database behind the product. The combination of mass exploitation before a patch existed, and a web tier that could read the whole backing database, made it severe.
QI don't use MOVEit — why does this affect me?
Most victims weren't MOVEit users themselves; they were pulled in because a vendor, partner, or service provider they had entrusted data to used MOVEit. This is a classic supply-chain leak: the safety of your data also depends on the patching practices of whoever you hand it to. A vendor inventory and minimizing the data you hand over both help.
QIs there anything a small service can learn?
Yes. (1) Internet-facing admin and file-transfer features are prime targets, so minimize exposure and patch anything on the KEV (actively-exploited) list within hours to days. (2) Segment the database behind a web app and restrict privileges so the web tier can't read everything. (3) Minimize the data you hand to third parties. All of this works at any scale.