Microsoft’s SharePoint on-premises ecosystem is once again at the center of a high-risk security incident: an untrusted-deserialization remote code execution (RCE) class of weaknesses is being actively exploited against internet-facing SharePoint Server deployments, and an exact CVE identifier supplied in some tickets — CVE-2025-54897 — could not be reliably corroborated in public vendor and vulnerability databases at the time of reporting. The practical effect documented by Microsoft and multiple industry responders is clear and urgent: attackers are delivering serialized payloads that SharePoint servers deserialize, leading to web‑shells, theft of ASP.NET machineKey material, forged __VIEWSTATE payloads and persistent remote code execution — a chain that has already been used to deploy ransomware and high-impact post‑exploit tooling. (msrc.microsoft.com)
Microsoft’s public guidance and coordinated government advisories describe a cluster of related SharePoint vulnerabilities that together permit a particularly dangerous exploit chain. The vulnerabilities fall into two practical categories: an authentication/spoofing weakness that allows crafted requests to bypass server-level checks, and an unsafe-deserialization flaw that executes attacker-supplied objects during object reconstruction. When chained, these weaknesses enable attackers to write webshells into SharePoint’s layouts directory, extract cryptographic material (the ASP.NET machineKey), and then forge signed __VIEWSTATE entries to achieve persistent, stealthy code execution. (msrc.microsoft.com, cisa.gov)
Microsoft’s emergency guidance treats these flaws as an urgent operational priority for on‑premises SharePoint Server customers — SharePoint Online (Microsoft 365) is not affected — and prescribes immediate patching, enabling the Antimalware Scan Interface (AMSI), rotation of machineKey values, and endpoint detection controls as the frontline mitigations. (msrc.microsoft.com)
If your internal tickets or third‑party advisories reference CVE‑2025‑54897, treat that label as potentially a transposition, vendor-mapping, or local tag until you can confirm the authoritative MSRC/NVD entry. Flagging ambiguous CVE numbers is essential because mitigation steps and KB identifiers are tied to specific advisories.
Every hour unpatched internet-facing SharePoint servers remain exposed increases the likelihood of compromise and makes remediation more complex and costly; for infrastructure owners, swift, coordinated action is the only responsible path forward.
Source: MSRC Security Update Guide - Microsoft Security Response Center
Background / Overview
Microsoft’s public guidance and coordinated government advisories describe a cluster of related SharePoint vulnerabilities that together permit a particularly dangerous exploit chain. The vulnerabilities fall into two practical categories: an authentication/spoofing weakness that allows crafted requests to bypass server-level checks, and an unsafe-deserialization flaw that executes attacker-supplied objects during object reconstruction. When chained, these weaknesses enable attackers to write webshells into SharePoint’s layouts directory, extract cryptographic material (the ASP.NET machineKey), and then forge signed __VIEWSTATE entries to achieve persistent, stealthy code execution. (msrc.microsoft.com, cisa.gov)Microsoft’s emergency guidance treats these flaws as an urgent operational priority for on‑premises SharePoint Server customers — SharePoint Online (Microsoft 365) is not affected — and prescribes immediate patching, enabling the Antimalware Scan Interface (AMSI), rotation of machineKey values, and endpoint detection controls as the frontline mitigations. (msrc.microsoft.com)
Why this is materially dangerous
- High-privilege execution context: SharePoint typically runs inside the IIS worker process (w3wp.exe), which often runs at elevated privileges or with access to sensitive enterprise resources. Code executed here can be leveraged to pivot laterally into domain resources.
- MachineKey theft enables persistence: If attackers can extract the ASP.NET machineKey (ValidationKey and DecryptionKey) from web.config or memory, they can craft validly-signed __VIEWSTATE payloads that SharePoint will accept later — effectively creating a robust persistence mechanism that survives some partial remediations. (msrc.microsoft.com, bitdefender.com)
- Real-world exploitation and ransomware: Multiple incident responders and news reports confirm active exploitation and subsequent deployment of ransomware families in at least some intrusions, elevating this from a theoretical risk to an operational crisis for affected organizations. (itpro.com, tomshardware.com)
- Patch bypasses and chained exploits: Attackers have demonstrated the ability to chain multiple problems (authentication bypass + deserialization), and in several cases to bypass initial patches, creating emergent CVEs that effectively re‑weaponize earlier defects. This means defenders must treat “patched” status with caution and follow vendor guidance closely. (bleepingcomputer.com, bitdefender.com)
The attack chain, step by step
1. Reconnaissance
Automated scanning locates internet‑facing SharePoint endpoints and probes for vulnerable versions and known endpoint patterns (e.g., ToolPane.aspx, SignOut.aspx). Public-facing SharePoint farms are high-value targets because they expose the application to unauthenticated HTTP(S) requests.2. Authentication/spoofing bypass
An attacker crafts a POST to an administrative layout endpoint (commonly /_layouts/15/ToolPane.aspx?DisplayMode=Edit) while manipulating the Referer header (e.g., setting it to /_layouts/SignOut.aspx) to trick server-side validation into allowing file writes to the layouts directory. This bypass is typically associated with an improper authentication or request-validation weakness.3. Unsafe deserialization and shell drop
The attacker then submits a serialized payload (an encoded .aspx, a ViewState-based serialized object, or a specially-crafted object blob) that SharePoint’s deserialization logic reconstructs without adequate validation. During deserialization, code paths are invoked that allow arbitrary code execution, resulting in the server writing an ASPX webshell like spinstall0.aspx into the layouts folder. (bitdefender.com)4. MachineKey extraction
Once a webshell is present, it can execute code to enumerate files, read web.config, extract ASP.NET machineKey values (ValidationKey/DecryptionKey), and exfiltrate those keys. Possession of machineKey permits forging of validly signed __VIEWSTATE payloads. Attackers use these forged viewstate payloads to inject additional serialized objects and regain trusted execution even after partial patches. (bitdefender.com)5. Post-exploit activity
After gaining code execution and cryptographic leverage, attackers often:- Deploy additional backdoors and webshells;
- Harvest credentials (Mimikatz-style tooling);
- Move laterally using tools like Impacket or PsExec;
- Exfiltrate sensitive documents and credentials; and
- Deploy ransomware or other destructive payloads. (bitdefender.com)
Confirming the CVE: verification note and caution
The CVE number you provided (CVE-2025-54897) could not be located on Microsoft’s publicly accessible Security Update Guide in a non‑JavaScript rendering nor in independent vulnerability trackers during verification checks; MSRC content may require JavaScript to reveal details. Microsoft’s published emergency guidance and multiple coordinating advisories focus on the cluster identified by other CVE numbers — notably CVE‑2025‑49704, CVE‑2025‑49706 and the subsequently observed bypasses tracked as CVE‑2025‑53770 and CVE‑2025‑53771. Defenders should validate any CVE identifier in their ticketing or tracking systems against the Microsoft Security Update Guide and the NVD before acting on a numeric tag alone. (msrc.microsoft.com, cisa.gov)If your internal tickets or third‑party advisories reference CVE‑2025‑54897, treat that label as potentially a transposition, vendor-mapping, or local tag until you can confirm the authoritative MSRC/NVD entry. Flagging ambiguous CVE numbers is essential because mitigation steps and KB identifiers are tied to specific advisories.
Immediate defensive checklist (prioritized)
- Apply Microsoft’s security updates for supported SharePoint Server versions (Subscription Edition, 2019, 2016) immediately. Security updates are cumulative; confirm the correct KB for your build. (msrc.microsoft.com)
- Enable and configure the Antimalware Scan Interface (AMSI) in SharePoint, and deploy Microsoft Defender Antivirus (or an enterprise AV with AMSI hooks) on all SharePoint servers. If AMSI HTTP request body scanning is available, enable Full Mode. AMSI + Defender provide prevention and detection of malicious payloads arriving in HTTP bodies. (msrc.microsoft.com)
- Rotate ASP.NET machineKey values and restart IIS on every SharePoint host after applying updates or enabling AMSI. Use PowerShell commands: Set‑SPMachineKey and Update‑SPMachineKey (or the Central Administration job), then run iisreset. Rotation invalidates any stolen keys. (msrc.microsoft.com)
- Deploy and harden endpoint detection (EDR) and Microsoft Defender for Endpoint to detect in‑memory payloads, suspicious child processes of w3wp.exe, and encoded PowerShell activity. (cisa.gov)
- Inspect Layouts directories for unknown files such as spinstall0.aspx and search historical logs for POST requests to ToolPane.aspx with suspicious Referer headers. Microsoft supplied Defender query examples for hunting; implement these promptly. (bleepingcomputer.com)
- If AMSI cannot be enabled quickly, consider isolating affected servers from the Internet (or placing them behind an authenticated VPN/proxy) until patches and mitigations are fully applied. (msrc.microsoft.com)
Detection and hunting guidance
- Search for suspicious files in the Layouts folder (example filename: spinstall0.aspx). Microsoft published Defender hunting queries to detect these artifacts; deploy them immediately across telemetry sources. (bleepingcomputer.com)
- Hunt for unusual spawning of cmd.exe or powershell.exe by w3wp.exe and for encoded Base64 command lines in process creation events.
- Deploy SIGMA/YARA and EDR rule packs published by CISA and security vendors to detect known IOC patterns, DLL sideloading, and webshell behaviors. (cisa.gov)
- Deploy WAF rules to block and log requests that match the ToolPane/SignOut patterns and heavy Base64 POST bodies targeting layouts endpoints. Microsoft/TechCommunity published example Azure WAF custom rules to help block the known request patterns. (techcommunity.microsoft.com)
Practical WAF rule example (illustrative)
- Block URIs containing /_layouts/15/ToolPane.aspx or /_layouts/15/spinstall0.aspx
- Block or alert when the Referer header contains /_layouts/SignOut.aspx or similar
Remediation and incident response considerations
- If you confirm compromise, isolate the host immediately, preserve forensic artifacts, and assume that cryptographic material and credentials may be exfiltrated. Rotate credentials and certificates across the environment and consider rebuilding critical hosts from known-good images.
- After remediation (patching + machineKey rotation + restart), continue to hunt in historical logs — many campaigns used automated scanning and may have been active prior to detection. Evidence of webshell drop or unusual post-exploit behavior indicates a broader in‑network incident.
- If machineKey compromise is suspected, plan for farm-wide key rotation and a controlled restart window for all SharePoint nodes, validating the operation on test systems first. (msrc.microsoft.com)
Technical analysis: why deserialization matters in SharePoint
Deserialization is the process of reconstructing complex objects from a serialized representation. When an application deserializes untrusted or attacker-controlled data without strict validation, the deserialization process can invoke object constructors or methods that execute arbitrary code. In ASP.NET and SharePoint contexts, serialized viewstate or object blobs that are accepted and deserialized can trigger such code paths. The combination with improper request validation (enabling file writes to layouts) magnifies the impact — allowing an unauthenticated or semi‑authenticated attacker to get arbitrary code executed within the web server. This pattern has long been a favored avenue for web application exploitation and has real operational consequences when the target is a widely deployed enterprise product like SharePoint.Who’s exploiting this and what’s being observed
Threat intelligence and media reports show both financially motivated ransomware actors and state‑linked groups exploiting these SharePoint flaws. Microsoft and multiple security vendors have observed exploitation beginning in July 2025 and continuing in waves, with attributed activity involving Chinese-affiliated groups (Storm‑2603, Linen Typhoon, Violet Typhoon) as well as criminal ransomware operators deploying Warlock and other families in compromised environments. The activity includes webshell installation, machineKey exfiltration, and follow-on lateral movement. (tomshardware.com, techradar.com)Risk assessment and operational recommendations
- High priority for internet-facing SharePoint servers: Treat any externally accessible SharePoint farm as critical until patched, AMSI-enabled, and machineKeys rotated.
- Legacy versions remain exposed: Unsupported SharePoint versions (2010/2013) will not receive fixes; affected organizations must either isolate, migrate, or implement robust compensating controls (WAF + VPN + strict egress/ingress filtering). (techcommunity.microsoft.com)
- Patch-and‑verify approach only works with deep telemetry: After patching, validate that WAF/EDR/AV detections are firing and that machineKey rotation has been completed farm‑wide, and continue threat hunting. (msrc.microsoft.com)
Cross-check & verification summary
- Microsoft’s MSRC guidance, CISA advisories, and multiple vendor write‑ups converge on the same operational facts: deserialization‑based RCE chains exist against on‑prem SharePoint Server and are being exploited in the wild; mitigation requires patching, AMSI enablement, EDR deployment, and machineKey rotation. (msrc.microsoft.com, cisa.gov, bleepingcomputer.com)
- The singular CVE identifier provided (CVE‑2025‑54897) could not be directly validated in MSRC’s update guide under JS-disabled rendering and was not found in independent trackers during verification; authoritative advisories focus on the CVEs enumerated above (CVE‑2025‑49704, CVE‑2025‑49706, CVE‑2025‑53770, CVE‑2025‑53771). Treat numerical labels cautiously and confirm them in the vendor's advisory before mapping to KBs and tickets.
Conclusion
The SharePoint deserialization-to-RCE campaigns represent a textbook example of why chained application-layer weaknesses are so destructive: relatively small coding or validation errors can be combined into an exploit that produces webshells, forges cryptographic material, and enables durable persistence — culminating in credential theft, ransomware, and full network compromise. Defenders must act now: verify the precise CVE and KBs for their SharePoint builds, apply the cumulative updates Microsoft published, enable AMSI and enterprise AV, rotate machineKeys after patching, deploy EDR and WAF protections, and hunt aggressively for webshells and anomalous IIS behavior. If any ambiguity exists around a CVE identifier in internal tracking, escalate to confirm the authoritative MSRC advisory and coordinate remediation based on the vendor’s published mitigation steps rather than a lone numeric label. (msrc.microsoft.com, cisa.gov, techcommunity.microsoft.com)Every hour unpatched internet-facing SharePoint servers remain exposed increases the likelihood of compromise and makes remediation more complex and costly; for infrastructure owners, swift, coordinated action is the only responsible path forward.
Source: MSRC Security Update Guide - Microsoft Security Response Center
