Microsoft’s on-premises SharePoint servers are under active attack from a chain of vulnerabilities that grant unauthenticated attackers remote code execution (RCE). The exploit combines an authentication bypass with unsafe deserialization to drop webshells, steal cryptographic machine keys, and establish persistent access—a path that has already led to ransomware deployments and extensive network compromise. Administrators must patch immediately and apply a series of hardening measures to close the door.

The core weakness involves two interrelated flaws: a request-validation weakness that allows crafted HTTP requests to bypass server-side checks, and a deserialization vulnerability that executes attacker-supplied objects during the reconstruction process. When chained, these vulnerabilities let an unauthenticated attacker upload a malicious .aspx file to the SharePoint layouts directory, execute code with the privileges of the IIS worker process (w3wp.exe), and exfiltrate the ASP.NET machineKey. Once in possession of the machineKey, attackers can forge valid __VIEWSTATE payloads, turning a one-time breach into durable, hard-to-detect persistence. SharePoint farms exposed to the internet are the primary targets, but internal deployments also face risk if an attacker gains a foothold through other means.

Microsoft’s Security Response Center (MSRC) and the U.S. Cybersecurity and Infrastructure Security Agency (CISA) have issued urgent advisories. The vulnerability identifiers circulating in official guidance include CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, and CVE-2025-53771. However, a separate CVE number—CVE-2025-54897—appeared in some incident tickets and reports, but it could not be independently verified in public databases at the time of writing. The MSRC update guide page for that identifier leads to a generic description of the “confidence” metric, suggesting it may not correspond to a published advisory. Defenders should rely on the confirmed CVE list and Microsoft’s cumulative security updates, not on unverified numeric labels.

The attack unfolds in a five-stage sequence:

  • Reconnaissance. Attackers scan for internet-facing SharePoint farms, identifying version-specific endpoint patterns like ToolPane.aspx and SignOut.aspx. Automated tools fingerprint servers vulnerable to the known bypass.
  • Authentication/spoofing bypass. A crafted POST request to an administrative endpoint—typically /_layouts/15/ToolPane.aspx?DisplayMode=Edit—includes a manipulated Referer header set to /_layouts/SignOut.aspx. This tricks the server into allowing file writes to the layouts directory, a location normally restricted.
  • Unsafe deserialization and webshell drop. The POST body carries a serialized payload, such as an encoded .aspx file or a malicious ViewState object. SharePoint’s deserialization logic reconstructs the object without proper validation, executing code that writes a webshell (commonly named spinstall0.aspx) into the layouts folder.
  • MachineKey extraction. With the webshell active, the attacker reads the web.config file to obtain the values—the validationKey and decryptionKey that ASP.NET uses to sign and encrypt ViewState. These keys are exfiltrated or used immediately to forge valid signed payloads.
  • Post-exploitation. Armed with code execution and the machineKey, attackers deploy additional backdoors, harvest credentials with tools like Mimikatz, move laterally using Impacket or PsExec, exfiltrate sensitive data, and often unleash ransomware. Observed ransomware families include Warlock, and both financially motivated criminals and nation-state groups (including those tracked as Storm-2603, Linen Typhoon, and Violet Typhoon) have been implicated.

Real-world exploitation has been underway since at least July 2025, according to Microsoft and multiple threat intelligence firms. The impact spans industries worldwide—any organization running an unpatched or improperly secured SharePoint Server is vulnerable. Crucially, SharePoint Online (Microsoft 365) is unaffected; the attack surface is limited to on-premises deployments, including Subscription Edition, 2019, 2016, and unsupported older versions like 2013 and 2010.

The danger cannot be overstated because the IIS worker process often runs with high privileges, granting attackers a launchpad into the broader Active Directory environment. MachineKey theft is particularly insidious: even after patching the initial entry vector, attackers who possess the keys can regenerate valid ViewState and maintain a foothold unless the keys are rotated organization-wide. In several reported incidents, attackers exploited a partially patched system—the initial bypass was closed, but the stolen machineKey allowed them to forge ViewState and re-enter the network.

