A dangerous vulnerability in SharePoint Server lets attackers seize full control of on-premises farms, and Microsoft has just released the fix. The flaw, tracked as CVE-2025-62204, enables remote code execution through unsafe deserialization — a technique that has fueled a wave of office-wide ransomware attacks this year. Every IT team running SharePoint Server must act now: patch, rotate cryptographic keys, and hunt for signs of intrusion.

What the Advisory Reveals

The official page for CVE-2025-62204 sits in Microsoft’s Security Update Guide, though you’ll need to interact with the guide’s JavaScript interface to view all details. Independent vulnerability databases list the bug as a deserialization issue with a CVSS severity rating hovering around 8.0 — high enough to demand immediate attention. Microsoft’s advisory confirms patches are available through standard update channels for supported SharePoint Server editions, including Subscription Edition, SharePoint Server 2019, and SharePoint Server 2016 (where applicable).

Because the exact KB numbers and product mappings are locked inside that interactive guide, administrators should treat the MSRC portal — not third-party trackers — as the single source of truth. Several earlier SharePoint vulnerabilities produced inconsistent CVE labels across databases, and relying on a numeric identifier alone risks misapplying patches. Microsoft has not detailed any mitigating factors or workarounds in the public advisory, which underscores the imperative to install the update.

The vulnerability itself is classic ASP.NET deserialization. Attackers craft malicious serialized objects — often smuggled inside ViewState blobs or other serialization paths — which the server blindly reconstructs. This gives the attacker permission to run arbitrary code inside the IIS worker process (w3wp.exe), the very heart of a SharePoint server.

The Real-World Risk: Who’s Affected?

If your SharePoint farm is on-premises and reachable from the internet, you are in the crosshairs. This includes:

  • SharePoint Server Subscription Edition
  • SharePoint Server 2019
  • SharePoint Server 2016 (with supporting KBs)

SharePoint Online (Microsoft 365) is not affected by this class of deserialization vulnerabilities because Microsoft manages the underlying infrastructure and applies patches at the service level. For home users or small businesses relying on SharePoint Online, there is no immediate action to take.

Internet-exposed farms face the greatest danger. Automated scanners constantly probe for SharePoint endpoints, and the exploit chain typically requires nothing more than a specially crafted HTTP request. Even a single unpatched server can be a beachhead for attackers to move laterally across a network. Older, unsupported versions — SharePoint 2010, 2013, or custom legacy builds — won’t receive patches, leaving isolation or migration as the only defenses.

The Attack Chain: Why Deserialization Is Dangerous

While Microsoft hasn’t published full technical details for CVE-2025-62204, the anatomy of similar exploits observed throughout 2025 reveals a repeatable pattern. Here’s how an attack typically unfolds:

  1. Reconnaissance: Scanners fingerprint SharePoint versions by probing well-known URLs.
  2. Bypass & Upload: The attacker sends a crafted POST request to a layout endpoint — often /_layouts/15/ToolPane.aspx or a similar path — while spoofing headers to bypass authentication checks. This persuades the server to write a malicious ASPX web shell into the Layouts folder.
  3. Key Theft: The web shell reads web.config or memory to exfiltrate the machine-wide machineKey values (validationKey and decryptionKey).
  4. Persistent Backdoor: Armed with the keys, the attacker forges signed __VIEWSTATE payloads that SharePoint trusts implicitly, creating a stealthy persistence mechanism that survives server reboots and even some incomplete remediations.

Because the malicious code runs inside the IIS worker process, it inherits the server’s network privileges. Attackers can harvest credentials, move laterally, and deploy ransomware — as multiple incident response reports have documented this year.

A Year of SharePoint Exploits: How We Got Here

SharePoint on-premises farms have endured a bruising 2025. In July, a cluster of vulnerabilities — dubbed “ToolShell” by researchers — combined an authentication bypass with unsafe deserialization to wreak havoc. Those flaws (CVE-2025-53770 and CVE-2025-53771) demonstrated just how quickly a single chained exploit can cascade into a global incident. National cybersecurity agencies and Microsoft responded with coordinated advisories, but the outbreaks exposed a hard truth: many organizations still run SharePoint farms that are internet-facing, poorly monitored, and slow to patch.

