CVE-2023-34362: MOVEit Transfer unauthenticated SQL injection

CVE-2023-34362 is an unauthenticated SQL injection in the HTTP/S web application of Progress MOVEit Transfer. NVD records that the flaw can expose the MOVEit database and, depending on whether the deployment uses MySQL, Microsoft SQL Server, or Azure SQL, permit SQL statements that read, alter, or delete database data. NVD scores it CVSS 3.1 9.8 critical.

This is not a patch-only event. CISA added the CVE to the Known Exploited Vulnerabilities catalog on June 2, 2023 (required action due June 23, 2023) and currently records known ransomware campaign use. Rechecked against that CISA KEV JSON entry on 2026-08-21. Its joint advisory with the FBI says CL0P began exploiting the previously unknown flaw by May 27, installed the LEMURLOOT web shell on internet-facing MOVEit systems, and stole data. We must therefore separate two questions: whether the installed release is fixed, and whether an exposed system was already compromised before it was fixed.

I reviewed the public Progress advisory, release notes, patch FAQ, CISA KEV entry and incident advisory, and the NVD record. I did not inspect MOVEit's proprietary source, execute an exploit, or test a live appliance. This recipe does not assert undocumented endpoint or query details and intentionally contains no exploit payload.

Affected versions and fixed release trains

Progress release notes identify these original CVE-specific hotfix floors:

MOVEit Transfer train	Affected CVE-2023-34362 releases	Initial CVE-specific fix
2023.0 / 15.0	2023.0.0	2023.0.1 / 15.0.1
2022.1 / 14.1	Earlier than 2022.1.5	2022.1.5 / 14.1.5
2022.0 / 14.0	Earlier than 2022.0.4	2022.0.4 / 14.0.4
2021.1 / 13.1	Earlier than 2021.1.4	2021.1.4 / 13.1.4
2021.0 / 13.0	Earlier than 2021.0.6	2021.0.6 / 13.0.6
2020.1 / 12.1	Earlier than 2020.1.6	Progress documented a 2020.1.6 hotfix; confirm the currently supported package and upgrade path with Progress Support
2020.0 / 12.0 and older	All releases, including unsupported versions	No durable legacy destination; upgrade to a supported release through a Progress-approved path

These versions are historical minimums for CVE-2023-34362, not recommended new deployment targets. Progress disclosed separate MOVEit SQL injection vulnerabilities in June 2023 and subsequently directed customers to later patches and service packs. For remediation now, install the latest cumulative, vendor-supported release available for the approved upgrade path. Do not stop at an initial May 31 hotfix merely because a scanner clears this one CVE.

MOVEit Cloud was patched by Progress. Cloud customers should verify the provider notice and review tenant audit evidence; they should not attempt an on-premises installer change.

Evidence note: NVD prose and Progress release notes name the initial fixes above. Live NVD Transfer CPE excludes 2021.0.7 / 2021.1.5 / 2022.0.5 / 2022.1.6 / 2023.0.2. Those are one hotfix later than vendor 2021.0.6 / 2021.1.4 / 2022.0.4 / 2022.1.5 / 2023.0.1. Live GHAD GHSA-hq22-q5g8-577g has vulnerabilities empty. Do not invent a first_patched from that empty list. Do not resolve the NVD-versus-vendor split with a scanner suppression. Record the exact build, the current Progress-supported release, the scanner observation, and the vendor evidence in TRIAGE.md; a current cumulative Progress release avoids relying on either historical boundary.

Indicator of exposure

A vulnerable installation is not automatically a reachable installation. The known vulnerable path is the MOVEit Transfer web application over HTTP or HTTPS. Exposure requires all of the following:

• MOVEit Transfer is in an affected train or its exact build cannot be proven.
• HTTP/S reached the MOVEit web application through IIS, a reverse proxy, a load balancer, a WAF, a VPN, or an internal network during the vulnerable period.
• The source network included an untrusted actor, compromised partner, or compromised internal host.

An SFTP- or FTPS-only path does not itself establish reachability to this web flaw, but it does not make the installed release safe. Keep HTTP/S closed until the application is patched and the exposure decision is documented. Current isolation also does not erase earlier internet or partner exposure.

