Cleo’s Login Was Not a Login: Two Flaws Let Low-Privilege Users Reach RCE
Cleo Harmony verified a signed SAML response, then trusted attacker-controlled identity data from the wrong part of it. Four linked weaknesses could turn one self-registered, low-privilege account into administrative command execution.
Researchers at Armadin reconstructed the chain in Harmony 5.8.x. It crosses the SAML parser, token issuance and separate identity stores before using Cleo’s own automation engine to execute commands as the operating-system account running the service. A public exploit now shortens the path from technical disclosure to practical attack.
The signature was valid. The identity was not.
The first vulnerability, CVE-2026-84114, is an XML Signature Wrapping flaw in Cleo’s SAML service provider. Harmony could verify a legitimate signed portion of a response while reading attacker-controlled identity attributes from a different, unsigned portion.
A valid signature therefore did not guarantee that the email address used for authentication came from the signed assertion. Armadin says the application also swallowed a SAML profile-validation exception that should have caused the response to be rejected. The result was an attacker-selected identity presented through a response that still passed signature verification.
Four steps, two CVEs, one administrator shell
The complete route to command execution contains four distinct stages:
- The attacker uses the SAML wrapping weakness to assert an arbitrary identity.
- A self-registered portal account receives a token type with more authority than an ordinary user should have.
- Harmony consumes that token against a different identity store and resolves it as a higher-privileged administrator. These token and cross-store failures are tracked together as CVE-2026-84115.
- The attacker uses Cleo’s built-in Actions automation feature to run commands as the service account.
Armadin demonstrated the chain in four requests. The final Actions feature is legitimate product functionality, but reaching it as an administrator converts the authentication failure into remote code execution.
Why managed file transfer raises the stakes
Harmony is designed to move sensitive files between customers, suppliers and internal systems. It commonly holds access to transfer directories, scheduled jobs, partner connections, service credentials and integration endpoints. Administrative control can therefore expose both the files passing through the platform and the systems connected to it.
This is why managed file-transfer servers repeatedly attract ransomware and data-theft groups. They combine an internet-facing edge with trusted access to high-value internal data. An attacker does not need to compromise every downstream organisation when one transfer platform already sits inside their shared trust chain.
The fix existed before the disclosure became urgent
Both vulnerabilities were fixed in Harmony 5.8.1.11, released on 15 May 2026. Cleo’s public release notes described the build only as containing security-related improvements and did not identify the two CVEs or explain the attack chain.
That changed operationally when Armadin published its technical analysis on 2 September and exploit availability was reported publicly. No confirmed malicious exploitation had been disclosed at the time of writing, but public reproduction removes much of the safety margin for an exposed installation.
What defenders should do now
- Upgrade Harmony to 5.8.1.11 or a newer supported release, then verify that every node in the deployment is running the corrected build.
- Remove direct internet access to administrative interfaces and restrict the portal and API paths to the users and networks that require them.
- Review SAML assertions, portal registrations, token issuance and administrator sessions for unexpected identities or cross-store account mappings.
- Audit Actions, transfer jobs, destination paths, service accounts and credentials for changes that an authorised administrator did not make.
- Preserve application, identity-provider and operating-system logs before rebuilding a server that may have been exposed while vulnerable.
The bigger lesson
A signed login response is not automatically a trusted identity. The application must verify the exact assertion it later consumes, issue the correct token and keep separate identity stores from collapsing into one another. Cleo failed at several hand-offs, and the product’s legitimate automation capability magnified those authentication mistakes into an operating-system shell.
Sources: Armadin’s technical analysis, Cleo Harmony 5.8.1 release notes, and SecurityWeek’s exploit report.
