CVE-2026-20963: SharePoint Deserialization Flaw Now Under Active Exploitation

A critical deserialization vulnerability in on-premises Microsoft SharePoint Server, tracked as CVE-2026-20963, sat quietly in January's Patch Tuesday bundle for two months before CISA confirmed it was being actively exploited in the wild. Federal agencies were given just 72 hours to patch. CISA has not yet found evidence of ransomware exploitation specifically tied to CVE-2026-20963, but given the deserialization attack class's established appeal to both espionage operators and ransomware groups, the distinction may be temporary. Many organizations still haven't patched.

Microsoft patched CVE-2026-20963 on January 13, 2026, and classified the likelihood of exploitation as "less likely." Two months later, CISA contradicted that assessment by adding the vulnerability to its Known Exploited Vulnerabilities (KEV) catalog on March 18, 2026. The Canadian Centre for Cyber Security confirmed it had also observed exploitation, issuing advisory AL26-005. CERT-EU published its own security advisory 2026-004, recommending that administrators rotate ASP.NET machine keys and enable AMSI in Full Mode as precautionary measures after patching. As of this writing, no specific threat actor has been publicly attributed, but the pattern is familiar: nation-state operators and ransomware groups have historically targeted SharePoint deserialization flaws with precision, and this one follows an exploit class they already know well.

What Is CVE-2026-20963

CVE-2026-20963 is a remote code execution vulnerability rooted in the deserialization of untrusted data, classified under CWE-502. It affects on-premises installations of Microsoft SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016. SharePoint Online in Microsoft 365 is not affected.

The vulnerability allows an unauthenticated attacker to send a specially crafted serialized payload over the network to a vulnerable SharePoint endpoint. Microsoft's own advisory states that in a network-based attack, an unauthenticated attacker could inject and execute code remotely on the SharePoint Server. The Canadian Centre for Cyber Security, in its advisory AL26-005, characterized the flaw as one that could allow "an unauthenticated remote attacker to execute code." When SharePoint processes this payload, it reconstructs the data into live application objects without validating what types of objects are being instantiated. The result is arbitrary code execution within the context of the SharePoint worker process (w3wp.exe), which typically runs under a service account with broad permissions across the server and, often, adjacent infrastructure. In MITRE ATT&CK terms, this exploitation method maps directly to T1190: Exploit Public-Facing Application, where adversaries leverage a weakness in an internet-facing system to gain initial access to a network.

CVSS scoring for this vulnerability varies across sources due to a fundamental disagreement about whether authentication is required. Microsoft's original advisory describes the attacker as "authorized" and assigns a CVSS v3.1 base score of 8.8 (AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H). However, CISA's KEV entry characterizes the vulnerability as enabling an "unauthorized attacker to execute code over a network," and SecurityWeek confirmed that Microsoft itself described the CVSS as 9.8 (AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H) in the advisory. The Canadian Centre for Cyber Security aligned with the unauthenticated characterization, describing the flaw as one that could allow an unauthenticated remote attacker to execute code. The EPSS (Exploit Prediction Scoring System) currently rates CVE-2026-20963 at 7.10% probability of exploitation in the next 30 days, placing it in the 91st percentile—meaning it is assessed as more likely to be exploited than approximately 91% of all cataloged vulnerabilities. Regardless of which CVSS score an organization uses for internal prioritization, the confirmed active exploitation makes the risk level unambiguous.

How the Exploit Works

The vulnerability exists in how SharePoint handles serialized objects within its ASP.NET application pages, particularly those under the /_layouts/ directory. When SharePoint receives serialized input, it does not treat it as passive data. It rebuilds that input into live objects in memory and executes the associated logic as part of the deserialization process. Critically, there are no effective controls restricting which object types can be created or what behavior they trigger once reconstructed.