The CVE-2025-62204 disclosure fits that same mold. While it carries a fresh identifier, the underlying weakness is familiar: an application-layer vulnerability that lets attackers turn a trusted .NET object into a weapon. The fact that patches are available is good news, but the lag between advisory publication and actual enterprise deployment remains a critical gap.

Your Immediate Response Plan

Treat this vulnerability as a “patch and hunt” priority. Here are the steps to take, in order:

1. Identify Every SharePoint Host

Inventory all on-premises servers, note their exact product SKUs (Subscription Edition, 2019, 2016) and any language packs. This is essential because different builds may require different updates.

2. Apply the Official Microsoft Updates

Visit the MSRC Security Update Guide, locate the CVE-2025-62204 entry, and download the correct update for each server. Do not assume Windows Update will catch this automatically — some SharePoint patches are distributed separately. Validate the KB number and build version after installation.

3. Rotate the ASP.NET machineKey Farm-Wide

This step is non-negotiable. After patching, generate new validationKey and decryptionKey values and push them across the farm using SharePoint Central Administration or PowerShell cmdlets like Set-SPMachineKey. Restart IIS on every node. Rotating the keys invalidates any stolen key material and prevents attackers from using forged ViewState payloads even if they still have a foot in the door.

4. Enable AMSI and Enterprise Antimalware

Turn on the Antimalware Scan Interface in SharePoint (Full Mode if your version supports it) and deploy Microsoft Defender Antivirus or a comparable solution. AMSI hooks into HTTP request processing and can detect and block malicious payloads in transit.

5. Deploy EDR and Hunt for Compromise

If you have endpoint detection and response (EDR) capabilities — Microsoft Defender for Endpoint, CrowdStrike, or similar — make sure they are active on SharePoint servers. Run queries to look for:

  • Suspicious child processes spawning from w3wp.exe (e.g., powershell.exe, cmd.exe)
  • Base64-encoded POST requests to ToolPane.aspx
  • New or modified .aspx files in the Layouts directories (e.g., spinstall0.aspx)

6. Harden Internet-Facing Servers Immediately

If you cannot patch or deploy AMSI within the next 24 hours, take internet-exposed SharePoint servers offline or place them behind a VPN or authenticated proxy. The risk of automated exploitation is too high to wait.

Beyond the Patch: Long-Term Hardening

Applying a single update isn’t enough. The 2025 exploit wave has shown that attackers will probe for deserialization flaws relentlessly. Build defense in depth:

  • Reduce Internet Exposure: Place SharePoint behind a web application firewall (WAF) and restrict traffic to known IP ranges. Disable direct access to management endpoints. If public reach isn’t strictly required, use VPN-only access.
  • Tune Detection Rules: Configure your WAF or intrusion detection system to block POST requests to /_layouts/15/ToolPane.aspx (and similar paths) that contain abnormal headers or large payloads. Log and alert on any Referer header that matches SignOut.aspx — a common spoofing tactic.
  • Maintain a Tight Update Cadence: Use deployment tools like WSUS, SCCM, or Intune to push SharePoint updates quickly. Keep an accurate inventory so that language packs and build variants are always accounted for during patching.

If you confirm a compromise, the response escalates. Isolate affected servers, preserve forensic artifacts (IIS logs, web.config, memory dumps), and assume the machineKey and service account credentials are stolen. Rotate all secrets, rebuild servers from clean images, and restore data from verified backups. Do not simply remove a web shell and consider the incident closed — the attackers may have established multiple persistence mechanisms.

What Comes Next

CVE-2025-62204 will likely be added to the Known Exploited Vulnerabilities catalog by CISA within days, and we expect security vendors to publish detection signatures and hunting rules shortly. The bigger question is whether exploitation will spike before most organizations patch. Given the speed of earlier SharePoint attacks, administrators should brace for active scanning within hours of the advisory. If you haven’t already, make today the day you patch — and then make tomorrow the day you audit and harden every SharePoint server in your environment.