Is CVE-2023-40044 (Progress WS_FTP Server Deserialization of Untrusted Data) being exploited in the wild?

Yes. CISA added CVE-2023-40044 to its Known Exploited Vulnerabilities catalogue on 5 October 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 WS_FTP Server contains a deserialization of untrusted data vulnerability in the Ad Hoc Transfer module that allows an authenticated attacker to execute remote commands on the underlying operating system.

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

For a CVE like this, the practical question is not whether the flaw exists, but whether defenders should treat it as an active incident risk. CISA’s KEV listing is the key signal that exploitation has moved beyond theory. For current status and record details, verify the entry in the CISA Known Exploited Vulnerabilities Catalog and the CVE Program.

The vulnerability itself is a deserialization of untrusted data issue in Progress WS_FTP Server’s Ad Hoc Transfer module. In practice, that means a crafted input can be converted into server-side behaviour the application did not intend, which is why these flaws often become remote command execution paths once an attacker reaches the vulnerable code path.

Why this issue is operationally urgent

Once a vulnerability is confirmed in the KEV catalogue, the priority changes from normal patch scheduling to exposure reduction and verification. The risk is not only initial compromise, but also the speed with which exploit code can be weaponised across internet-facing file transfer systems. Use the vendor advisory and KEV guidance to confirm whether your deployment is still exposed, then cross-check it against the broader Zero-Day and Exploited Vulnerabilities Guide and the Insecure Deserialisation Guide.

For teams that manage internet-facing application flaws at scale, the right lens is exploitation likelihood plus business blast radius, not just severity. That is why prioritisation should be driven by active exploitation evidence, asset criticality and whether the affected server is externally reachable rather than by patch queues alone. The Vulnerability Management Guide is the right operating model for that decision.

What to do when patching is delayed or compromise is uncertain

If you cannot patch immediately, reduce exposure first, then look for signs of abuse. For a file transfer server, that usually means limiting network reachability, constraining administrative access, and validating whether the application has been used as an ingress point for commands, web shells or post-exploitation activity. Active exploitation of deserialisation flaws often leaves little noise unless you review application logs, process creation, outbound connections and unexpected changes around the transfer service.

When exposure is confirmed, treat the system as potentially compromised until you prove otherwise. If the server handled sensitive transfers or stored credentials, rotate any secrets, service credentials or session material that could have been accessed through the application or adjacent administration functions. The relevant response logic is the same one used for other actively exploited server flaws, including emergency containment, compromise assessment and post-remediation hunting.

Risk and Threat Considerations

Actively exploited file transfer vulnerabilities are attractive because they often sit on trusted infrastructure, are reachable from outside the network and may have broad access to data, credentials or downstream systems. A deserialisation flaw is especially dangerous because it can convert a single request into arbitrary server-side behaviour, which shortens the path from exposure to command execution.

Failure mechanism: An attacker sends crafted input that the application deserialises unsafely, triggering unintended object behaviour or code paths that can lead to remote command execution on the host.

Impact: The server can be used for data theft, lateral movement, persistence or ransomware staging, and any credentials or files processed by the transfer service may need to be treated as exposed.

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, CIS Controls v8 and NIST SP 800-53 Rev 5 set the governance and control requirements practitioners need to meet.

Framework	Control / Reference	Relevance
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and documented	The question asks whether the vulnerability is actively exploited and exposed assets matter.
	PR.DS-01 — Data-at-rest is protected	Compromised transfer servers may expose stored files and transferred data.
Recommendation — Identify exposed WS_FTP assets and prioritize them for urgent remediation. Protect and review data stored or handled by the affected server.
CIS Controls v8	CIS-7 — Continuous Vulnerability Management	KEV-listed exploitation requires accelerated vulnerability remediation and validation.
Recommendation — Accelerate remediation for externally exploitable vulnerabilities with active use in the wild.
NIST SP 800-53 Rev 5	SI-2 — Flaw Remediation	This CVE requires prompt remediation and verification of the fix path.
Recommendation — Apply and verify the remedial action for the vulnerable WS_FTP service.

Practitioner Guidance

What to verify: Confirm whether any Progress WS_FTP Server instance is internet-facing, whether it is still running the vulnerable module, and whether it was reachable before remediation began. Then verify whether application logs, system logs and EDR telemetry show suspicious child processes, archive activity, script execution or unusual outbound traffic around the disclosure window.

Decision rule: If the system is exposed and you cannot validate clean state quickly, treat it as an incident candidate, not just a patch candidate. Patch or isolate first, then decide whether credential rotation, session invalidation or broader containment is needed based on what the server could access rather than on whether you have already found malware.

Practitioner takeaway: For KEV-listed server flaws, the operational question is whether the system was reachable and whether it handled sensitive trust material, because that determines whether the response is simple remediation or full compromise handling.