Attackers exploit this by crafting a serialized payload using .NET gadget chains—sequences of pre-existing framework classes that, when combined in a specific order during deserialization, result in code execution. The attacker base64-encodes the payload and embeds it into a parameter such as __VIEWSTATE within a POST request directed at a vulnerable endpoint.

Once the payload reaches the deserialization routine, SharePoint reconstructs the object graph without verifying the types involved. Internal methods execute automatically during reconstruction. The resulting code runs inside w3wp.exe, inheriting the permissions of the SharePoint service account. From there, the attacker can execute system commands, deploy web shells, alter configurations, or pivot laterally into connected systems. This post-exploitation behavior maps to several MITRE ATT&CK techniques: T1059.001: Command and Scripting Interpreter – PowerShell and T1059.003: Windows Command Shell for command execution, T1505.003: Server Software Component – Web Shell for establishing persistent access, and T1210: Exploitation of Remote Services for lateral movement into adjacent systems.

The Two-Month Gap Between Patch and Exploitation

Microsoft released the patch for CVE-2026-20963 on January 13, 2026, as part of the standard Patch Tuesday cycle (KB5002822 for Subscription Edition). At the time, the advisory carried an exploitability assessment of "exploitation less likely," and the vulnerability received no special emphasis within the update bundle. According to SecurityWeek, the flaw was reported to Microsoft by an anonymous researcher.

For two months, the patch sat in release notes. Then, on March 18, CISA escalated the vulnerability to KEV status, confirming active exploitation and setting a remediation deadline of March 21—a 72-hour window under Binding Operational Directive 22-01. When Microsoft updated its own advisory on March 17, it still did not acknowledge in-the-wild exploitation, creating a disconnect between what CISA was observing and what Microsoft was officially communicating.

This gap raises difficult questions. Were threat actors quietly exploiting the flaw for weeks or months before CISA detected it? Did organizations deprioritize the patch because Microsoft's own risk assessment underestimated the threat? SharePoint updates are notoriously disruptive—they often require downtime, configuration wizard runs, and coordination across teams—which means many organizations defer them unless there is a clear and present danger signal. In this case, that signal came two months late. NIST SP 800-40 Rev. 4, Guide to Enterprise Patch Management Planning, directly addresses this pattern by framing patching as preventive maintenance rather than an optional activity—a cost of doing business that organizations cannot afford to delay when actively exploited vulnerabilities are at stake.

Affected Versions and Patch Details

The following on-premises SharePoint Server versions are affected by CVE-2026-20963:

To verify whether your environment is patched, run Get-SPProduct on each SharePoint server and check the build number against the fixed versions listed above. Any build number below the fixed version for your edition remains vulnerable.

All patches are available through Microsoft Update, the Microsoft Update Catalog, and the Microsoft Download Center. SharePoint security updates are cumulative, so organizations applying the latest available update will also receive the CVE-2026-20963 fix. Note that for Subscription Edition customers currently on the January 2026 update, upgrading directly to the March 2026 update (KB5002843) requires first installing the February 2026 update (KB5002833) and running the SharePoint Products Configuration Wizard (PSConfig) between each step.

SharePoint Online in Microsoft 365 is not affected. This vulnerability is exclusive to self-managed, on-premises deployments, including those running in cloud IaaS environments like Azure, AWS, or GCP.

SharePoint's Recurring Deserialization Problem

CVE-2026-20963 is not an isolated incident. It is the latest in a pattern of insecure deserialization vulnerabilities that have plagued SharePoint Server for years. The 2025 ToolShell campaign alone produced four CVEs across two rounds of patching: CVE-2025-49704 and CVE-2025-49706 (the original exploit chain, patched July 8, 2025), followed by CVE-2025-53770 and CVE-2025-53771 (bypass variants that emerged within days, requiring emergency out-of-band patches on July 19–22, 2025). All four were added to CISA's KEV catalog. Microsoft confirmed that Chinese nation-state actors and a ransomware operator actively exploited the ToolShell chain to deploy web shells, steal cryptographic MachineKeys, and move laterally across enterprise networks.