Read-only Windows inventory can start with the installed-product records:

$uninstall = @(
  'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall\*',
  'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall\*'
)
Get-ItemProperty -Path $uninstall -ErrorAction SilentlyContinue |
  Where-Object DisplayName -Match '^MOVEit Transfer' |
  Select-Object DisplayName, DisplayVersion, InstallDate, InstallLocation

Corroborate that result with the MOVEit administration UI, installer history, node inventory, and Progress release notes. Do not infer a safe version from a file timestamp or from only one node of a web farm.

Compromise indicators and assessment

CISA's MOVEit incident advisory describes LEMURLOOT activity and provides the maintained IOC set and defensive YARA material. High-signal observations include:

• an unexpected human2.aspx file or associated compiled ASP.NET artifact;
• HTTP telemetry containing X-siLock-Comment or X-siLock-Step* header names, when the logging stack captured request headers;
• an unexpected privileged account represented as Health Check Service;
• unexplained account creation or deletion, large or unusual downloads, access to dormant tenants, or database changes during the exposure window;
• CISA-listed file hashes or network indicators in EDR, proxy, WAF, IIS, or SIEM data.

Search the actual configured web root and log locations. Do not assume every installation uses a default path. The following shape is read-only after an operator supplies those paths:

$moveitWebRoot = '<configured MOVEit web root>'
$iisLogRoot = '<configured IIS log root>'

Get-ChildItem -LiteralPath $moveitWebRoot -Filter 'human2.aspx' -Recurse -Force |
  Select-Object FullName, Length, CreationTimeUtc, LastWriteTimeUtc

Get-ChildItem -LiteralPath $iisLogRoot -Filter '*.log' -Recurse -File |
  Select-String -Pattern 'human2\.aspx|X-siLock-Comment|X-siLock-Step'

Absence of those strings is not proof of no compromise: the artifact may have been renamed or removed, headers may not have been logged, and logs may have expired. A version upgrade also does not remove persistence, restore altered data, or determine what was exfiltrated.

Emergency containment

When an affected or unknown build is reachable over HTTP/S:

1. Have the authorized network or service owner block inbound HTTP and HTTPS to MOVEit at the closest reliable control point. Record the exact time, rule, scope, owner, and business impact. Do not let an autonomous agent make this production change.
2. Preserve IIS, WAF, proxy, MOVEit audit, Windows event, EDR, database, and authentication logs. Preserve relevant file metadata and take organization-approved snapshots before deleting or modifying artifacts.
3. Notify the incident-response owner. If an IOC is present, exposure history is unclear, or logs do not cover the vulnerable window, treat the system as potentially compromised and follow the organization's evidence, legal, privacy, customer-notification, and regulatory process.
4. Obtain the signed patch or supported installer only through Progress. Patch every active, passive, web-farm, disaster-recovery, and golden-image copy before HTTP/S is restored.
5. Let incident response decide rebuild, artifact removal, account disablement, and credential or key rotation after evidence is preserved. Patching and incident eradication are separate workstreams.

Remediation strategy

The safest default is a cumulative upgrade, not a hand-authored SQL filter or WAF signature:

1. Inventory the exact MOVEit edition, marketing version, internal build, deployment role, web root, database engine, and network reachability for every node.
2. Resolve the approved upgrade path and latest supported cumulative release from Progress. Older or unsupported trains require Progress Support and may require an intermediate upgrade.
3. Back up configuration and database state using the organization's normal MOVEit recovery process. Preserve separate forensic evidence if compromise is suspected; do not overwrite it with an operational backup.
4. Validate the vendor package's signature or published integrity evidence, rehearse the upgrade and rollback in a representative non-production environment, and review compatibility for web farms, integrations, APIs, automation, certificates, and database drivers.
5. Apply the update to every node under an operator-approved maintenance plan. Keep vulnerable nodes and stale images out of rotation.
6. Verify the running build on each node, refresh inventory and scanner evidence, run normal authenticated service health checks, and obtain the IR owner's approval before restoring external HTTP/S access.

Do not attempt to patch MOVEit's proprietary application code in a repository. Infrastructure-as-code changes may stage isolation, image replacement, or installer deployment, but a human operator must approve service interruption, production rollout, evidence handling, and re-exposure.

