One Site Member Login and SharePoint Runs Your Payload: CVE-2026-45659 Lands on CISA's KEV

Every corporate SharePoint tenant has hundreds of Site Members. Contractors, project rooms, external collaborators, the intern who needed doc access last quarter and still shows up in the directory. Microsoft's advisory for CVE-2026-45659 says an attacker needs "a minimum of Site Member permissions" to trigger a remote code execution, and that phrasing is doing a lot of work. Any account in that ocean of low privilege users can feed a serialized payload straight into a legacy .NET deserializer, and CISA now says attackers are already doing it.

The CVE sat quiet for six weeks. Microsoft patched it in May 2026, initially with an "Exploitation Less Likely" tag and even omitted the CVE from the first cut of the May Security Updates before quietly correcting the advisory. On July 1 CISA added it to the Known Exploited Vulnerabilities catalog with a July 4 deadline for FCEB agencies; everyone else running on-prem SharePoint should read that as their deadline too.

What sits behind Update() on a list item

The vulnerable code path lives in Microsoft.SharePoint.Library. When a Site Member updates a list item, SharePoint walks the item's custom fields, hands their serialized values to the framework, and rehydrates them so the field control can render or store the new state. For a specific class of custom field types with ViewState style serialization, that rehydration call is LosFormatter.Deserialize, applied straight to the bytes we sent in through the Update() method. There is no MAC check on the payload, no type allowlist wrapped around the formatter, no ObjectStateFormatter restriction, no sign that the code ever expected the field value to be adversarial.

LosFormatter is one of those .NET primitives most defenders have already met through ysoserial.net. It is the underlying serializer behind ASP.NET ViewState, and it will happily reconstruct arbitrary CLR types from a base64 encoded blob. Give it a payload that ends in a gadget chain like TypeConfuseDelegate, TextFormattingRunProperties, or ActivitySurrogateSelector, and the process running the deserializer runs whatever the last gadget cooks up. In SharePoint that process is w3wp.exe, running as the SharePoint web application service account.

The reason this is a bug at all is that SharePoint treats a serialized custom field as trusted state. In its mental model any authenticated user with contribute rights was already allowed to write items to lists, so their submitted data was already inside the trust boundary. What the code missed is that "data" was actually "arbitrary types the CLR will instantiate for you," and the trust boundary was drawn in the wrong place. CWE-502, a deserialization of untrusted data flaw, is the exact label the NVD entry carries.

The exploit shape from the outside

From the wire, exploitation looks almost boring. A low privilege session posts to a list update endpoint (the standard REST paths under _api/web/lists('...')/items, or the equivalent CSOM XML over /_vti_bin/client.svc/ProcessQuery), containing a value for one of the affected custom field types. Inside that value sits a base64 encoded LosFormatter payload whose final gadget spawns a System.Diagnostics.Process starting cmd.exe or powershell.exe. SharePoint dutifully rehydrates the object graph, invokes the deserialization gadget, and the payload runs under the SharePoint app pool identity.

An .aspx webshell then drops into _layouts or _catalogs/masterpage, wired into the SharePoint config so the attacker can return through an unauthenticated endpoint with signed headers. The more painful piece for most environments is that the SharePoint service account is often a Domain User with far more access than the SharePoint team ever inventoried: farm passphrase, connected content databases, sometimes a delegated MSA that can pull keys out of the SharePoint secure store. The RCE is the entry; the SharePoint identity is what turns one compromised server into a domain problem.

Why the request looks legitimate to every control in the path

Nothing about a Site Member submitting a list item update is suspicious. The auth is legitimate, the endpoint is a first party SharePoint URL, the TLS is valid, the user agent matches office workstations. A perimeter WAF sees an authenticated POST to a REST endpoint, and a CASB or EDR looking at the client sees an ordinary user opening a browser tab. The malicious primitive is inside the request body, wrapped in a serialization format that most inline controls can't parse and wouldn't recognize as executable even if they did.

That leaves your SOC with two real vantage points: the SharePoint app server itself, watching w3wp.exe for signs it spawned something it should never spawn, and the network egress from that server, watching for outbound connections the SharePoint role has no legitimate reason to make. Both are behavioral, and both need policy work before an alert is worth waking anyone up.

Where the log signal actually lives

At the host level, the tell is w3wp.exe (specifically the app pool worker for a SharePoint Web Application) becoming the parent of a command interpreter or scripting host: cmd.exe, powershell.exe, wscript.exe, mshta.exe, or rundll32.exe. A public Splunk analytic, Windows Suspicious Child Process Spawned From WebServer, already covers that shape and is one of the more valuable no-cost detections you can turn on today. In Sentinel the equivalent hunt is a DeviceProcessEvents query where the parent image is w3wp.exe on a SharePoint role and the child image is a scripting or LOLBin binary. Map to T1190 (Exploit Public Facing Application) for initial access, T1059.001 (PowerShell) for the follow-on, and T1505.003 (Server Software Component: Web Shell) once you see any freshly written .aspx under LAYOUTS or TEMPLATE\LAYOUTS.

At the SharePoint layer, ULS logs record REST and CSOM traffic with the caller identity. Alerting on ordinary list updates alone would set fire to your SIEM; what is worth paging on is the correlation between a low privilege account posting a list item update and the same app pool spawning a script host or writing a new file under LAYOUTS within seconds. Keep IIS logs alongside so the request URL and identity are preserved for post incident work.

The network signal is thinner but useful. A SharePoint app server initiating outbound TCP to a public IP that isn't Microsoft Update, WSUS, or your monitoring stack is unusual enough to flag. Run that against your DNS logs for the same host and you often catch the second stage callback before the operator settles in.

What to do this week

Patching is the whole answer if you can move. Apply Microsoft's May 2026 SharePoint updates, and for Subscription Edition confirm the build is 16.0.19725.20280 or later, the fixed build Microsoft and CISA both call out. For SharePoint Server 2019 and Enterprise Server 2016 the May 2026 cumulative updates carry the fix as well; the CVE was inadvertently omitted from Microsoft's first published list, so double check the KB against the updated advisory rather than relying on your patch dashboard's original mapping.

If you can't patch this week, take SharePoint off the public internet, tighten Site Member enrollments, and audit which accounts hold that permission across every site collection. Turn the ULS plus process telemetry described above into alerting rather than logging. Rotate the SharePoint managed accounts and the farm passphrase after patch, because if the bug was exploited before you closed it, those credentials are the pivot to everything else.

Verification matters. A patched binary is not proof that the patch fixed anything in your fleet: a reboot missed on one WFE, a paused Windows Update job, a rolled back CU after a compatibility complaint from Finance, any of those quietly leaves a hole. Run a benign simulated payload after patching, a serialized object that logs rather than executes, and confirm SharePoint rejects it. Then keep replaying it on a schedule so a future rollback shows up as a failing test rather than a headline.

Where this sits for us

The reason this bug landed the way it did is that the detection story and the validation story are two different problems, and most blue teams run them out of two different tools that don't talk to each other. BlueTeamAutomation runs BASzy safe payload simulations against your fleet on a schedule, correlates the results with your EDR and SIEM signals, and drives the response and the compliance evidence through the same SOAR loop, so the detection you wrote and the proof it works stay live instead of being a one time scramble.