The root cause is systemic. SharePoint is built on a legacy .NET codebase that relies on binary serialization for handling state data, including the BinaryFormatter class that Microsoft itself has publicly deprecated and warns against using. Microsoft deprecated BinaryFormatter in .NET 9, where it now throws exceptions on use. But SharePoint's architecture predates that decision by many years, and removing the dependency would require rewriting core serialization logic that thousands of enterprise deployments depend on.

This creates an ongoing cycle: Microsoft patches one deserialization entry point, researchers or attackers discover another, and the underlying attack surface persists. The ToolShell vulnerabilities from July 2025 demonstrated this clearly—the initial patches for CVE-2025-49704 and CVE-2025-49706 were bypassed within a week, leading to CVE-2025-53770 and CVE-2025-53771. CVE-2026-20963 targets the same fundamental weakness through a different code path, and there is no reason to believe it will be the last.

Detection and Threat Hunting Guidance

Detecting exploitation of CVE-2026-20963 is challenging because the malicious payload is processed as legitimate application data. Signature-based detection alone is insufficient. Organizations should adopt a layered approach that combines application-level monitoring, endpoint telemetry, and network analysis. NIST SP 800-92, Guide to Computer Security Log Management, provides foundational guidance on establishing the log collection and analysis infrastructure necessary to support this type of threat hunting.

At the application layer, security teams should inspect incoming HTTP requests to SharePoint endpoints under /_layouts/ for anomalies in serialized data. This includes unusually structured payloads, unexpected parameter formats in __VIEWSTATE or similar fields, and request patterns that align with known .NET gadget chain structures.

On the endpoint, monitor the SharePoint worker process (w3wp.exe) for suspicious child process creation, particularly spawning cmd.exe or powershell.exe. This behavior maps to T1059.001: PowerShell and T1059.003: Windows Command Shell. Enable Windows Event ID 4688 (process creation) on all SharePoint servers and correlate with SharePoint Unified Logging Service (ULS) entries.

# Hunt for suspicious process chains from SharePoint worker process
# Windows Event ID 4688 - Process Creation
# Look for w3wp.exe spawning cmd.exe, powershell.exe, or certutil.exe

Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} |
  Where-Object { $_.Properties[13].Value -match 'w3wp\.exe' -and
    $_.Properties[5].Value -match '(cmd|powershell|certutil)\.exe' } |
  Select-Object TimeCreated, @{N='ParentProcess';E={$_.Properties[13].Value}},
    @{N='NewProcess';E={$_.Properties[5].Value}}

Additionally, scan the /_layouts/ directory tree and the SharePoint Web Server Extensions folder for recently created .aspx files that may indicate web shell deployment (T1505.003: Web Shell). Any new file appearing in these directories outside of a known update cycle warrants immediate investigation.

Mitigation Steps

The single highest-impact action is applying the January 2026 security updates. Organizations that have already applied subsequent cumulative updates (February or March 2026) are also protected, as SharePoint security updates are cumulative. This aligns with the flaw remediation requirements in NIST SP 800-53 Rev. 5, specifically control SI-2 (Flaw Remediation), which requires organizations to identify, report, and correct system flaws and install security-relevant updates within organization-defined time periods, and control RA-5 (Vulnerability Monitoring and Scanning), which mandates continuous scanning and remediation based on risk.

For environments where immediate patching is not feasible, the following interim measures can reduce exposure. These are not generic suggestions—each one targets a specific link in the CVE-2026-20963 exploitation chain.