When to use

Use this recipe when an on-premises MOVEit Transfer server, web farm, passive node, disaster-recovery image, vendor appliance, CMDB record, scanner finding, or historical incident record may involve CVE-2023-34362. It is especially important when HTTP/S was internet-, partner-, VPN-, or broad-internal-network reachable at any time before the environment reached a cumulative fixed build.

Use it to join four workstreams: version inventory, emergency isolation, vendor upgrade, and compromise assessment. Do not use it to perform exploit validation, to declare an exposed server clean, or to combine unrelated MOVEit vulnerabilities into an unreviewed change.

Inputs

• CMDB and asset inventory for every MOVEit Transfer and MOVEit Cloud tenant, including active, passive, web-farm, DR, template, snapshot, and retired systems.
• Exact marketing version and internal build evidence, installer/package provenance, Progress entitlement, support status, upgrade path, and current vendor release notes.
• IIS bindings, reverse proxies, WAFs, load balancers, firewall rules, VPN and partner paths, DNS history, and an exposure timeline.
• Configured MOVEit web roots, application and audit logs, IIS/WAF/proxy logs, Windows and EDR telemetry, database audit evidence, backup history, and log retention limits.
• User and administrator account history, file-download and tenant-access records, and the current CISA IOC set.
• Maintenance window, service owner, incident-response owner, evidence custodian, privacy/legal contacts, backup and rollback plan, and approval boundaries for containment and production changes.

Agent prompt

You are remediating exactly CVE-2023-34362 in a MOVEit Transfer environment.
Produce exactly one of:

- a reviewer-ready PR/change request that prepares an approved cumulative
  Progress upgrade, inventory and safe verification; or
- `TRIAGE.md` when a stop condition applies, including not-exposed evidence,
  an owner, and the next decision required.

Do not execute an exploit, send a probe to a live service, or include a SQL or
HTTP payload. Do not claim that patching proves no compromise.

### Step 0 - Establish authority and preserve evidence

1. Identify the service owner, incident-response owner, and production-change
   approver.
2. Record the current time, host/node list, exact build evidence, HTTP/S
   exposure state, and log-retention window without changing the target.
3. If suspicious activity or an IOC is already known, stop ordinary
   remediation work and create `TRIAGE.md` for incident response before any
   cleanup or upgrade can overwrite evidence.

### Step 1 - Inventory every copy

1. Find every active, passive, web-farm, DR, image, snapshot, and template copy
   of MOVEit Transfer. Identify MOVEit Cloud separately.
2. Record marketing version, internal build, role, database engine, install
   path, web root, installer provenance, support status, and upgrade owner.
3. Map HTTP/S reachability through IIS, load balancers, WAFs, proxies, VPNs,
   partner links, and internal networks for the full vulnerable period.

### Step 2 - Classify exposure and compromise risk

- Affected/unknown build plus any untrusted HTTP/S path: emergency containment
  and compromise assessment are required.
- Affected build with proven continuous HTTP/S isolation: patch before
  reopening; retain the evidence that proves isolation.
- Current cumulative fixed build: verify every node and image, then document
  whether it was previously exposed while vulnerable.
- MOVEit Cloud: record Progress's provider patch notice and tenant-log review;
  do not prepare an on-premises installer change.

Review the current CISA IOC set, configured web roots, account history,
download/audit events, and retained HTTP/S telemetry. An incomplete or expired
log window is uncertainty, not a clean result.

### Step 3 - Prepare containment and upgrade

1. If HTTP/S is still exposed, write an operator action to block it. Do not
   change production firewall, WAF, load-balancer, or IIS state yourself.
2. Select the latest cumulative, vendor-supported release on a
   Progress-approved upgrade path. Treat the May 31 CVE-specific fixes as
   historical floors, not preferred targets.
3. Use only a Progress-supplied package and record signature or integrity
   verification. Never download a patch from an exploit site or mirror.
4. Prepare configuration/database backup, staging rehearsal, compatibility,
   maintenance, rollback, and per-node rollout steps. Keep stale nodes and
   images out of rotation.

### Step 4 - Verify safely

