Is CVE-2024-38189 (Microsoft Project Remote Code Execution Vulnerability) being exploited in the wild?

Yes. CISA added CVE-2024-38189 to its Known Exploited Vulnerabilities catalogue on 13 August 2024, which it does only when there is reliable evidence of active exploitation. CISA has not linked it to known ransomware campaigns. Microsoft Project contains an unspecified vulnerability that allows for remote code execution via a malicious file. Any organisation running the affected product should treat remediation as urgent.

What “being exploited in the wild” means for this CVE

For a vulnerability like CVE-2024-38189, “in the wild” means there is evidence that attackers are already using it against real systems, not just demonstrating proof of concept code in a lab. That changes the operational posture immediately: exposure is no longer theoretical, and the question becomes whether your environment is reachable, weaponisable, or already affected.

Because the direct answer already states that Microsoft Project contains a vulnerability that can lead to remote code execution through a malicious file, the practical reading is straightforward: a file-open or file-processing path is the likely entry point, and any workflow that accepts untrusted Project files deserves attention. Treat it as a live exploitation issue, not a future patch-planning item.

Zero-Day and Exploited Vulnerabilities Guide is the right internal reference when you need the operational difference between ordinary vulnerability handling and active exploitation triage.

How to confirm exposure and decide what needs urgent action

The first task is to identify where Microsoft Project is installed, who uses it, and whether those systems receive files from outside the organisation. If the product is present on endpoints used by finance, project management, engineering, or executive staff, the exposure may be wider than the security team initially assumes because those users often receive shared files from email, collaboration platforms, or external partners.

Next, confirm whether the organisation has any controls around document intake, detonation, attachment filtering, or application restrictions for Project files. If you cannot reliably say which users can open external files in the affected application, you do not yet have enough visibility to treat the risk as contained.

Vulnerability Management Guide is useful here because this situation is fundamentally about scope, prioritisation, exceptions, and verification, not just patch deployment.

What remediation looks like when patching cannot wait

The safest response is to apply the vendor fix as soon as it is available and to follow the vendor advisory for version-specific instructions. Do not rely on the mere presence of endpoint protection or user caution as a substitute for remediation when CISA has already placed the issue in KEV.

If patching is delayed, reduce the exploit path instead of hoping for a temporary hold to remain safe. That usually means limiting access to Microsoft Project on only the systems and users that genuinely need it, blocking or sandboxing untrusted Project files where you can, and tightening email and download workflows that feed the application.

CISA Known Exploited Vulnerabilities Catalog should be the external source of record for exploitation status, while the vendor advisory should drive the exact fix path.

Risk and Threat Considerations

Once a CVE is confirmed as actively exploited, the main risk is not just remote code execution in the abstract, but compromise through ordinary business workflows that users trust. Malicious files are attractive because they can move through normal collaboration channels, and successful exploitation can give an attacker code execution before many controls have a chance to react.

Failure mechanism: A targeted file is opened or processed in Microsoft Project, the vulnerability is triggered, and attacker-controlled code executes in the context of the user or system handling the file.

Impact: That can lead to endpoint compromise, lateral movement, credential theft, or follow-on deployment of additional malware, which is why active exploitation should be treated as an incident-response concern as much as a patching concern.

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 SP 800-53 Rev 5, NIST CSF 2.0 and OWASP ASVS 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 rapid identification, prioritisation, and remediation.
Recommendation — Prioritise and remediate the exposed Microsoft Project systems immediately.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	This CVE needs identification, prioritisation, and verification of affected assets.
	SI-2 — Flaw Remediation	KEV-listed exploitation makes prompt flaw remediation the core control action.
Recommendation — Scan for Microsoft Project exposure and verify remediation status. Apply the vendor fix and document exception handling if patching is delayed.
NIST CSF 2.0	ID.RA-01 — Asset vulnerabilities are identified and recorded	You need inventory and exposure visibility to know where the CVE matters.
	PR.IP-12 — Vulnerability management plan is implemented	A live-exploited vulnerability should be handled through an emergency remediation process.
Recommendation — Identify every system running Microsoft Project and record its remediation state. Use your vulnerability management process to accelerate containment and patching.
OWASP ASVS	V15 — Secure Coding and Architecture	The issue is a code execution flaw triggered through file handling and application behaviour.
Recommendation — Review file-processing paths and harden the application workflow around untrusted files.

Practitioner Guidance

What to prioritise: Patch the exposed Microsoft Project estate first, then verify where external files are allowed to enter those systems. If a device can receive untrusted Project files and the application remains unpatched, treat that device as high priority.

What to verify: Check for suspicious file opens, abnormal child processes, unexpected outbound connections, and recent changes on endpoints where Project is installed. If the product was used before remediation, preserve logs and endpoint evidence so you can judge whether the vulnerability was merely present or actually exercised.

Practitioner takeaway: For an actively exploited RCE in a business application, the right question is not whether the exploit is clever, it is whether the attack path still exists anywhere in your environment.