1. Block deserialization payloads at the WAF layer: Generic WAF rules are not enough. Configure your Web Application Firewall to specifically inspect POST request bodies targeting SharePoint endpoints (particularly /_vti_bin/client.svc, /_api/, and /_layouts/ paths) for known .NET gadget chain signatures. Look for base64-encoded payloads containing indicators of ObjectDataProvider, TypeConfuseDelegate, ActivitySurrogateSelector, and BinaryFormatter class references. If your WAF supports custom rules, write pattern-matching rules that flag unusually large or structurally anomalous serialized objects in HTTP request bodies. Rate-limit POST requests to these endpoints as an additional friction layer.
2. Enable AMSI integration with full HTTP body scanning: Configure the Antimalware Scan Interface in SharePoint and deploy Microsoft Defender Antivirus (or an equivalent endpoint protection solution) on all SharePoint servers. Critically, if HTTP Request Body scanning is available, enable Full Mode—not the default partial mode. CERT-EU's advisory for CVE-2026-20963 specifically recommends enabling AMSI in Full Mode and rotating ASP.NET machine keys as precautionary measures after patching. AMSI gives the endpoint protection engine visibility into the serialized payloads before the deserialization routine processes them, which is the last opportunity to intercept a gadget chain before it executes. If AMSI cannot be enabled immediately, rotate your MachineKeys and restart IIS (iisreset) after installing the security update to invalidate any cryptographic material an attacker may have already harvested.
3. Enforce MFA on all SharePoint authentication paths: Because exploitation requires at least low-privilege authenticated access, multi-factor authentication is one of the most effective controls for breaking the attack chain at its earliest stage. Require MFA for all SharePoint access—internal and remote—and extend it to service accounts and privileged identities where possible. A single compromised credential obtained through phishing is often sufficient to deliver a deserialization payload. MFA does not prevent the vulnerability from being exploitable, but it raises the barrier from "anyone with a stolen password" to "anyone with a stolen password and a compromised second factor," which eliminates the vast majority of commodity attack scenarios.
4. Replace VPN-based SharePoint access with Zero Trust Network Access: Traditional VPNs grant authenticated users broad network-level access, which means a compromised credential provides not just a path to the deserialization endpoint but lateral movement capability across the entire network. ZTNA solutions (Microsoft Entra Private Access, Cloudflare Access, Zscaler Private Access, or equivalent) enforce per-application access policies that route users only to the specific SharePoint resources they need, without exposing the underlying network. This eliminates the VPN's implicit trust model and ensures that even a successfully authenticated attacker cannot pivot to adjacent infrastructure. For organizations that cannot deploy ZTNA immediately, place SharePoint behind a reverse proxy that restricts access by source IP, device posture, and user identity.
5. Harden IIS and lock down the LAYOUTS directory: Restrict write permissions on the /_layouts/ directory and the Web Server Extensions folder (C:\Program Files\Common Files\microsoft shared\Web Server Extensions\) to only the service accounts that absolutely require them. This limits the ability of post-exploitation web shells (T1505.003) to persist on disk. Use IIS URL Rewrite rules to block direct access to non-essential SharePoint endpoints that process serialized input. Disable any web parts, APIs, or features that your organization does not actively use—each enabled endpoint is a potential deserialization surface. Review the SharePoint application pool identity permissions with Get-SPServiceApplicationPool | Select-Object Name, ProcessAccountName and ensure the service account follows least-privilege principles.
6. Segment the network with microsegmentation, not just VLANs: Place SharePoint servers in a dedicated network segment with explicit firewall rules that deny all east-west traffic to Domain Controllers, SQL databases, file shares, and other high-value assets by default. Then allow only the specific ports and protocols SharePoint requires to function. Traditional VLAN segmentation is insufficient because flat rules within a VLAN still permit lateral movement. Microsegmentation tools (host-based firewalls, identity-aware segmentation platforms) can enforce per-process network policies, so that even if w3wp.exe is compromised, it cannot reach infrastructure that SharePoint does not legitimately communicate with. Restrict outbound internet access from SharePoint servers to only the update and management endpoints required for patching and telemetry—this blocks command-and-control callbacks that attackers rely on for post-exploitation staging. NIST SP 800-123, Guide to General Server Security, provides baseline guidance on network segmentation for server environments.
7. Audit credentials and eliminate dormant access: Review and remove unnecessary user accounts with SharePoint access. Since exploitation requires only low-privilege authenticated access, every valid credential is a potential entry point. Audit service accounts for excessive permissions, disable accounts that have not authenticated in 90 days, and remove any lingering test or developer accounts from production. Rotate passwords for all SharePoint-related service accounts, particularly the farm account and application pool identities, as a precautionary measure if you suspect any prior compromise. Pay special attention to accounts with Site Collection Administrator or Full Control web application policies—these represent the highest-risk credentials in a deserialization scenario.
8. Deploy EDR with SharePoint-specific behavioral rules: Ensure endpoint detection and response tooling is active on all SharePoint servers with rules specifically targeting the CVE-2026-20963 exploitation chain: w3wp.exe spawning child processes such as cmd.exe, powershell.exe, or certutil.exe (T1059.001); new .aspx files created in /_layouts/ or Web Server Extensions directories after the January 2026 patch date; encoded PowerShell execution from the IIS worker process context; and outbound network connections from w3wp.exe to external IP addresses. Run EDR in block mode where possible—alert-only configurations detect exploitation after the fact, but block mode can terminate the gadget chain execution before lateral movement begins. Microsoft Defender for Endpoint's Attack Surface Reduction rules provide additional coverage: enable rules that block credential theft from LSASS, block process creation from PSExec and WMI commands, and use advanced protection against ransomware.
9. Conduct a retroactive compromise assessment: Because the patch was available for two months before CISA confirmed active exploitation, organizations should not assume they are clean simply because they have now patched. Review IIS logs for suspicious POST requests containing unusually large payloads or encoded content targeting /_vti_bin/, /_api/, and /_layouts/ endpoints dating back to at least January 2026. Scan the /_layouts/ directory and Web Server Extensions folders for unexpected .aspx files created after January 13, 2026. Check Windows Event ID 4688 (Process Creation) logs for any instances of w3wp.exe spawning command interpreters. If any indicators of compromise are found, treat the SharePoint server as fully compromised: isolate it, rotate all associated credentials (including the farm account and MachineKeys), and initiate your incident response plan.