After an authorized operator applies the update:

1. Capture the running version/build from every node and compare it with the
   Progress release evidence selected in Step 3.
2. Confirm no vulnerable node, DR image, snapshot restoration path, or golden
   image can re-enter service.
3. Re-run the approved authenticated inventory or vulnerability scan without
   exploit mode. Do not suppress a conflicting result; attach it to triage.
4. Run the organization's ordinary authenticated upload/download and
   integration health checks using non-sensitive test data.
5. Confirm the IR owner reviewed preserved evidence and approved restoration
   of HTTP/S. A clean version check is not IR clearance.

### TRIAGE.md stop conditions

Stop and write `TRIAGE.md` when any of these is true:

- `human2.aspx`, a CISA-listed IOC, `Health Check Service`, unexplained account
  activity, unusual downloads, or another suspicious event is found;
- an affected or unknown build had untrusted HTTP/S reachability and retained
  evidence cannot bound the exposure window;
- exact build, node completeness, web-farm/DR scope, or historical exposure
  cannot be proven;
- the required Progress package, signature/integrity evidence, entitlement,
  support status, or safe upgrade path cannot be verified;
- the installed release is unsupported or needs an intermediate/major upgrade
  that exceeds the authorized change;
- production containment, service interruption, database migration, rollback,
  or evidence preservation lacks an authorized owner;
- the target is MOVEit Cloud or another provider-owned deployment;
- a scanner/vendor version-boundary conflict cannot be reconciled; or
- the repository does not control the MOVEit runtime or deployment.

`TRIAGE.md` must state the observed facts, missing evidence, affected assets,
exposure window, containment status, log-retention boundary, IOC review status,
service and IR owners, vendor case if any, and the exact decision needed. Do
not paste secrets, customer file names, personal data, full access tokens, or
unredacted forensic evidence into the repository.

### Guardrails

- No exploit payloads, public-instance scanning, active SQL testing, web-shell
  interaction, destructive database queries, or unsafe live probes.
- Do not delete suspicious files or accounts, clear logs, restart services,
  rotate credentials, rebuild hosts, or alter production network controls.
  Those actions require IR/change-owner approval after evidence preservation.
- Do not write a substitute patch for proprietary MOVEit code.
- Do not use third-party patch packages or treat a WAF signature as the fix.
- Do not declare `not compromised` from absent IOCs, a successful upgrade, or
  a passing scanner result.
- Do not claim this recipe remediates separate MOVEit CVEs. The selected
  cumulative release must be checked against all applicable Progress
  advisories in a separately reviewed scope.

Verification - what the reviewer looks for

• Every active, passive, web-farm, DR, template, and image copy has exact build evidence and a named owner.
• The destination is a current Progress-supported cumulative release on a documented upgrade path, not merely an initial May 31 hotfix.
• Package provenance and signature/integrity verification are recorded.
• Historical and current HTTP/S exposure is documented separately from SFTP or FTPS availability.
• Suspicious-file, account, download, HTTP, and current CISA IOC review is attached or handed to IR without placing sensitive evidence in the PR.
• The rollout, backup, rollback, normal service health check, and per-node version verification are reproducible.
• External HTTP/S remains blocked until both patch verification and IR approval are complete.
• A scanner disagreement is investigated, not suppressed.

Watch for

• Patching is not incident response. The campaign predates public disclosure. A fixed build says nothing about activity before installation.
• Partial fleet upgrades. Passive nodes, DR images, snapshots, and golden images can silently restore a vulnerable server.
• Historical hotfix confusion. The initial CVE-specific floors are not a safe reason to remain on an obsolete branch. Later Progress advisories and cumulative service packs matter.
• NVD metadata differences. NVD prose, CPE ranges, and vendor release notes are not perfectly aligned. Prefer a current cumulative vendor release and preserve disagreement for review.
• False clean results. Missing human2.aspx or missing header telemetry is not proof of no exploitation; artifacts and logs can be absent.
• Evidence destruction. Upgrade, cleanup, account deletion, log rotation, and rebuilds can destroy the timeline investigators need.
• Web farm and database dependencies. Version skew or an unreviewed schema change can cause outage or rollback failure.
• Cloud ownership. MOVEit Cloud patching is provider-operated; customer responsibilities are status confirmation, tenant evidence review, and any resulting incident actions.
• Sensitive output. MOVEit logs and audit data can contain customer, partner, file, account, and transfer details. Redact before attaching.

