SharePoint CVE-2026-45659: Patched in May, Exploited in July

On July 1, 2026, CISA added CVE-2026-45659 to its Known Exploited Vulnerabilities catalog and gave U.S. federal agencies until July 4 to patch or pull affected servers offline. The vulnerability is a remote code execution flaw in on-premises Microsoft SharePoint Server. Microsoft had already fixed it — back on May 26, 2026. The problem is that almost nobody knew, because the CVE was, in Microsoft's own words, "inadvertently omitted from the May 2026 Security Updates." A patch shipped. The line item that would have told anyone to install it did not.

That is the whole story in one sentence: a critical SharePoint RCE was available as a patch for five weeks while defenders had no CVE to track, no bulletin entry to prioritise, and no reason on their patch dashboard to touch it. Then attackers found it. This is the second summer in a row that on-prem SharePoint has become the industry's problem, and the mechanism of failure this time is not a zero-day — it is a blind spot in how organisations decide what to patch.

Inside CVE-2026-45659: authenticated deserialization to RCE

CVE-2026-45659 is an insecure-deserialization bug (CWE-502) carrying a CVSS score of 8.8. It affects SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016 — the entire supported on-prem line. SharePoint deserialises attacker-controlled data without validating it, so a crafted serialized payload is reconstructed into live objects on the server and reaches code execution.

The access requirement is the detail that matters. Per Microsoft's advisory, "any authenticated attacker could trigger this vulnerability. It does not require admin or other elevated privileges." In practice that means valid credentials plus Site Member permissions — the level granted to ordinary contributors on a SharePoint site. Not a farm admin. Not an owner. A member who can add content.

This lowers the bar in a way that maps cleanly onto real intrusions. Site Member is exactly what an attacker holds after any of the routine first moves: a phished set of Microsoft 365 or AD credentials, a password sprayed against an exposed OWA/ADFS endpoint, a valid session lifted from an infostealer log. On-prem SharePoint is rarely internet-facing by design, but it is almost always reachable from the internal network — which is the network an attacker is standing on the moment they have one working account. Deserialization RCE from a low-privilege authenticated context turns "I have a foothold" into "I own the box that holds your contracts, HR files, and legal documents," to borrow the asset list Black Duck's Robert Coles used when describing why SharePoint is worth the effort.

The CVSS 8.8 rating understates the operational value. SharePoint sits on the identity plane: it runs as a service account with reach into the farm, it stores the documents an attacker wants, and it is trusted by everything around it. RCE there is a pivot point, not a dead end.

The patch no one could see

The reason this became a KEV entry rather than a routine May patch is a process failure, not a technical one. Microsoft addressed the flaw in the May 2026 cumulative updates but left the CVE off the published Security Update Guide. Organisations that install every cumulative update regardless of contents were quietly protected. Organisations that drive patch decisions by bulletin — risk-rank the listed CVEs, schedule the criticals, defer the rest — never saw it. There was nothing to rank.

This is a common operating model, not negligence. Large SharePoint estates do not blindly apply every cumulative update on release; they test, they stage, they prioritise by severity, and severity comes from the bulletin. Remove the CVE from the bulletin and the flaw becomes invisible to the exact process most enterprises use to stay current. As Black Duck's Ben Ronallo put it, "patch bulletins are a starting point, not a substitute for verifying what's actually running."

That sentence is the lesson of the whole incident. A vulnerability scanner keyed to CVE feeds had nothing to fire on for five weeks. A compliance report that asks "are we patched against known criticals?" answered yes while the box was exploitable. The only signal that would have caught this is one that ignores the catalogue entirely and asks a different question: if I attack this server the way an attacker would, does it fall?

SharePoint on-prem, one year after ToolShell

