Microsoft SharePoint Server is a popular on-prem enterprise collaboration platform tool used worldwide. It’s used for sharing intranets, document libraries, and business-process workflows in global enterprises.
In a typical enterprise setup, it handles sensitive info, such as credentials, including BDC connectors, SQL-backed content databases, Kerberos-delegating service accounts, and ASP.NET MachineKey material.
Since SharePoint functions within the organization’s trust boundary and connects to many internal systems, remote code execution can have significant security and business consequences.
CVE-2026-45659, a kind of deserialization-of-untrusted-data, is an on-prem vulnerability in the SharePoint server product line that enables an authenticated user to execute arbitrary code on the SharePoint web server in the IIS application pool identity.
In such a scenario, Site Member is the default role granted to users since it is most widely used across SharePoint sites. However, it also extends the attack surface owing to a large number of authenticated internal users in the company.
CISA has included CVE-2026-45659 in the Known Exploited Vulnerabilities category on July 1, 2026 with a deadline to resolve this by July 4, which indicates the severity of the vulnerability. This clearly means it’s not merely a routine classification.
It is to be noted that SharePoint Server is a bespoke ASP.NET application, hosted by the w3wp.exe worker process. It also fronts a SQL Server-tier holding a content database.
SharePoint carries all those attack primitives exposed by the underlying framework, its associated CVEs fall into three clusters:
- Unsafe deserialization of ViewState or control-state payloads
- Path traversal through file-serving handlers
- Authorization bypasses the multi-tenant permission model
CVE-2026-45659 falls in the first category of deserialization of-untrusted data that might turn a signed-in Site Member into a shell on the web tier.
Vulnerability Overview
An authenticated Site Member sends a request, carrying an attacker-controlled serialized .NET payload, to a SharePoint endpoint.
Now, the handler sends this payload to a permissive .NET deserializer.
Next, the deserializer initiates the gadget classes and its constructors or property setters execute the arbitrary code as the SharePoint application pool identity.
Below given three factors compound to make the CVE severe:
1. Permission Floor: To carry out this exploit, only Site Member level privilege is required, which is the lowest permission anonymous role in SharePoint.
This Site Member is a common user who has been added to this default group at the time of site creation. But they are not granted elevated privileges and this is applicable to a majority of authenticated users.
In case of any employee account, contractor account, or computer account that has ever been provisioned to access a SharePoint site, that user can reach the endpoint.
2. Deserialization sink: In the past, SharePoint servers have exposed several .NET deserialization sinks like:
- ObjectStateFormatter deserializing ViewState
- LosFormatter deserializing control state
- BinaryFormatter deserializing internal service bus payloads
- XML Serializer / DataContractSerializer on various web-service frontends.
So far, Microsoft has not released the sink targeted by the CVE-2026-45659 vulnerability. Instead, it has just chosen to issue an advisory “deserialization of untrusted data”.
This implies that it’s most likely among ASP. NET stack formatters, which is accessible via a SharePoint-specific binder.
3. Application pool identity: SharePoint web applications function under a domain service account that is typically configured with elevated privileges on the SharePoint farm. This SharePoint farm involves read/write on the content databases, Kerberos delegation to backend services, and access to MachineKey material, which includes signing the entire tenant’s ViewState. In this context, RCE is not a contained IIS worker compromise. This is a stepping stone to farm-wide credential theft and lateral movement.
Microsoft’s severity score of this vulnerability is CVSS 8.8, which is fairly high. This high score depicts this vulnerability as network-reachable, low complexity, without user interaction.
Microsoft’s advisory card lists Authentication: None and Privileges Required: Low, but the CVSS vector’s PR is what actually applies here: the attacker must hold an authenticated low-privilege account, which Site Member satisfies.
The vendor scores Scope: Unchanged. We would argue for Scope: Changed because code execution as the app-pool identity extends well beyond the compromised process, with read/write access to the content databases, access to MachineKey material, and Kerberos delegation to backend services.
Root Cause Analysis
Reading CVE-2026-45659 in isolation misses a core point and the advisory issued by Microsoft is not substantive.
It makes the CVE understandable by placing it next to its closest chronological family members:
- CVE-2025-53770 and CVE-2025-53771:ToolShell family, mid-May 2025. A pre-auth deserialization chain that ransomware groups have been prolifically exploiting. Redefined the SharePoint threat landscape overnight.
- CVE-2026-20963L: early January 2026. An unauthenticated deserialization RCE also in this same product family, that had been patched previously.
- CVE-20-2647294: twin to 45659, disclosed and patched in the same May 2026 SharePoint security update bundle. These two CVEs comprise the May 2026 SharePoint deserialization duo.
- CVE-20-2645659: our bug of interest.
A Request to an endpoint on the SharePoint web application. That endpoint takes a request parameter that eventually feeds into a permissive .NET deserializer.
The deserializer respects Serializable classes and supports reflection-assisted type creation. One end of a gadget chain is accessible through the deserialization graph that is usually some pipeline of ObjectDataProvider, TypeConfuseDelegate, DataSet, TextFormattingRunProperties, or a bespoke SharePoint type) reaches something that can execute code. That code runs in the SharePoint app pool context.
The difference between the CVEs is which endpoint they target, which formatter they target, and what minimum permission level they require.
CVE-2026-45659 required Site Member; some of the prior CVEs were unauth; some of the prior CVEs required Site Owner. They all abuse the same primitive.
The Deserialization Sinks Exposed by SharePoint
SharePoint’s attack surface for historical deserialization includes several ASP.NET formatters:
- ObjectStateFormatter: It is the ViewState serializer by default. Any endpoint that reflects the __VIEWSTATE field through the framework is a candidate sink if the MachineKey is known/stored or enable-view-state-MAC is bypassed. It’s historically one of the most impactful sinks on ASP.NET itself.
- LosFormatter: It is a limited object serializer used for control state and some other legacy scenarios. Similar gadget surface to ObjectStateFormatter.
- BinaryFormatter: Microsoft has made it obsolete by Microsoft as of .NET 5, but still present on the .NET Framework 4.X. This runs on SharePoint on-premises and is widely used in internal SharePoint service payloads.
- XmlSerializer / DataContractSerializer: It’s considered safe by construction but reachable in certain configurations. xsi:type coercion is possible when the deserializing party accepts a KnownType-relaxed graph, for example.
Microsoft has not yet shared which formatter CVE-2026-45659 abuses. The required Site Member permission reduces the attack surface. So far, we know that:
- Sinks only reachable through farm administrator endpoints are excluded.
- Sinks reachable through anonymously accessible endpoints are excluded.
The most likely targets are handlers found under _vti_bin/.asmx, _api/, or ASPX pages under /_layouts/15/.
These endpoints accept a parameter that eventually reaches a permissive formatter without proper type filtering.
Why Site Member Is the Load-Bearing Detail
Why does this matter? This is because “authenticated” isn’t a SharePoint-specific term. Here is a list of the authenticated as one of the following roles, in increasing order of privilege:
- Visitor: It is read-only.
- Site Member: It has read/write access to the site’s default lists and libraries. It can contribute to lists (create and edit items), upload documents, and post to the root document library.
- Site Owner: It has administrative control of the site.
- Farm Administrator: It holds administrative control of the SharePoint farm.
Site Member has been chosen deliberately as the lowest role that allows any site capability. In a typical enterprise SharePoint deployment, Site Member permission on the team’s primary site will be granted to all members of that team’s Active Directory group.
This means the presence of an AD account, group membership, and a SharePoint site created for that group are all that’s required to pass the CVE’s authentication check.
Now, contrast this with sibling CVE-2026-47294, from the same patch bundle. The advisory describes the same underlying class of bug (deserialization of untrusted data leading to RCE), but on different endpoints and, likely, with different permissions.
Both advisories warn that Microsoft patched similar bugs under different CVE IDs in the same update, but they omit the individual endpoints from the vendor advisory.
The Code-Execution Primitive
The specifics vary by sink, but the general form of the primitive targeting .NET deserialization stays consistent across the family:
- The formatter parses a byte stream (or XML document).
- It builds objects by reading type names from the stream, then asking the runtime to construct instances of those types.
- Some of the reconstructed types have deserialization constructors, OnDeserialization callbacks, ISerializationSurrogate implementations, or property setters that execute code at construction time.
- Find a chain of these types, an entry gadget reaching a terminal gadget, and you have arbitrary command execution.
The canonical terminal gadget in the WPF-adjacent .NET deserialization space is System.Windows.Data.ObjectDataProvide.
By setting ObjectInstance to a Process object, MethodName to “Start”, and MethodParameters to a ProcessStartInfo configured with a shell command, Process.Start(cmd) gets invoked at property setter time during deserialization.
It’s this gadget behind ~99% of deserialization RCE attacks against a .NET product over the last decade, including both the Veeam BinaryFormatter chain and the ToolShell SharePoint chain.
Whether CVE-2026-45659 triggers this exact gadget chain or a similar SharePoint-only gadget chain has not been disclosed. But this family of vulnerabilities has triggered the ObjectDataProvider chain reliably in the past, and SharePoint.exe has the framework’s WPF assemblies loaded, making the class reachable.
The Trust Boundary Question
Blacklist-style mitigations continue to fail for .NET deserialization vulnerabilities for the same reason they failed in Veeam and other similar products.
Use a wire-typed protocol like protobuf or JSON with strict schema validation, or MessagePack with an allowlist that doesn’t drive reflection-based type instantiation.
The safe-design allows allowable types via a SerializationBinder operating in allowlist mode, allowing only an explicitly defined list of allowed expected types.
Unsafe uses no binder or a blacklist-based binder. SharePoint did this for most of its existence. The same is true of .NET Framework’s built-in formatters before custom hardening.
Microsoft’s May 2026 SharePoint security advisory presumably added a check that prevents the specific gadget classes used to exploit CVE-2026-45659 from being accepted, or filters the parameter that eventually reaches the deserialization sink.
Without Microsoft releasing a patch diff, it’s almost impossible to know which approach they took. Based on the timeline of this vulnerability’s history, the latter is unlikely and that they reject that specific abused class from being deserialized.
Patch Diffing
The May 2026 Patch Bundle
CVE-2026-45659 is addressed by patches in the May 2026 SharePoint updates. This security was issued as three separate KB articles for each affected product:
- SharePoint Server Subscription Edition: build 16.0.19725.20280, KB50028{6|3}’
- SharePoint ‘Server 2019: build 16.0.10417.20128, KB5002870
- SharePoint Enterprise Server 2016: build 16.0.55{5|6}2.1002, KB50028{6|8}
The same patch package addresses CVE-2026-47294, another deserialization-related CVE. While assigned different CVE IDs by Microsoft, these two are almost certainly the same vulnerability disclosed by Microsoft as part of a single research submission. Microsoft subsequently divided into sibling CVEs by the vendor for advisory-tracking purposes.
To verify that the patch has been applied to a farm, admins will need to verify that the farm is actually running the intended build, rather than simply checking whether the KB number is present in the farm’s update history.
Microsoft instructs admins to go to Central Administration, click System Settings, and then select Manage servers in this farm. From there, ensure that the Version column reflects the desired build.
Windows Update may show that the KB was applied to the OS, but SharePoint’s configuration wizard (psconfig.exe) may not yet have installed the update on the farm. As such, the version number displayed in Central Administration is considered the authoritative source.
What the Patch Likely Changes
Without a public patch diff, we can’t know for sure, but historically speaking, .NET framework deserialization CVE patches fall into one of three categories:
1. Adding a SerializationBinder, where the vulnerable sink is calling the formatter. Deserialize without a binder argument; simply install a binder that only knows about allowed types.
2. Adding a specific type Rejecter: If a vulnerable sink is reachable and a specific gadget type is used against it, add a runtime check for that type, then throw an exception.
3. Eliminating the deserializer entirely. Replace BinaryFormatter.Deserialize with something typed. This is the correct long-term solution.
The Veeam family has exclusively used solution No 2: add a blacklist entry for each CVE because the vendor considered the pipeline difficult to remove.
The ToolShell family of patches more closely resembled solution 1 by adding a TypeFilterLevel check which constrained what the deserializer would accept. I’m of the opinion that the patch for CVE-2026-45659 will be one of these two options.
Regardless of which solution is used to handle this vulnerability, we can say with confidence that SharePoint will continue to expose a deserialization interface after this is patched.
Just because the specific code path exploited by 45659 is remediated doesn’t mean another code path exploiting the same formatter classes with user-controlled input won’t be next month’s CVE.
The Six-CVE-Bundle Question
Compared with the Veeam KB4696 package, which resolved six 2026 CVEs of internal types including deserialization, path traversal, LPE, and SQL injection, the May 2026 SharePoint bundle addresses fewer comparable vulnerabilities.
Both CVE-2026-45659 and CVE-2026-47294 are remote code execution flaws resulting from deserializing untrusted data (CWE-502) in the SharePoint web tier.
The single shape for each bundle likely indicates that one researcher or team reported both problems and that Microsoft’s internal triage found several reachable sinks with enough shared code to include in one bundle.
When your organization prioritizes the May 2026 SharePoint update for two CVEs, re-patching one does not mean the other is fixed; the affected version is still installed.
Static Analysis
The SharePoint Web Application Surface
SharePoint’s HTTP surface is unusually broad by modern standards. A single farm exposes:
- ASPX pages under /_layouts/15/: the administrative UI, most site-collection-scoped pages, and utility pages served by the framework itself.
- _vti_bin web services: legacy ASMX SOAP endpoints that survive for backward compatibility with older Office and SharePoint Designer clients. Historically, these have been a rich attack surface because ASMX endpoints often accept .NET typed parameters that flow into XmlSerializer or DataContractSerializer.
- _api REST endpoints: This is the modern client object model surface that involves JSON in, JSON out. Individual endpoints under _api can and do call into legacy code paths internally. And therefore, the wire format does not guarantee that the sink is safe.
- client.svc: the WCF hosted client object model service. Batches of REST-like calls are delivered as XML documents.
- _vti_bin/lists.asmx, _vti_bin/webs.asmx, _vti_bin/copy.asmx, and dozens of other ASMX endpoints: each with its own parameter surface.
Any of the above that call a permissive .NET deserializer on a user-supplied parameter is a potential CVE-2026-45659 sink. Without the vendor advisory naming the endpoint, a defender attempting to identify the vulnerable path from the outside would have to diff the SharePoint assemblies before and after the patch.
The changed method is the one whose call graph reached the vulnerable formatter.
The IIS Process Model
Every SharePoint HTTP request lands in an IIS worker process (w3wp.exe), with one worker process per application pool. The SharePoint web application pool runs under a domain service account configured during farm setup.
Elevated privileges on that account, including read and write access to the content databases, delegation to backend services, and access to MachineKey material, determine the blast radius of any RCE on the front end.
The process ancestry pattern creates the primary detection signal. On a secure SharePoint server, w3wp.exe legitimately spawns a small, well-known set of child processes, including the SharePoint Timer service worker, occasional OWSTIMER.EXE invocations, and a handful of framework helpers.
It does not legitimately spawn cmd.exe, powershell.exe, rundll32.exe, mshta.exe, certutil.exe, or any interactive-shell binary.
A child process of w3wp.exe matching that shape is a high-fidelity indicator that a deserialization sink has fired.
The MachineKey Question
Every ASP.NET farm has a <machineKey> element in its web . config that holds symmetric key material used to sign and encrypt ViewState, form authentication tickets, and various other framework-signed data. In a SharePoint farm, the MachineKey is farm-wide. Every front-end server uses the same key so that requests can be load-balanced across the farm.
An attacker with RCE on any front-end server can read the MachineKey from web. config. Once the MachineKey is exfiltrated, the attacker can :
- Forge signed ViewState. Every ASP.NET application on the farm that accepts a __VIEWSTATE field becomes an unauthenticated deserialization sink because the attacker can produce a validly signed payload.
- Forge form authentication tickets. If the SharePoint farm uses forms authentication, which is not the default but is common in extranet deployments, the attacker can mint arbitrary user identities.
- Persist across a patch. MachineKey material does not rotate when you install a security update. A patched SharePoint farm whose MachineKey was stolen before the patch remains vulnerable to any ObjectStateFormatter-shaped attack until an explicit MachineKey rotation is performed.
This is why serious incident response procedures for a SharePoint deserialization compromise begin with MachineKey rotation.
It is also why CISA guidance on the ToolShell family in 2025 called out MachineKey rotation as a required step even after patching. For a farm that was reachable before the patch, durable remediation for CVE-2026-45659 therefore includes not only the KB update but also MachineKey rotation on every front-end server.
Detection Fingerprints in the ULS Log
SharePoint logs ULS diagnostic events from all levels of the framework. Deserialization failures on the patched build, whether originating from a true exploitation attempt against the newly blocked type or simply from a benign request that coincidentally undergoes related validation, are logged to ULS with identifiable characteristics:
- The source of the event is the SharePoint category associated with the vulnerable endpoint.
- The exception type is System.Runtime.Serialization.SerializationException, System.Web.HttpException, or a variant defined in the ASP.NET framework itself.
- The stack trace contains calls into Deserialize, ObjectStateFormatter, LosFormatter, or BinaryFormatter defined in the framework.
The event severity is Unexpected or Monitorable.A sudden spike in ULS entries matching this pattern, especially when tied to authenticated requests from an unexpected user account or client IP, is the strongest log-based indicator that CVE-2026-45659 is being exploited against a patched host.
Conclusion
Impact
CVE-2026-45659 allows remote code execution against the SharePoint front-end web-tier like any user with the Site Member permission level.
The impact is significant because the application pool runs under a domain service account with broad privileges across the SharePoint farm. These may include read and write access to content databases, Kerberos delegation to backend systems, and access to the MachineKey material used to sign ViewState across the farm.
Code execution as this identity is only the beginning. It provides a path to full farm-wide credential theft through MachineKey access, persistent access through forged tickets, again enabled by MachineKey theft, and compromise of every system to which the SharePoint service account has delegated access.
Since the exploit only requires the Site Member permission level, it could therefore have an impact on the entire group of authenticated users in a SharePoint tenant.
This includes dormant employee accounts and contractor identities. It also includes service accounts that had access to a document library but were never removed. Any identity that was given access to a SharePoint site at any point may also fall into this category. In a real organization, this can amount to thousands of users.
Once any of these users has been authenticated, an attacker can reach the exploit path.
SharePoint also holds a special place within the broader organizational structure of most enterprises.Since it is among a few on-prem applications that regularly stores the credentials it needs to access other systems in the environment. If it is compromised an attacker will be able to read the content databases directly and, in the case of MachineKey being stolen, the ASP.NET applications in the SharePoint farm can become persistent unauthenticated deserialization vulnerabilities.
After exploitation, the domain service account also acquires any existing Kerberos delegation to backend services.
That is the reason why, since I began reporting on the product, I have observed every exploitation of a SharePoint deserialization CVE. There is a high potential return from compromised hosts whereas the barrier to entry is low.
Remediation
The immediate action you can take:
- Install the May 2026 SharePoint update on every front-end server in the farm: KB5002863 for Subscription Edition, KB5002870 for SharePoint Server 2019, or KB5002868 for SharePoint Enterprise Server 2016.
- Verify installation through Central Administration under Manage Servers in this farm.
- The Version column must show a build number at or above the fixed build for the product line. Farms in a mixed build state, where some front-end servers are patched and others are not, remain exploitable because a request can be load-balanced to any front-end server in the farm.
Beyond the patch, the two mitigations that materially reduce risk are network segmentation of the SharePoint web tier and MachineKey rotation.
Network segmentation matters because Site Member is a permission-level that any onboarded user can have. The practical exploitation risk depends on how many users can reach the SharePoint site collection from their usual work locations.
A farm reachable only from a corporate management VLAN, behind an authenticating reverse proxy that enforces additional session controls, has a materially smaller effective attack surface than one reachable from every laptop on the enterprise VPN.
Where the farm is publicly reachable, such as in an extranet deployment, the case for restricting network access is even stronger. MachineKey rotation is the mitigation of record for any farm reachable before the patch.
If the MachineKey may have been exfiltrated before the update was installed, the patch does not close the persistence primitive.Rotating the key, which means generating a new symmetric secret and pushing it to every front-end server through the SharePoint configuration wizard, invalidates any signed ViewState the attacker may have forged and closes the ObjectStateFormatter-shaped follow-on attack.
This rotation is the durable step after patching. Without it, a patched farm whose keys were stolen remains exploitable indefinitely.
In the long term, farms that can migrate to SharePoint Online or Microsoft 365 SharePoint escape this CVE class entirely because the deserialization sinks reside in the on-prem web application code path that the cloud service does not run.
This migration is a significant operational undertaking, but for organizations weighing quarterly patching against a durable end to this CVE family, it is the long-term architectural remediation.
Detection
The exploitation path leaves several reliable signals in standard telemetry.
- Process ancestry on the SharePoint web servers is the strongest single indicator. Legitimate w3wp.exe operation does not spawn cmd.exe, powershell.exe, rundll32.exe, mshta.exe, certutil.exe, or other interactive shell binaries.
A child process of w3wp.exe matching that pattern is a high-fidelity indicator that a deserialization sink has fired and the resulting shell command is running as the application pool identity. Sysmon Event ID 1 with a parent image filter on w3wp.exe and an allowlist of the small set of legitimate SharePoint child processes can detect this cleanly.
- On patched builds, the ULS log surfaces exploitation attempts as deserialization exceptions. These may appear as a System.Runtime.Serialization.SerializationException or an ASP.NET framework HttpException whose stack trace references the specific formatter class around which the CVE-2026-45659 patch added a check.
A sudden increase in ULS entries matching this signature, particularly when correlated with authenticated requests from unexpected users or client IPs, is the strongest single log-based signal that the exploit is being fired.
- Post-exploitation persistence in the SharePoint family commonly involves dropping a webshell into a SharePoint web directory. New ASPX files under \Web Server Extensions\16\TEMPLATE\LAYOUTS\, \ISAPI\, or the site’s document library storage locations, outside of a scheduled patch or deployment window, are anomalous and worth alerting on.
File integrity monitoring on the SharePoint installation directory, combined with web server log correlation for file writes, is a reliable way to detect this pattern.
At the network level, an outbound connection from any SharePoint front-end server to a destination outside the farm’s normal backend network is a strong signal. SharePoint’s legitimate egress is relatively small and well defined, including the SQL Server tier, the search service application, and occasional Microsoft update and licensing endpoints.
Beaconing traffic to an attacker-controlled C2 server or fetching a second-stage implant from an unusual destination is easier to identify against that baseline if it is being monitored.
- Cross-reference with CISA KEV. The CVE was added to the KEV catalog on 2026-07-01 with a 3-day FCEB remediation deadline, an aggressive timeline that signals observed exploitation.
Any KEV-listed CVE on your SharePoint estate justifies immediate incident response engagement rather than routine patching.
Key Takeaways
The SharePoint deserialization family is not a cluster of unique bugs, but it’s a single primitive that manifests itself at various endpoints as new frontends are evaluated. Each patch closes an entry point, but does not change the underlying serialization design. SharePoint internal service payloads continue to use .NET-native formatters for serialization. Any endpoint that allows user-controlled bytes to be fed into those formatters is vulnerable. SharePoint provides a large number of endpoints.
The playbook is simple: patch on patch-day, rotate MachineKey if you knew about it pre-patch, and consider SharePoint front-end web tier a potential-persistent-compromise vector. The CVE will change, but your defensive game should not.
References:
- https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-45659
- Microsoft MSRC advisory: CVE-2026-47294, sibling CVE in the same bundle
https://msrc.microsoft.com/update-guide/vulnerability/CVE-2026-47294 - KB5002863: SharePoint Server Subscription Edition fix
https://support.microsoft.com/help/5002863 - KB5002870: SharePoint Server 2019 fix
https://support.microsoft.com/help/5002870 - KB5002868: SharePoint Enterprise Server 2016 fix
https://support.microsoft.com/help/5002868 - CISA KEV catalog, added 2026-07-01
https://www.cisa.gov/known-exploited-vulnerabilities-catalog - NVD entry: CVE-2026-45659
https://nvd.nist.gov/vuln/detail/CVE-2026-45659 - MITRE CVE Record: CVE-2026-45659
https://www.cve.org/CVERecord?id=CVE-2026-45659 - SecurityWeek: CISA warns of actively exploited SharePoint vulnerability
https://www.securityweek.com/cisa-warns-of-actively-exploited-microsoft-sharepoint-vulnerability/
