Is CVE-2023-34362 (Progress MOVEit Transfer SQL Injection) being exploited in the wild?

Yes. CISA added CVE-2023-34362 to its Known Exploited Vulnerabilities catalogue on 2 June 2023, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Progress MOVEit Transfer contains a SQL injection vulnerability that could allow an unauthenticated attacker to gain unauthorized access to MOVEit Transfer’s database.

What “exploited in the wild” means for CVE-2023-34362

For this CVE, “exploited in the wild” means there is credible evidence that attackers were actively using the moveit transfer sql injection flaw before or during public disclosure. The practical question is not whether the bug is real, but whether exposure should be treated as an active incident-response issue rather than a routine patch item. That changes urgency, triage, and post-fix verification.

The first step is to confirm whether any MOVEit Transfer instance is internet-facing, reachable from partner networks, or present in a shared hosting or managed-service footprint. If the product is present, assume exploitability matters immediately, because unauthenticated SQL injection against a file-transfer platform can expose both application data and connected database content. Use the vendor advisory and the CISA Known Exploited Vulnerabilities Catalog to verify the authoritative status and response expectations.

Once active exploitation is confirmed, patching is only part of the response. Teams should treat the affected system as potentially exposed to data theft or follow-on abuse, especially where the application stores customer files, integration credentials, or operational records. That is why confirmed exploitation in a file-transfer product often triggers both remediation and compromise assessment, rather than patching alone.

Why this MOVEit flaw was operationally serious

The vulnerability type matters here: SQL injection is dangerous because it can let an attacker submit crafted input that alters database queries. In a managed file-transfer product, that can become a direct path to unauthorized database access, metadata disclosure, and broader application compromise. The risk is amplified when the product sits at a trust boundary between internal systems, external users, and business partners.

What made this class of issue especially urgent is the combination of unauthenticated access and the likelihood of rapid exploitation after disclosure. For practitioners, that means a vulnerability scan result is not enough. Exposure must be interpreted through asset criticality, external reachability, and whether the application handles sensitive files or credentials. The CVE Program record identifies the issue consistently across tools and advisories, while the NIST National Vulnerability Database is the usual reference for record-level details and cross-vendor tracking.

For defensive triage, this is the kind of flaw where “we have not observed alerts” is not reassuring by itself. Web application exploitation can leave limited immediate telemetry, and database-layer access may occur before obvious service disruption appears. That makes the issue a classic example of why exploitation status changes the operational priority even when the system still seems to function normally.

What to do when exposure is confirmed

The response sequence should be: confirm whether the product is present, determine whether the vulnerable version is exposed, apply the vendor fix or mitigation path, then review for signs of compromise. If patching must wait, isolate the instance, restrict network reachability, and preserve logs and system state for forensic review. The objective is to reduce further access while protecting evidence.

If the platform may have been touched by attackers, check for abnormal database activity, unexpected administrative changes, webshell-style artefacts, new accounts, strange outbound connections, and any unusual file export or archive creation. Where MOVEit was used to handle partner data or automated transfers, also review upstream and downstream systems that may have consumed stolen data or received tampered files. Compromise assessment should be specific, not generic.

In environments where the application integrates with service accounts, downstream databases, or external transfer workflows, rotate any credentials or secrets that could have been exposed through the application path. That is especially important when the system contains stored connection strings, API tokens, or privileged database access used for automation. The Zero-Day and Exploited Vulnerabilities Guide and the Vulnerability Management Guide are useful for the response pattern, prioritisation, and post-patch validation.

Risk and Threat Considerations

When a file-transfer product is exploited in the wild, the immediate risk is not just service disruption, it is data exposure and potential downstream abuse of any trust relationships connected to the platform. SQL injection can give an unauthenticated attacker a path into the database layer, which may expose records, stored secrets, or integration details that support later movement.

Failure mechanism: Crafted input alters backend queries, allowing unauthorized database interaction and, in some deployments, broader application compromise or data theft before operators notice anomalous behaviour.

Impact: Sensitive files, customer records, operational metadata, and related credentials may be exposed, and the organisation may need both incident response and credential rotation rather than a simple patch cycle.

Standards & Framework Alignment

This section maps relevant standards and security frameworks to the operational risks and controls described in this guidance.

NIST CSF 2.0, NIST SP 800-53 Rev 5, CIS Controls v8 and OWASP ASVS set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Vulnerability Risks Are Identified and Recorded	A KEV-listed exploit requires explicit vulnerability risk awareness and tracking.
Recommendation — Track KEV-listed exposure and update remediation priority immediately.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	The question centers on exploiting a software flaw that must be remediated and verified.
	IR-4 — Incident Handling	Confirmed wild exploitation can require incident handling, evidence preservation, and compromise assessment.
Recommendation — Apply SI-2 to remediate the flaw and verify the fix. Invoke IR-4 to assess compromise and preserve evidence before disruptive cleanup.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	Actively exploited CVEs require asset scoping, prioritisation, and remediation tracking.
Recommendation — Use CIS-7 to find exposed instances and drive rapid remediation.
OWASP ASVS	V4 API and Web Service — API and Web Service	SQL injection against a web service reflects core API/web service input-handling risk.
Recommendation — Review service inputs and query handling under V4 to block injection paths.

Practitioner Guidance

What to verify: Confirm whether MOVEit Transfer is internet-facing, externally reachable through partners, or connected to sensitive databases or automation accounts. If those conditions are true, treat exploitation risk as materially higher and move it ahead of routine maintenance work.

Decision rule: If the instance could have processed sensitive transfers before remediation, do not stop at patching. Validate logs, inspect for tampering, and decide whether related credentials, sessions, or integration secrets should be rotated because they may have been exposed through the application path.

Practitioner takeaway: For a KEV-listed SQL injection in a transfer platform, the right question is not only “is it patched?”, but “what trust relationships and stored access material might have been exposed before we contained it?”