CVE-2026-45659 lands almost exactly a year after the July 2025 ToolShell campaign, and the pairing is instructive. ToolShell chained CVE-2025-53770 — an unauthenticated deserialization RCE rated CVSS 9.8 — with an auth-bypass to hit SharePoint with no credentials at all. Per Palo Alto Unit 42's threat brief, exploitation began around July 7, 2025, before the patch, and compromised 85+ servers across 29 organisations in the first wave. Imperva logged over 60,000 attack attempts in a single day. Three China-nexus groups — Linen Typhoon, Violet Typhoon, and Storm-2603 — were tied to the campaign, and Microsoft's own guidance had to tell customers that patching alone was insufficient because the attackers had stolen ASP.NET machine keys and could forge access post-patch.

	ToolShell (CVE-2025-53770)	CVE-2026-45659
Disclosed	July 2025 (zero-day)	May 2026 (silent patch)
Auth required	None (unauth)	Site Member (authenticated)
CVSS	9.8	8.8
Root cause	Deserialization + auth bypass	Deserialization (CWE-502)
Failure mode for defenders	Faster than the patch	Patch existed but was invisible
Post-patch risk	Stolen machine keys	Assumed same — rotate keys

The two flaws are different in mechanism but identical in what they say about the surface. On-prem SharePoint is a deserialization-rich, identity-adjacent, hard-to-decommission platform that attracts state-aligned and criminal attention every single time a class of bug surfaces. The 2026 case is arguably worse for defenders precisely because it looks quieter: no dramatic zero-day headline, no 60,000-attempts-per-day telemetry spike, just a flaw that sat patched-but-untracked until exploitation forced CISA's hand. The Register noted that Microsoft's public exploitability assessment was "Less Likely" right up until CISA confirmed the opposite.

"We're fully patched against the May criticals — I ran the report Monday." "Which report?" "The scanner. It pulls the CVE feed, cross-references our builds, flags anything on the KEV list. We're clean." "CVE-2026-45659 wasn't in a bulletin until this week. It wasn't in your feed in May. What did the scanner have to match against?"

That exchange is the gap between compliant and not exploitable. They are not the same property, and this CVE is the proof.

Remediation

A complete runbook for CVE-2026-45659. Do these in order.

1. Am I affected?

Check the farm build version. From the SharePoint Management Shell on any farm server:

(Get-SPFarm).BuildVersion

Compare against the fixed builds below. Any build lower than your edition's fixed build is vulnerable:

• SharePoint Server Subscription Edition — fixed in 16.0.19725.20280
• SharePoint Server 2019 — fixed in 16.0.10417.20128
• SharePoint Enterprise Server 2016 — fixed in 16.0.5552.1002

If your last cumulative update predates the May 2026 release (roughly, servers not patched since May 21, 2026), assume vulnerable until proven otherwise. Do not rely on "we had no open critical CVEs in May" — the CVE was omitted from that bulletin.

2. Patch — exact fixed versions

Install the May 2026 (or later) cumulative update for your edition to reach the fixed build above. Per Microsoft, systems that already installed the May 2026 updates need no further action — the fix is in that package even though the CVE was not listed. Confirm the resulting build with (Get-SPFarm).BuildVersion after PSConfig completes. The MSRC advisory is the authoritative source for per-edition KB packages.

3. Can't patch tonight? Compensating controls

• Cut off pre-auth reachability. Since exploitation requires an authenticated Site Member, tighten who can reach the SharePoint web front-ends: restrict to VPN/ZTNA, enforce MFA on every account that can log into a SharePoint site, and remove stale Site Member grants.
• Deploy AMSI in Full Mode for SharePoint (supported on SE, 2019, and 2016 with recent updates). AMSI integration is the single most effective mitigation Microsoft shipped for the SharePoint deserialization class — it inspects the request body before the payload is deserialised.
• Front the farm with a WAF rule that inspects POST bodies to /_layouts/ and /_vti_bin/ endpoints for serialized .NET payloads (__VIEWSTATE anomalies, TypeConfuseDelegate/ObjectDataProvider gadget markers).

