MOVEit, GoAnywhere, Cleo — The File-Transfer Pattern That Keeps Working

If you sell software that moves regulated files between large companies, you ship a bundle that has the same shape every time: a public-internet-facing admin console for tenant management, a serialized-object protocol for inter-process communication, a customer-facing API surface that accepts complex object inputs from authenticated users, and a Java or .NET runtime underneath. Three different vendors, all hit by Cl0p, all shipping that same bundle. The fourth shipment is already in production somewhere.

This isn't a coincidence and it isn't bad luck. It's a pattern. Once you see it, you can find the next vulnerability before the CVE drops.

What happened

Three campaigns, three vendors, three CVEs — and an architectural anti-pattern that links them.

Cl0p is the ransomware affiliate program that found and operationalized all three. By their own count and corroborating victim disclosures, the three campaigns combined hit more than 2,700 organizations — payroll providers, hospitals, state agencies, banks, universities, supply-chain manufacturers. The damage profile in each case was identical: bulk exfiltration of every file the MFT product had ever brokered, followed by extortion against every downstream organization whose data was in the dump.

The vendors are unrelated companies on different stacks. Progress MOVEit was a .NET stack. Fortra GoAnywhere was Java. Cleo was a Java stack with proprietary connector code. Different developers, different release cycles, different code review processes. Same architectural shape, same class of bug, same attacker.

Why it kept working

The MFT product class shares four properties that combine to produce this exact pre-auth RCE pattern:

1. Internet-facing admin plane. Customers expect to be able to administer their MFT remotely. So the admin console listens on the public internet, usually on TCP/443 or a high port. That's the first principle of the attack surface: there's a management endpoint that has to accept connections from anywhere.

2. Serialized-object protocols. MFT products were built in the era when Java serialization (or .NET BinaryFormatter, or YAML !ruby/object) was the default way to pass complex objects between processes. The license servlet, the autorun handler, the connector framework — these are all places where an HTTP body or file gets deserialized into a live object. Deserialization of attacker-controlled bytes into live objects has been a known unsafe pattern since 2015. It still ships.

3. Trusted-partner accept-anything API design. MFT vendors are selling B2B integration. The whole point of the product is to accept complex inputs from a partner and translate them into actions. So the API design philosophy is permissive by default. Endpoints accept large structured bodies. Schemas are loose. Optional fields proliferate. That's the developer mindset that produces "let's just deserialize the whole request body and figure out what it is afterwards."

4. Long-lived, slow-to-patch deployments. An MFT box at a payroll processor is part of every day's batch job. Patching it requires coordinated downtime with every customer. Customers run versions that are 18 to 36 months behind current. That gives Cl0p a wide patch-gap window and a soft re-exploitation window after a CVE drops. The Cleo campaign in December 2024 successfully exploited a vulnerability that had been silently patched two months prior — the patch was incomplete, but more importantly, almost nobody had applied it.

You don't need to be a brilliant attacker to find the fourth one. You need to identify the universe of products with the same four properties, fingerprint the management plane, find the deserialization sink, and weaponize. Cl0p has been running this playbook against MFT vendors specifically since at least 2021. The next vendor is on their list right now.

What to check today

If you operate an MFT, or any product that has the four properties above, here is the work that pays off before the next CVE.

