CVE-2024-38094 – Immediate actions for Microsoft SharePoint

What you need to know right now

If your scanner has just flagged CVE-2024-38094, you are looking at a high‑severity remote code execution risk in Microsoft SharePoint. The vulnerability is being actively exploited in ransomware campaigns, and the Cybersecurity and Infrastructure Security Agency (CISA) has listed it as a known‑exploited vulnerability. You need to know whether you are exposed, how bad it is, and exactly what to type to protect your environment.

Related remediation guides

Other vulnerabilities in the same family or affecting the same products:

• CVE-2025-53770 SharePoint Server – Immediate Action Guide
• CVE-2026-45659 – SharePoint Server deserialization flaw – what it means and how to fix it
• CVE-2025-49704 – Immediate actions for Microsoft SharePoint code‑injection risk

For the wider picture, our Known Exploited Vulnerabilities tracker lists every flaw CISA has confirmed under active attack.

Why this matters to you

Any organisation that runs SharePoint – whether on‑premises, in a hybrid deployment, or as part of a hosted service – should treat this alert as urgent. Remote code execution means an attacker can run arbitrary commands on the server that hosts SharePoint. In the hands of ransomware operators that translates to encrypted files, stolen data, and costly downtime.

Technical background – what the flaw actually is

The NVD classifies CVE-2024-38094 as a deserialization vulnerability. In plain English, SharePoint accepts a data structure from a client, turns that structure back into an object in memory, and then works with it. If the data is crafted in a malicious way, the deserialization process can be tricked into creating objects that execute code. The end result is that an unauthenticated network‑connected attacker can achieve code execution on the SharePoint server.

Microsoft has not published the exact gadget chain or the precise request that triggers the bug. That information is not publicly available, and the vulnerability description in the NVD is limited to the generic class. What we do know is that the flaw is remote, does not require prior authentication, and can be triggered over the network.

How severe is it?

The CVSS score is 7.2 – a high rating. The score reflects the ease of remote exploitation and the potential impact on confidentiality, integrity, and availability. CISA’s inclusion of the vulnerability in its Known Exploited Vulnerabilities catalog confirms that malicious actors are already using it in the wild. Ransomware groups have specifically cited this bug as an entry point.

Because the attack does not need valid credentials, the usual perimeter controls (strong passwords, MFA) do not stop it. If an attacker can reach the SharePoint web endpoint, they can launch the exploit.

Determine whether you are exposed

The first step is to confirm that SharePoint is installed on the host you are checking. On a Windows server you can run the following PowerShell command:

Get-SPFarm | Select BuildVersion

This will output the build version of the SharePoint farm. Compare the value you see with the entries in the table below – the table is generated automatically from the NVD and lists which builds are vulnerable and which are patched.

If the build version you see matches any entry marked as vulnerable, you are at risk. If it matches a patched entry, you are already protected.

Mitigation and remediation steps

CISA’s guidance is clear: apply the vendor‑provided mitigations, or stop using the product if no fix is available. Microsoft has released a security update that addresses the deserialization flaw. The qualitative advice is:

• Apply the latest SharePoint security update for your release branch. The update is distributed through Windows Update, WSUS, or your existing patch management system.
• Restart the SharePoint services after installation. A simple restart ensures the new binaries are loaded.
• Restrict inbound traffic to the SharePoint web front‑ends. Use firewall rules or network security groups to allow only trusted IP ranges.
• Enable request validation and anti‑serialization hardening. In the SharePoint web.config file set requestValidationMode="4.0" and enable customErrors="On" if not already set.
• Deploy a web application firewall (WAF) rule that blocks suspicious deserialization payloads. Many commercial WAFs have signatures for this class of attack.

If your environment cannot be patched immediately – for example, because you are on a custom build that cannot be upgraded – you should take the following temporary measures:

• Isolate the SharePoint server from the internet and limit access to internal subnets only.
• Disable any custom web services or APIs that accept serialized objects from unauthenticated callers.
• Monitor inbound traffic for unusual POST requests to /_vti_bin/ endpoints, which are commonly used in SharePoint exploits.

Remember, these steps are not a substitute for the official patch. They only reduce the attack surface while you arrange for the update.

What to do if a patch is unavailable

In the unlikely event that you cannot apply the vendor patch – perhaps because you are running a legacy environment that is out of support – you must consider discontinuing use of SharePoint. The risk of a remote code execution breach outweighs the benefit of keeping an unsupported product online.

Before you retire the service, take the following actions:

• Back up all SharePoint content databases and document libraries.
• Export site collections to a secure location using the Export-SPWeb cmdlet.
• Plan migration to a supported platform – either a newer SharePoint release or an alternative collaboration tool.

During the migration window, keep the server isolated and monitor logs for any signs of exploitation. Once the data is safely moved, decommission the old server and remove it from the network.

Verification after remediation

After you have applied the update, run the PowerShell command again and confirm that the build version now appears in the patched column of the table below. check the Windows Event Log for any entries that reference the update – look for Event ID 19 from the source “Microsoft-Windows-WindowsUpdateClient”.

Finally, perform a quick scan with your vulnerability scanner to ensure CVE-2024-38094 no longer appears. If the scanner still flags the issue, double‑check that the update was applied to every SharePoint server in the farm, including any additional web front‑ends.

Summary checklist

• Run Get-SPFarm | Select BuildVersion to identify your current SharePoint build.
• Compare the result with the table below – if it is listed as vulnerable, you need to act.
• Deploy the latest Microsoft security update for SharePoint.
• Restart SharePoint services and verify the new build version.
• Apply network restrictions and WAF rules as temporary mitigations.
• If you cannot patch, isolate the server and plan migration or decommission.
• Re‑run your scanner to confirm the vulnerability is resolved.

Table of affected and fixed releases

The table below is generated automatically from the NVD. It shows which SharePoint builds are vulnerable and which have been patched. Use it in conjunction with the PowerShell command above.

NOTE: No version numbers are displayed here – the table is populated by the system based on the latest NVD data.

the table below

Affected versions

NVD has not published machine-readable version ranges for CVE-2024-38094 yet. Check the vendor advisory for the exact affected and fixed releases before you plan an upgrade.