One Request, Total Persistence: Inside the SharePoint Flaw Attackers Are Exploiting

Summary

Vulnerability Details

Root Cause Analysis

CVE-2026-50522 stems from unsafe deserialization of untrusted data inside SharePoint Server. Deserialization vulnerabilities in .NET-based applications like SharePoint typically follow a well-established pattern: an application accepts a serialized object, often embedded in a ViewState, Web Part property, or API payload, and reconstructs it into a live .NET object without adequately restricting which types that data is allowed to instantiate. If an attacker can control the serialized bytes reaching that reconstruction step, they can craft a payload that instantiates a chain of otherwise-legitimate .NET classes, a technique commonly known as a "gadget chain," whose side effects during construction or disposal ultimately execute attacker-controlled code in the context of the SharePoint service account.

Microsoft has not published the specific code path or vulnerable component involved, consistent with its standard practice of withholding exploit-enabling detail from public advisories. What is confirmed is the vulnerability class (CWE-502) and the outcome: a request reaching the vulnerable deserialization logic results in arbitrary code execution on the server, with no memory-corruption exploitation reliability concerns of the kind seen in native-code vulnerabilities, deserialization bugs in managed languages tend to be dependable once a working gadget chain exists for the target's SharePoint version.

How CVE-2026-50522 Can Be Exploited

Attack prerequisites

1. 1. A reachable, on-premises SharePoint Server instance running Subscription Edition, 2019, or 2016 Enterprise.
2. 2. Per Microsoft's advisory, an attacker account already authenticated with at least Site Owner-level permissions on the target SharePoint site.
3. 3. Network reachability to the SharePoint web front-end, whether directly internet-facing or reachable from an already-compromised internal position.

Conceptual exploitation flow

1. 1. The attacker authenticates to the target SharePoint site with Site Owner-level access, either through legitimate credentials, a phished account, or access obtained via a prior intrusion.
2. 2. Using Site Owner privileges, the attacker reaches a SharePoint feature that accepts and processes serialized .NET object data as part of its normal function, such as a Web Part property, an exposed API endpoint, or a ViewState-processing page. This is the surface the public proof-of-concept targets, since it is the point where attacker-supplied bytes flow directly into SharePoint's deserialization logic.
3. 3. Rather than inventing a new gadget chain from scratch, the exploit builds on publicly cataloged .NET deserialization gadget chains, well-documented sequences of otherwise-legitimate framework classes whose constructors or destructors can be chained together to execute arbitrary commands once instantiated. The attacker selects a gadget chain compatible with the assemblies loaded in a standard SharePoint installation.
4. 4. The chosen gadget chain is serialized into the object format SharePoint expects at that endpoint, wrapped with whatever formatting or encoding the target feature requires (for example, Base64 encoding within a ViewState field or a JSON/XML envelope for an API payload), and embedded in an otherwise normal-looking HTTP request to the vulnerable endpoint.
5. 5. SharePoint deserializes the request without adequately validating which object types it is being asked to reconstruct. As the gadget chain's objects are instantiated, their chained side effects execute the attacker's embedded command, resulting in arbitrary code execution in the context of the SharePoint service account.
6. 6. With code execution established, observed activity shows attackers immediately issuing a single follow-up request to extract the server's IIS machine keys.
7. 7. The stolen machine keys let the attacker forge valid ViewState and authentication tokens independent of the original vulnerability, preserving access even after the SharePoint farm is patched, unless the keys themselves are rotated.

Impact

MITRE ATT&CK Mapping

Mitigation

1. 1. Apply Microsoft's July 2026 security update immediately.
2. 2. Rotate IIS machine keys on every SharePoint server, regardless of patch status.
3. 3. Audit for prior exploitation.
4. 4. Enable AMSI integration in SharePoint Server 2016 and 2019.
5. 5. Restrict and monitor Site Owner-level account provisioning.
6. 6. Limit direct internet exposure of on-premises SharePoint front-ends

Instantly Fix Risks with Saner Patch Management