1. Inventory every internet-facing management plane. Anything that listens on a public IP and serves an admin UI, an admin API, or a partner-integration endpoint. Yes, including the ones a vendor or MSP put there. Yes, including the box you forgot you had.
2. Fingerprint the framework underneath. Java with Apache Commons Collections on the classpath? .NET with BinaryFormatter or DataContractSerializer? Python with pickle? Ruby with Marshal? YAML with safe_load not actually being used? These are the deserialization sinks. If you can fingerprint them remotely, an attacker definitely will.
3. Move the management plane behind a VPN or an identity-aware proxy. The admin console does not need to be reachable from arbitrary internet IPs. None of the three CVEs above would have produced a 2,700-org incident if the management plane had been behind a per-tenant identity-aware proxy. This is the single highest-leverage mitigation in the entire pattern.
4. Audit your code for deserialization of attacker-controlled input. If your codebase has BinaryFormatter.Deserialize, ObjectInputStream.readObject, pickle.loads, yaml.load (without SafeLoader), or Marshal.load on a path reachable from an unauthenticated HTTP handler, that is the bug. Treat it as critical and fix it. The vendor patches for CVE-2023-0669 and CVE-2024-50623 were both "stop deserializing this." If their developers had spotted the sink, the patch would have been the same patch six months earlier and the campaign would not exist.
5. Subscribe to the CISA Known Exploited Vulnerabilities catalog and pre-stage your MFT patching playbook. The Cl0p MFT campaigns averaged less than 10 days from CVE assignment to mass-exploitation. You don't have time to design the change-control process during the incident.

The "find the next CVE" exercise

Detection of the pattern doesn't require a vulnerability disclosure. Three signals, in combination, identify a candidate:

1. Banner / TLS-fingerprint match. The product identifies itself in HTTP Server headers, in the favicon hash, in the JavaScript bundle, in the unique ports it exposes (e.g. Cleo's autorun directory was reachable on port 5080). Build a fingerprint database for every commercial MFT in the market.
2. Endpoint surface includes a deserialization-shaped sink. Endpoints that take POST bodies with Content-Type: application/x-java-serialized-object, or that accept .ser file uploads, or that have query parameters named license, config, state, or session with base64-encoded blob values, are candidate sinks. Even an HTTP 500 on a malformed input that mentions "ObjectInputStream" or "BinaryFormatter" in the stack trace is enough to confirm.
3. Long-lived, lightly-patched deployments. If shodan/censys queries against the product's fingerprint return a substantial population of hosts running versions more than 12 months out of date, that's the prerequisite for a mass-exploitation event.

The intersection of those three signals is where the next CVE will land. We've been running this exercise across the MFT vendor universe since the Cleo campaign and we have a watchlist of products that match all three criteria today. We're not going to publish the watchlist here, but the methodology above is enough for any defender to build their own.

How CELVEX Group tests for this

Test INFRA-MFT-DESERIALIZATION-PATTERN-001 in core/test_catalog/_supplement_pattern_analysis_2026-03.py implements the three-signal detection above. For every customer perimeter, the test fingerprints the framework underneath every internet-facing HTTP service, identifies any service whose banner or favicon matches a known MFT product (we maintain a database of 31 commercial MFT products and their fingerprints), probes the management plane for endpoints that accept serialized object content types, and cross-references against current and historical CVE data for that product family.

Output is a single ranked list. "You have a Cleo Harmony box on the public internet running version 5.8.0.21" is a paging-grade alert. "You have a candidate MFT box that fingerprints as $vendor and exposes a deserialization-shaped endpoint" is a triage-grade alert — usually worth confirming with the vendor and confirming whether the endpoint is reachable without authentication. The test runs nightly for every customer subscribed to the Infrastructure tier and on every external-perimeter Exposure Check.

The point is that this work doesn't have to wait for the next CVE. The pattern is published. The fingerprints are findable. The next campaign is on a vendor whose developers are reading this paragraph thinking "we don't deserialize attacker input." They probably do. Most of them did, in the previous three.

Bottom line

Cl0p has demonstrated, across three vendors and three years, that the managed-file-transfer product class has a structural weakness independent of any individual vendor's code review process. The architectural shape — internet-facing admin plane plus serialized-object protocols plus permissive partner-API design plus slow patch cadence — produces pre-auth RCE bugs at a rate that's high enough to support a continuous ransomware campaign business.

The right reaction is not to shrug. The right reaction is to assume the next campaign is already in progress against a vendor whose patch is being written today, accept that you cannot tell ahead of time which vendor it will be, and harden the architectural property that's actually broken: the internet-facing management plane. Move it behind a VPN or an identity-aware proxy. The CVE will still happen. Your incident will not.