Logging Gaps That Hide Replayed MOVEit Transfer Sessions

CVE-2026-89070 is an authentication bypass by capture-replay in the OpenID Connect module of Progress MOVEit Transfer, classified CWE-294 with a CVSS v3 base score of 7.5. The affected releases run from before 2025.1.6 through 2026.0.3, with fixes in 2025.1.6 and 2026.0.4.

Detecting a replayed session is genuinely difficult, and the reason is structural rather than a matter of effort. The attacker presents material the server expects. From the application's point of view, authentication succeeded for the right reason.

What the platform log shows

The platform records that a user authenticated through OIDC at a given time from a given address, and then records what that user did. All of those entries are accurate. The user was authenticated by the configured mechanism, and the actions were permitted for that identity.

The only hint available on the platform side is behavioural. A session from an unusual source address, a download pattern that differs from the account's history, a transfer outside the normal window, or two concurrent sessions for one identity can each be a signal. None of them is proof, and each has innocent explanations.

Where the missing evidence lives

The identity provider issued the assertion that the platform accepted. Configured well, it records that issuance: the subject, the time, the application, and an assertion or token identifier.

If those records exist, detection becomes a comparison problem. An identifier used once produces one session. An identifier used twice produces two sessions, or a session the user did not initiate.

If the provider does not log identifiers, that comparison is impossible after the fact. Many deployments are in exactly that position, because default audit settings record the event without retaining the identifier.

Closing the gap

Enable identifier-level logging for the MOVEit Transfer application in the identity provider. Confirm the retention period is long enough to cover an incident investigation rather than only a compliance minimum.

Shorten assertion lifetime for this relying party. A captured assertion valid for fifteen minutes is a much smaller problem than one valid for hours, and shorter lifetimes increase the chance that a stale capture fails.

Confirm clock synchronization on both sides. Where freshness depends on timestamps, skew between the platform and the provider creates either false rejections or a wider acceptance window than intended.

What to query during an investigation

Pull provider issuance records for the MOVEit Transfer application for the exposure window. Group by subject and look for repeated identifiers. Compare the issuance timestamps against platform authentication events for the same user. Then pull transfer activity for those sessions and check it against the user's job function.

Exposure context

A ZoomEye query for the product fingerprint app="MOVEit" matches 1,676 assets at the time of writing. It identifies systems presenting the product fingerprint and says nothing about logging configuration.

References

• CVE-2026-89070 record, CVE.org
• Progress MOVEit Transfer Critical Security Bulletin, Progress Community
• Progress Software Patches Twelve High-Severity MOVEit Transfer Vulnerabilities, SecurityOnline

Disclaimer

Exposure figures cited here come from a ZoomEye query for the product fingerprint and describe matching assets, not confirmed vulnerable hosts.