Immediate defensive actions must follow a prioritized checklist:

  1. Apply Microsoft’s security updates. Cumulative patches for SharePoint Server Subscription Edition, 2019, and 2016 address the vulnerabilities. Confirm the exact KB article for your build and install immediately. After patching, restart IIS on all servers.
  2. Enable and configure AMSI. The Antimalware Scan Interface (AMSI) integrates with Microsoft Defender Antivirus (or compatible third-party AV) to inspect web request bodies. In SharePoint, enable AMSI HTTP request body scanning in Full Mode. This blocks malicious serialized payloads at the web server level. Microsoft has confirmed that AMSI-enabled environments saw successful prevention of these exploits in testing.
  3. Rotate the ASP.NET machineKey. Use SharePoint PowerShell cmdlets (Set-SPMachineKey and Update-SPMachineKey) or the Central Administration job to generate new validation and decryption keys. Then run iisreset on every server in the farm. Rotation invalidates any stolen keys and denies attackers persistent ViewState-forgery capability.
  4. Deploy and tune endpoint detection and response (EDR). Microsoft Defender for Endpoint and other EDR platforms can detect in-memory payload execution, suspicious child processes spawned by w3wp.exe (such as cmd.exe or powershell.exe with encoded commands), and anomalous file writes to the layouts directory. Apply the detection rules published by Microsoft and CISA.
  5. Hunt for indicators of compromise (IOCs). Search all SharePoint servers for unknown files in the Layouts folder, especially names like spinstall0.aspx, spinstall1.aspx, or other suspicious .aspx files. Review HTTP logs for POST requests to ToolPane.aspx with Referer headers pointing to SignOut.aspx or similar. Implement the advanced hunting queries provided by Microsoft in Defender for Endpoint.
  6. Harder the perimeter with a web application firewall (WAF). Configure WAF rules to block or alert on requests containing /_layouts/15/ToolPane.aspx, /_layouts/15/spinstall0.aspx, and any request where the Referer header includes SignOut.aspx. Microsoft has shared sample Azure WAF custom rules that can be adapted for other WAF products. Test rules in detection mode before enforcing.

For organizations that cannot patch or enable AMSI immediately, Microsoft recommends isolating the affected SharePoint servers from the internet—placing them behind a VPN or authenticated proxy—until mitigations are in place.

If compromise is confirmed, initiate a full incident response: isolate the host, preserve forensic evidence, rotate all credentials and certificates, and assume the machineKey has been exfiltrated. A farm-wide key rotation with a controlled restart is mandatory. In severe cases, rebuilding servers from known-good images may be the safest course.

The deserialization exploit class thrives in ASP.NET and SharePoint because of how ViewState and other session objects are handled. When an application deserializes data from an untrusted source without strict validation, the process can call dangerous constructors or setter methods that lead to code execution. In this instance, the additional request-validation flaw allowed the attacker to plant the malicious object in a writable location, bypassing the usual restrictions. The combination underscores why defense-in-depth is essential: a single missing check in the application’s trust boundary can have far-reaching consequences.

Microsoft’s security update guide for CVE-2025-54897, when accessed, displays only a generic explanation of the “confidence” metric—a measure of how certain researchers are about a vulnerability’s existence and details. This suggests that the identifier may not be a publicly released CVE but perhaps an internal or pre-disclosure tracker. Defenders who encounter this ID in third-party alerts should verify it against the official MSRC portal and the National Vulnerability Database (NVD). The industrially confirmed CVEs for this campaign are the four listed above, and they are the ones associated with the available patches.

Ongoing threat intelligence paints a concerning picture. Attackers are leveraging automated scanning, rapid exploitation, and a well-developed post-exploit toolkit. In at least one case, ransomware was deployed within hours of initial access. The involvement of state-linked actors alongside cybercriminal groups means that motivations range from espionage to pure financial gain. Both are devastating to the victim.

For SharePoint farms running unsupported versions (2010, 2013), no security update is forthcoming. These systems must be isolated, migrated to a supported version, or protected with compensating controls such as WAF, network segmentation, strict access controls, and continuous monitoring. Simply hoping they won’t be discovered is not a strategy—automated scanning will find them.

Looking ahead, the frequency of deserialization bugs in Microsoft products underscores the need for a shift in development practices. The .NET ecosystem has introduced safer serialization libraries and code analyzers, but legacy components like SharePoint remain deeply embedded in enterprise IT. Until those components are retired or rewritten, patch management, runtime inspection via AMSI, and key rotation will remain the front lines of defense.

The current wave of SharePoint exploits is a stark reminder that on-premises software carries the full burden of security maintenance. Organizations that have not yet applied the latest cumulative updates should do so immediately. Enable AMSI, rotate machineKeys, and hunt for signs of past intrusion. The price of inaction is already being paid in ransomware incidents and data breaches worldwide. As Microsoft refines its advisories and the broader security community shares detection artifacts, the window for effective defense narrows. Act now to keep attackers from writing their way into your SharePoint servers.