CISA’s required action for CVE-2023-34362 is to apply updates per vendor instructions. In practice, find every instance of Progress MOVEit Transfer in your estate, apply the vendor security update or documented mitigation, and if no fix can be applied, remove internet exposure or take the product out of service. After patching, review logs for signs of earlier exploitation, because attackers used this flaw in the wild.
What to do first when MOVEit Transfer is exposed
Start by confirming every internet-facing and internal instance of Progress MOVEit Transfer, because mitigation only works if you have a complete asset view. Use the vendor advisory and CISA KEV entry as the source of truth for the exact update or workaround path, then apply the vendor security update or documented mitigation everywhere it is installed. If you cannot remediate promptly, remove internet exposure or take the service out of operation.
For a CVE that was actively exploited in the wild, the practical question is not whether the application “should” be patched, but whether any reachable instance can still be used as an entry point. The shortest safe path is to reduce exposure first, then restore service on a known-good build.
When a flaw is already being exploited broadly, prioritising by business criticality alone is usually the wrong order. Exposure and exploitability matter more than convenience, so focus on the systems that are externally reachable, mission-critical, or difficult to isolate first.
How to verify the fix is actually in place
After remediation, verify that the update or mitigation was applied to each instance and that no alternate path still leaves the server exposed. That includes checking load balancers, reverse proxies, and any internet-exposed clone or standby system that might have been missed during the initial inventory. For patching decisions, the CISA Known Exploited Vulnerabilities Catalog is the operational reference for why this issue should be treated as urgent, while the CVE Program record anchors the vulnerability identity itself.
Because the direct answer points to vendor instructions rather than a universal fixed-version rule, the safest practice is to validate against the vendor’s exact guidance rather than relying on memory, change tickets, or a generic patch window. If the product is still online, confirm the mitigation is effective under real network conditions, not just in a maintenance note.
After the fix, re-test the application path that attackers would have used. In practice that means confirming the vulnerable endpoint is no longer reachable, the service behaves as expected, and the server is not simply “patched on paper.”
What to check after patching or shutdown
Even when remediation is complete, the response is not finished until you review logs for evidence of earlier exploitation and determine whether the system was used before the fix landed. This is especially important for internet-exposed file transfer products because exploitation can be quiet, fast, and followed by credential theft or data staging. The Zero-Day and Exploited Vulnerabilities Guide is useful here because it covers KEV triage, emergency mitigation, and post-patch hunting in the same response workflow.
Check for unusual file creation, unexpected archives, new web shells, modified application files, suspicious child processes, or outbound transfers that do not fit normal MOVEit activity. If the logs suggest access before remediation, treat the issue as a possible compromise investigation, not just a patching exercise.
If evidence shows the server was accessed or sensitive data may have been exposed, reset any credentials, sessions, or integration secrets that passed through the system. For exposed transfer platforms, this is often the difference between closing the vulnerability and closing the incident.
Risk and Threat Considerations
This kind of flaw is risky because a network-reachable SQL injection in a transfer platform can be converted into rapid data access, persistence, or follow-on intrusion before defenders have time to respond. The main exposure is not only the vulnerable product, but the trust placed in it as a boundary for external file exchange and privileged data movement.
Failure mechanism: Attackers can use the SQL injection path to bypass normal application controls, reach backend data, and potentially stage or extract information before remediation is complete. If the server remains internet-facing, the exploit path stays available even when the organisation knows the CVE exists.
Impact: The result can include data theft, further compromise of adjacent systems, or loss of confidence in the transfer service as a trusted ingress and egress point. In some environments, the downstream cost is higher than the vulnerability itself because the platform also handles sensitive business files and related credentials.
Standards & Framework Alignment
This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.
CIS Controls v8, NIST CSF 2.0 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.
| Framework | Control / Reference | Relevance |
|---|---|---|
| CIS Controls v8 | CIS-7 — Continuous Vulnerability Management | Actively exploited CVEs require asset scope, patching, and verification. |
| Recommendation — Prioritise and verify remediation for every reachable MOVEit instance. | ||
| NIST CSF 2.0 | PR.IP-12 — Vulnerability Management Plan | The question is about patching and mitigation workflow for a known exploited vulnerability. |
| Recommendation — Execute a documented vulnerability response process and track remediation to closure. | ||
| NIST SP 800-53 Rev 5 | SI-2 — Flaw Remediation | Directly governs applying vendor fixes and mitigations for software flaws. |
| RA-5 — Vulnerability Monitoring and Scanning | Supports locating all MOVEit instances and checking for exposure. | |
| IR-4 — Incident Handling | Post-patch log review and compromise assessment are part of incident response when exploitation is possible. | |
| Recommendation — Apply the vendor update or mitigation and validate the remediation. Scan for every deployment and confirm no exposed instance remains. Investigate logs and indicators of compromise after remediation. | ||
Practitioner Guidance
What to prioritise: Treat external exposure as the first decision point. If you cannot patch immediately, reduce reachability before you spend time on lower-priority cleanup tasks.
What to verify: Confirm there are no unmanaged MOVEit instances, no exposed standby systems, and no drift between the state you patched and the state actually serving traffic. Then verify logs for pre-remediation indicators of access or staging.
Decision rule: If the system may have been reachable during the exploitation window, assume compromise is possible until your log review and file integrity checks prove otherwise. If sensitive transfers or credentials flowed through it, expand the review to adjacent systems and secrets.
Practitioner takeaway: For actively exploited transfer-platform CVEs, the correct sequence is exposure reduction, vendor-directed remediation, and compromise hunting, in that order.
Related resources from NHI Mgmt Group
- CVE-2023-34362 (Progress MOVEit Transfer SQL Injection)
- How do you patch or mitigate CVE-2023-46748 (F5 BIG-IP Configuration Utility SQL Injection)?
- How do you patch or mitigate CVE-2024-29824 (Ivanti Endpoint Manager (EPM) SQL Injection)?
- How do you patch or mitigate CVE-2020-5722 (Grandstream Networks UCM6200 Series SQL Injection)?