Is CVE-2024-38094 (Microsoft SharePoint Deserialization) being exploited in the wild?

Yes. CISA added CVE-2024-38094 to its Known Exploited Vulnerabilities catalogue on 22 October 2024, which it does only when there is reliable evidence of active exploitation. CISA lists it as known to be used in ransomware campaigns. Microsoft SharePoint contains a deserialization vulnerability that allows for remote code execution. Any organisation running the affected product should treat remediation as urgent.

What the KEV listing means for a SharePoint deserialization flaw

For this CVE, the practical signal is not abstract vulnerability presence, it is confirmed active exploitation. Once Microsoft SharePoint appears in the CISA KEV catalogue, defenders should assume attackers are already using the flaw against exposed systems and that exploitation may not depend on broad scanning alone. A deserialization issue is especially dangerous because it can turn untrusted input into code execution.

That changes the operational priority from routine patch scheduling to urgent exposure control. The question is no longer whether the flaw could be abused, but whether your SharePoint estate is reachable, internet-facing, or reachable through trusted internal paths that an attacker could already access. If the service is still reachable, the attack window is open.

For a fast triage path, start with the two questions the KEV listing is designed to answer: is this asset present, and can it be remediated now? The most useful external references for that decision are the CISA Known Exploited Vulnerabilities Catalog and the CVE Program, with vendor-specific version and mitigation details taken from Microsoft guidance rather than from secondary summaries.

Why deserialization in SharePoint is a high-value exploitation path

Deserialization flaws are attractive because they can bypass normal application logic and land directly in a powerful execution context. In SharePoint, that can translate into remote code execution on a platform that often sits close to document stores, collaboration data, and trusted internal workflows. That combination gives an attacker both reach and leverage once execution is obtained.

The security problem is not only code execution itself, but what code execution can unlock next. An attacker who gains execution on a SharePoint server may be able to probe adjacent systems, access application secrets in memory or configuration, or plant persistence that survives a simple restart. If the server is also integrated with identity, file, or search infrastructure, the blast radius can grow quickly.

Because the vulnerability class is deserialization, do not assume that only one request or one endpoint is involved. The safer assumption is that any path taking untrusted serialized input can be part of the attack surface. The Insecure Deserialisation Guide is useful here because it explains the underlying failure mode, while the Zero-Day and Exploited Vulnerabilities Guide helps frame KEV-driven triage, emergency mitigation, and post-patch hunting.

What to do if patching is delayed or exposure is unclear

If immediate patching is not possible, the next best move is to reduce reachable attack paths. That means narrowing network exposure, tightening who can reach the SharePoint service, and reviewing whether any reverse proxy, WAF, or segmentation control can buy time. Temporary controls should be treated as risk reduction, not as a substitute for remediation.

When patching must wait, you also need to treat the server as potentially compromised until proven otherwise. Review logs for unusual child processes, suspicious outbound connections, unexpected web shells, authentication anomalies, and changes to the SharePoint application directories or associated service accounts. If exploitation may have occurred, recovery should include credential and session review for the service context that the server can reach.

SharePoint exploitation often becomes a broader trust issue, not just a single-host issue. If the server uses privileged service credentials or can reach internal data sources, rotate or invalidate anything that could have been exposed through the host, especially where the application has broad access or long-lived trust relationships. The Vulnerability Management Guide is relevant because it ties KEV status to prioritisation, verification, exception handling, and remediation accountability.

Risk and Threat Considerations

Confirmed exploitation of a SharePoint deserialization flaw means the attacker does not need to discover a novel path, they can reuse a known one against exposed or poorly segmented systems. That creates immediate risk of remote code execution, persistence, and follow-on access to adjacent internal resources.

Failure mechanism: Deserialisation of untrusted data allows crafted input to trigger code execution in the application process, which can then be used to run commands, deploy payloads, or stage lateral movement.

Impact: A successful exploit can expose documents, credentials, internal data flows, and downstream systems that trust the SharePoint host or its service identity.

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 rapid identification and remediation prioritisation.
	CIS-4 — Secure Configuration of Enterprise Assets and Software	Containment and hardening reduce reachable attack paths while patching is delayed.
Recommendation — Prioritise and remediate KEV-listed SharePoint exposure first. Harden and segment exposed SharePoint services until patched.
NIST CSF 2.0	GV.RM-01 — Risk Management Strategy	KEV-driven exploitation changes vulnerability handling into urgent risk management.
	DE.CM-09 — Network Monitoring	Exploitation of a SharePoint RCE should be hunted through network and host telemetry.
Recommendation — Escalate KEV-listed exploitation into the highest remediation priority. Monitor SharePoint hosts for suspicious connections, execution and persistence.
NIST SP 800-53 Rev 5	RA-5 — Vulnerability Monitoring and Scanning	Confirmed exploitation requires continuous identification and tracking of vulnerable assets.
	SI-2 — Flaw Remediation	Patch application and mitigation are the core response to an exploited software flaw.
Recommendation — Track and remediate vulnerable SharePoint instances immediately. Apply the vendor fix or approved mitigation as soon as possible.

Practitioner Guidance

What to prioritise: Treat KEV-listed SharePoint exposure as an emergency fix item, not a normal vulnerability backlog entry. If the server is internet-facing or reachable from broad internal networks, move it to the front of the queue.

What to verify: Confirm the exact SharePoint deployment, whether the vulnerable surface is reachable, and whether logs show signs of exploitation before or after the CISA listing date. If there is any indication of compromise, widen the review beyond the application host.

Decision rule: If you cannot patch immediately, assume the server is under active targeting and use containment, monitoring, and credential review as stopgaps, not as a final state.

Practitioner takeaway: KEV status should drive urgent action because it compresses uncertainty, if exploitation is already observed, every extra day of exposure increases both compromise likelihood and the cost of recovery.