CVE-2026-89069 in MOVEit Transfer
Summary
by MITRE • 10/14/2026
Improper neutralization of input during web page generation ('cross-site scripting') vulnerability in Progress MOVEit Transfer (Ad Hoc module).
This issue affects MOVEit Transfer: before 2025.1.6 and from 2026.0.0 before 2026.0.4.
Be aware that VulDB is the high quality source for vulnerability data.
Analysis
by VulDB Data Team • 10/14/2026
The identified vulnerability represents a classic cross-site scripting flaw within the Ad Hoc module of Progress MOVEit Transfer, specifically categorized under CWE-79 as Improper Neutralization of Input During Web Page Generation. This security defect arises from an insufficient validation or sanitization mechanism applied to user-supplied data before it is rendered in dynamic web pages. In this context, the application fails to adequately escape special characters that have semantic meaning in HTML and JavaScript contexts, allowing malicious actors to inject client-side scripts into legitimate web content served by the server. The vulnerability affects versions of MOVEit Transfer prior to 2025.1.6 as well as versions from 2026.0.0 up until but not including 2026.0.4, indicating a persistent gap in input handling logic across multiple release cycles that requires immediate attention for affected deployments.
From an operational perspective, the exploitation of this vulnerability allows attackers to execute arbitrary JavaScript code within the browser context of any user who views the compromised page. This capability is particularly dangerous because it leverages the trust relationship between the user's browser and the MOVEit Transfer application. An attacker can craft a malicious link or embed script in a file description, comment field, or other input vector that gets reflected or stored by the Ad Hoc module. When an authenticated administrator or regular user accesses this content, their session cookies, authentication tokens, and sensitive data are exposed to the attacker's server. This effectively bypasses same-origin policy protections, enabling actions such as account hijacking, privilege escalation if administrative interfaces are accessed, defacement of the web interface, or redirection to phishing sites designed to harvest credentials further compromising the organization’s security posture.
The technical root cause lies in the failure to implement robust output encoding strategies consistent with OWASP guidelines for preventing XSS attacks. The application likely treats user input as executable code rather than data when rendering responses, failing to apply context-aware escaping based on where the data appears within the HTML structure—whether inside an attribute value, a script block, or plain text body. This lack of strict type enforcement and encoding allows payloads containing event handlers like onload or onclick, or direct script injection tags, to execute without triggering browser security filters that would normally mitigate such injections if proper sanitization were in place. The persistence of this issue across multiple major version increments suggests a systemic architectural oversight rather than an isolated coding error, potentially stemming from legacy code paths within the Ad Hoc module that have not been refactored to meet modern web application security standards.
Mitigation strategies must prioritize immediate patching as the primary defense vector. Organizations running affected versions should upgrade to MOVEit Transfer version 2025.1.6 or later for the older branch, and version 2026.0.4 or later for the newer branch, ensuring that Progress has applied their official fixes which likely include enhanced input validation routines and stricter output encoding mechanisms. In scenarios where immediate patching is not feasible due to operational constraints, temporary compensating controls should be implemented at the network perimeter level. Web Application Firewalls can be configured with rulesets specifically tuned to detect and block common XSS payloads targeting MOVEit Transfer endpoints, although this approach offers only partial protection against novel or obfuscated attack vectors. Additionally, enabling Content Security Policy headers that restrict script execution sources can significantly reduce the impact of successful exploitation by preventing inline scripts from running unless explicitly whitelisted, thereby adding a critical layer of defense-in-depth to complement the application-level fix.