MOVEit Transfer OIDC capture-replay bypass CVE-2026-89070 fixed in 2025.1.6 and 2026.0.4

The vulnerability

Progress MOVEit Transfer is patching a capture-replay authentication bypass in its OpenID Connect module, tracked as CVE-2026-89070. According to a dev.to write-up, the flaw is classified under CWE-294 and carries a CVSS v3 base score of 7.5. Affected releases span everything earlier than 2025.1.6 through 2026.0.3; the fixed versions are 2025.1.6 and 2026.0.4.

The same write-up, referencing a SecurityOnline report, notes that the OIDC bug was one of twelve high-severity MOVEit Transfer vulnerabilities Progress patched in the same batch.

Why platform logs miss it

The core problem, the post argues, is structural rather than a matter of effort. An attacker replaying captured authentication material presents exactly what the server expects to see, so from the application's point of view the login was legitimate. The platform log records that a user authenticated through OIDC at a particular time from a particular address, then records what that user did. Every entry is accurate, and none of them distinguishes a replay from a genuine session.

The only signals available on the platform side are behavioral, and each is ambiguous: a session from an unfamiliar source address, a download pattern that deviates from the account's history, a transfer outside normal working hours, or two concurrent sessions under a single identity. None of these proves anything, and all have innocent explanations.

The evidence sits with the identity provider

The identity provider is the party that issued the assertion the platform accepted. Configured well, the dev.to post explains, it records the issuance: the subject involved, when it happened, the application it was issued for, and an assertion or token identifier.

That turns replay detection into a comparison problem. An identifier used once should correspond to exactly one session. An identifier that shows up twice, producing two sessions or a session the user never initiated, points to a replay. The catch is that many deployments log the authentication event without retaining the identifier, which makes that comparison impossible after the fact.

Hardening steps

The post recommends four measures:

• Enable identifier-level logging for the MOVEit Transfer application in the identity provider.
• Verify that log retention covers a realistic investigation window rather than a bare compliance minimum.
• Shorten assertion lifetimes for this relying party. A captured assertion valid for fifteen minutes is far less useful to an attacker than one valid for hours, and shorter windows raise the odds that a stale capture simply fails.
• Confirm clock synchronization between the platform and the provider. Where freshness checks depend on timestamps, skew either produces false rejections or widens the acceptance window beyond what was intended.

What to query during an investigation

For teams trying to determine whether a replay occurred before they patched, the post lays out a sequence: pull the provider's issuance records for the MOVEit Transfer application across the exposure window; group them by subject and search for repeated identifiers; compare issuance timestamps against the platform's authentication events for the same users; then pull the transfer activity from those sessions and check it against each user's actual job function.

Exposure context

A ZoomEye query for the product fingerprint app="MOVEit" matched 1,676 assets at the time of writing, according to the post. The author is careful with that figure: it counts systems presenting the fingerprint and says nothing about which are vulnerable or how their identity providers are configured.

Why it matters

The patch closes the hole, but it does not answer the question security teams will face next: did anyone exploit it while it was open? For most deployments, the platform's own logs cannot answer that. Whether an organization can even investigate a suspected replay depends entirely on whether its identity provider retained assertion identifiers, a setting many leave at defaults that discard them. Teams running MOVEit Transfer should treat the upgrade and the identity-provider logging review as a single action item, because discovering after an incident that the evidence was never collected is the worst possible timing.