Managed file transfer software keeps producing headline-grade breaches because it sits at the exact point a ransomware crew wants to be: at the edge, authenticated to partner networks, and entrusted with the data leaving the building. CVE-2024-55956 in Cleo Harmony, VLTrader, and LexiCom was the 2024 entry in that lineage, and Clop moved from patch to production exploitation in days. This post lays out what the bug is, how it differs from the closely-related CVE-2024-50623, and what the incident tells us about MFT security posture going into 2026.
What is CVE-2024-55956 and how is it different from CVE-2024-50623?
CVE-2024-55956 is an unauthenticated file-write-plus-execution vulnerability in Cleo's autorun directory handling that allows a remote attacker to drop and run arbitrary code. It is structurally similar to CVE-2024-50623, which Cleo had already patched in October 2024, but 55956 targets a distinct code path that the October fix did not close. In practical terms, the 50623 patch bought about six weeks before researchers and attackers found the adjacent bypass.
Huntress published the initial analysis on December 9, 2024, describing active exploitation against fully patched Cleo instances. Cleo acknowledged the bypass and shipped a hardened release (5.8.0.24) on December 11. The CVE itself was assigned retroactively on December 13. That sequence - public exploitation first, vendor acknowledgement second, CVE third - is now the norm for MFT bugs and is the shape defenders should plan around.
Affected products include Cleo Harmony, Cleo VLTrader, and Cleo LexiCom, all prior to 5.8.0.24. These are the same product line exploited in the earlier disclosure, and many deployments received the October patch only to be re-exploited via 55956 in December.
How does the exploit chain work at a technical level?
The exploit chain works by abusing Cleo's autorun directory feature to land an attacker-supplied file that the service then executes without verification. The Cleo services watch specific filesystem paths for incoming work units. A crafted HTTP request to the product's web listener writes a file into a directory that is processed on a timer, and the payload is executed with the privileges of the Cleo service account, which on default Windows installs is NT AUTHORITY\SYSTEM.
The payloads observed in the wild were staged in two phases. First, a small Powershell or XML autorun artifact established in-memory control. Second, a Java-based loader known by Huntress as "Malichus" pulled down additional modules, enumerated the host, and began staging the Cleo data store for exfiltration. Clop's affiliates appear to have favored the VLTrader variant because of its role in high-volume EDI workflows, which meant the data already transiting the host was what the crew wanted.
One useful detail from the post-mortems: the vulnerability did not require the web listener to be internet-facing on a standard port. Instances bound to non-default ports or placed behind a reverse proxy were still exploitable because the autorun path depended on the TCP listener's authentication bypass, not on the URL structure.
Who was affected and what was the impact?
More than 60 organizations were publicly named on Clop's leak site in connection with Cleo exploitation between mid-December 2024 and February 2025, with the real count almost certainly higher. Named victims spanned retail, logistics, manufacturing, and financial services. Because Cleo sits between partners, the breach of a single hub often implicated dozens of downstream counterparties whose files were staged on the compromised host.
The post-mortems published by victims follow a consistent shape. Attackers held access for several days before any ransomware or leak activity, used that window to enumerate partner directories, and exfiltrated whatever was resident in the MFT inbox and outbox at the time of intrusion. A few victims reported that older archive data remained on the host for retention reasons, which expanded the scope of disclosure obligations significantly.
The financial impact is harder to quantify publicly, but several named firms disclosed incident costs in the tens of millions in their subsequent earnings filings. Regulators in the US and EU opened inquiries into notification timelines, and at least one class action cited the Cleo incident as the predicate.
What detection opportunities existed?
Detection was possible if defenders were already collecting process-lineage and file-write telemetry on the Cleo hosts, but most were not. The signals that distinguish benign autorun activity from exploitation are:
- Unexpected child processes of the Cleo service (
java.exe,cmd.exe,powershell.exe) outside the product's normal workflow. - New files appearing in the autorun directory with names or extensions that do not match configured trading partners.
- Outbound HTTPS from the Cleo host to IPs outside the partner allowlist, especially low-reputation hosting providers.
- PowerShell invocations with encoded command-line flags originating from the Cleo service account.
Huntress published YARA rules and specific filename indicators within 48 hours of the initial disclosure. Defenders who had already integrated those rules into their EDR caught second-wave exploitation. Defenders who relied on perimeter signatures generally did not, because the web-layer traffic looked like routine Cleo protocol chatter.
A useful retrospective exercise: if you run any MFT product, spend an hour verifying that your telemetry would actually generate an alert for an unexpected child process of the MFT service binary. This is a cheap test and it is routinely negative on first run.
Why does managed file transfer keep producing this class of bug?
Managed file transfer keeps producing this class of bug because the products live at the intersection of three difficult properties: they accept untrusted input by design, they execute content on a schedule, and they run with high privilege because their job is to read and write across security boundaries. MOVEit, GoAnywhere, Accellion FTA, and now Cleo have all demonstrated variations of the same failure mode over the last five years.
The design pattern shared across these products is "watch this directory, run what arrives," which is a reasonable abstraction for trusted partners moving files but becomes a remote code execution primitive the moment authentication is bypassed or weakened. Hardening individual parsers only buys time. The structural fix is to isolate the execution tier from the ingest tier and require cryptographic validation of any unit of work before it leaves the quarantine path.
Few products in this category have actually done that. Until they do, the defensive burden sits with the operator, which means compensating controls like application allowlisting, service-account hardening, and aggressive egress restrictions are not optional on MFT hosts.
What should engineering teams do now?
Engineering teams running Cleo products should confirm they are on 5.8.0.24 or later, assume any pre-patch exposure resulted in compromise, and structurally segment the MFT tier as a hostile environment going forward. Specific actions worth taking this quarter:
- Pull the Cleo hosts onto a dedicated VLAN with explicit egress allowlists and no outbound access to commodity CDNs.
- Run the Cleo services as a non-privileged, per-host account rather than a domain-joined shared account. If the host is Windows and the product supports it, remove
SeDebugPrivilegefrom that account. - Rotate every credential and key stored in the Cleo configuration, including partner SSH keys and AS2 certificates. If the host was vulnerable, treat the entire credential store as disclosed.
- Instrument file-write and process-create events in the autorun directories with high-priority alerts. These directories are not places humans edit files routinely, so the false-positive floor is low.
- Build a rehearsed fallback for MFT outages. The next bug in this class will happen, and your downstream partners will appreciate a tested failover.
How Safeguard.sh Helps
Safeguard.sh reachability analysis would have pinpointed the Cleo hosts where the autorun code path was actually invokable and filtered out the unreachable instances, cutting CVE-55956 noise by 60 to 80 percent so remediation effort landed on real exposure first. Griffin AI autonomous remediation can stage version upgrades with rollback, disable the autorun workflow as an interim control, and track completion across every Cleo host in the estate without manual ticket shuffling. Eagle malware classification fingerprints the Malichus loader and related Clop artifacts against known families, SBOM generation with 100-level dependency depth keeps the Java components inside Cleo visible so the next adjacent bypass does not arrive unannounced, container self-healing restores clean instances after compromise, and TPRM surfaces the same exposure across vendors running Harmony, VLTrader, or LexiCom in your supply chain.