4. Hunt for compromise

Deserialization RCE on SharePoint has a consistent post-exploitation shape. Map your hunt to MITRE ATT&CK:

• T1190 (Exploit Public-Facing Application) → T1059.001 (PowerShell) / T1059.003 (cmd): hunt for w3wp.exe (the SharePoint IIS worker) spawning cmd.exe, powershell.exe, or csc.exe. A SharePoint worker process launching a shell is almost never legitimate.
• T1505.003 (Web Shell): look for new or modified .aspx files under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\ and the farm's _app_bin/wpresources paths. ToolShell dropped a spinstall-style key-stealer here; treat any unexpected .aspx in these directories as an IOC.
• T1552 (Unsecured Credentials): the ToolShell lesson — attackers exfiltrate the ASP.NET ValidationKey/DecryptionKey (machineKey) from web.config, then forge signed __VIEWSTATE payloads that pass validation after you patch. Grep ULS logs and IIS logs for anomalous __VIEWSTATE POSTs and for outbound connections from the SharePoint service account.
• T1136 (Create Account): check for new farm admins, new site collection admins, and unexpected AD accounts created around the exploitation window.

5. Eradicate and verify

• Remove any web shells found; do not just delete the file — identify the initial-access request in IIS logs and reconstruct the full session.
• Rotate the ASP.NET machine keys across the farm (Set-SPMachineKey / farm-wide key rotation followed by PSConfig), then IIS reset. This is not optional: if keys were stolen, patching does not evict the attacker. This was the single most-missed step in the 2025 wave.
• Rotate the SharePoint farm service account and any credentials that account could reach.
• Re-run the build-version check to confirm the fixed build, then re-run your hunt queries to confirm the post-exploitation indicators are clean after patching — not before.

Where continuous validation would have caught this

Everything above assumes you know the box was exploitable. The failure in CVE-2026-45659 is that most organisations didn't, because their entire detection posture for "am I vulnerable?" is downstream of a CVE catalogue that, for five weeks, was wrong. A scanner that matches builds against CISA KEV is only as good as the feed — and the feed was empty here until exploitation had already started.

The question that survives a missing bulletin entry is not "is this CVE on my list?" but "if I run the attack, does the server fall?" That is what Zero Hunt's generative pentest engine is built to answer. Its 10-agent AI swarm — Recon, Exploit, Web, Credential, Post-Exploit, Pivot, and the rest, coordinated by an AI Controller — validates a target by attempting the chain, not by looking up a catalogue. For a quietly-patched flaw with no ExploitDB entry and no public PoC, that distinction is the whole game: the Exploit and Web agents write a per-target deserialization probe with a local LLM against the environment in front of them, so there is no dependency on a signature that doesn't exist yet. Every candidate skill is backtested in the AI Gym against corpora like Vulhub and NYU CTF Bench before it ever touches a production farm, and every finding is ECDSA-signed with chain-of-custody so "we validated SharePoint on July 3" is a verifiable record, not a claim.

Because the campaigns are change-triggered and scheduled, a SharePoint farm gets re-tested when it changes and on a fixed cadence — the assumed-breach Credential and Post-Exploit agents run the Site-Member-to-RCE path exactly the way a real intruder with a phished account would, and surface the exposure whether or not a bulletin ever named it. And when an attacker does get through, Zero Hunt's on-appliance AI Traffic Analysis — a deep-learning model with four inference heads running at 2.7+ Gbit/s on local GPU, no cloud — is watching the wire for the post-exploit signature: a SharePoint host that historically only served content suddenly spawning outbound beacons or staging an egress burst. Patched-in-May-exploited-in-July is exactly the window where seeing the activity as it happens beats reading about it in next morning's SIEM digest.

You can't remediate what your catalogue never listed. You can validate what's actually running. Talk to us if that gap is one you're carrying on an on-prem SharePoint farm right now.