Rollback

Do not roll back into NVD-listed Transfer ranges below 2021.0.7 / 2021.1.5 / 2022.0.5 / 2022.1.6 / 2023.0.2 or into vendor 2021.0.6 / 2021.1.4 / 2022.0.4 / 2022.1.5 / 2023.0.1. Do not flatten leftover 2023.0.1 onto NVD 2023.0.2 and do not invent a first_patched from the empty GHAD vulnerabilities list.

Output contract

Return one of:

• A reviewer-ready PR/change request that inventories every MOVEit copy, prepares a current Progress-supported cumulative upgrade, records vendor package provenance, stages containment and operator actions, preserves the compromise-assessment handoff, verifies every running node and image, and documents backup, rollback, and safe service health checks.
• TRIAGE.md when evidence of compromise exists, exposure or logs are incomplete, the build or complete fleet cannot be proven, a supported Progress upgrade path is unavailable, operational/IR ownership is missing, the provider owns patching, or the repository cannot control the runtime.

The output must include asset and node inventory, before/after builds, database engine, deployment role, HTTP/S exposure timeline, containment status, Progress evidence and package provenance, log-retention and IOC review status, IR and service owners, maintenance and rollback plan, per-node validation, scanner result, and the approval required before re-exposure. It must not contain exploit material, sensitive customer evidence, unsupported cleanliness claims, third-party patches, or unapproved production actions.

References

• Progress MOVEit Transfer critical vulnerability advisory: https://community.progress.com/s/article/MOVEit-Transfer-Critical-Vulnerability-31May2023
• Progress MOVEit Transfer 2023 fixed issues, including the 2023.0.1 hotfix: https://docs.progress.com/bundle/moveit-transfer-release-notes-2023/page/Fixed-Issues-in-2023.html
• Progress MOVEit Transfer 2022.1.5 fixed issues: https://docs.progress.com/bundle/moveit-transfer-release-notes-2022_1/page/Fixed-Issues-in-2022.1.5.html
• Progress MOVEit Transfer 2022.0.4 fixed issues: https://docs.progress.com/bundle/moveit-transfer-release-notes-2022/page/Fixed-Issues-2022.0.4.html
• Progress legacy MOVEit Transfer 2021 release notes: https://docs.ipswitch.com/MOVEit/Transfer2021/ReleaseNotes/en/index.htm
• Progress legacy MOVEit Transfer 2021.1 release notes: https://docs.ipswitch.com/MOVEit/Transfer2021_1/ReleaseNotes/en/index.htm
• Progress legacy MOVEit Transfer 2020.1 release notes: https://docs.ipswitch.com/MOVEit/Transfer2020_1/ReleaseNotes/en/index.htm
• Progress security update and mitigation statement, June 5, 2023: https://www.progress.com/amp/update-steps-we-are-taking-protect-moveit-customers/dWU5d09jQTFGZndVVnJod2xERzk5TENYb204PQ2
• Progress MOVEit Transfer and MOVEit Cloud patch FAQ: https://www.progress.com/docs/default-source/moveit-docs/moveit-transfer_moveit-cloud-vulnerabilities-customer-faq_posted.pdf?sfvrsn=16a47a99_13
• CISA Known Exploited Vulnerabilities catalog entry: https://www.cisa.gov/known-exploited-vulnerabilities-catalog?field_cve=CVE-2023-34362
• FBI/CISA AA23-158A, CL0P exploitation of MOVEit Transfer: https://www.cisa.gov/news-events/cybersecurity-advisories/aa23-158a
• NVD CVE-2023-34362 record: https://nvd.nist.gov/vuln/detail/CVE-2023-34362

Related workflow

• CVE Intelligence Intake Gate
• use it when a scanner row, cloud notice, affected build, or exposure claim is incomplete before starting remediation.
• Vulnerable Dependency Remediation
• use its ownership, rollout, SBOM, and review controls around this product-specific vendor upgrade.