The Bigger Picture: End of Life Is Four Months Away

SharePoint Server 2016 and SharePoint Server 2019 reach end of support on July 14, 2026. After that date, Microsoft will stop releasing security updates for these versions entirely. Any new vulnerability discovered after July in either version will remain permanently unpatched.

This creates a strategic inflection point for organizations still running on-premises SharePoint. CVE-2026-20963 is a manageable problem today because a patch exists. The next deserialization flaw discovered in SharePoint 2016 or 2019 after end of support will not have that option. Organizations running these versions need to be planning their migration path now—whether to SharePoint Subscription Edition, SharePoint Online, or an alternative platform—because the window for supported, patched on-premises operations is closing rapidly. NIST SP 800-40 Rev. 4 explicitly addresses this scenario in its guidance on unpatchable assets, recommending that organizations plan for end-of-life transitions as part of their overall patch management strategy rather than accepting the cumulative risk of running unsupported software.

The broader reality is that on-premises SharePoint carries an inherent patching liability that cloud-hosted alternatives do not. SharePoint Online receives automatic security updates from Microsoft with no downtime, no PSConfig wizards, and no emergency 72-hour deadlines. Every month that an organization defers migrating is another month of exposure to the next vulnerability in a codebase that has proven, repeatedly, that its deserialization attack surface is far from fully resolved.

Knowledge Check

Frequently Asked Questions

Organizations running on-premises SharePoint in any version should treat CVE-2026-20963 as an immediate patching priority. The confirmed exploitation, the low barrier to entry for attackers, and the high-value data typically stored in SharePoint environments make this a vulnerability that cannot wait for the next maintenance window.