SURIQ
Seven weeks ago Microsoft shipped a fix for a remote code execution flaw in on-premises SharePoint Server and stamped it with the label defenders like to hear: unlikely to be exploited. On July 1, CISA put CVE-2026-45659 on its Known Exploited Vulnerabilities catalog after confirming attacks in the wild, and gave federal agencies three days to patch. The vendor forecast and the ground truth just parted ways.
That gap is the whole story. If you run SharePoint on your own hardware and you triaged the May update by Microsoft's exploitability rating, this bug is a live example of why that rating is a starting point, not a verdict. Here is what it is, why the "less likely" tag misled, and how you would know if you were already hit.
What CVE-2026-45659 actually is
CVE-2026-45659 is a deserialization of untrusted data flaw in Microsoft SharePoint Server. It carries a CVSS score of 8.8. A deserialization bug means the server rebuilds a .NET object from data an attacker controls, and in the wrong spot that reconstruction runs attacker code. Microsoft patched it on May 12, 2026, crediting a researcher who goes by MEOW. The fix covers three on-premises editions: Subscription Edition, Server 2019, and Enterprise Server 2016.
Two facts scope the risk. First, this is on-premises SharePoint Server only. SharePoint in Microsoft 365 is not in the affected list, so the exposure sits entirely with organizations that host the product themselves. Second, it is post-authentication: the attacker needs a foothold at Site Member level, the low end of SharePoint permissions, not an administrator account. Microsoft used that requirement, plus its own analysis, to tag the flaw "Exploitation Less Likely."
The dates above are the argument. Patched May 12, added to CISA's catalog July 1 on confirmed exploitation, federal deadline July 4. The three-day window CISA set is on the short end of what it issues, which is a signal in itself: the agency does not compress the clock like that for a flaw it thinks defenders can sit on.
Why "Exploitation Less Likely" was the wrong thing to trust
Microsoft's exploitability index is a prediction made at patch time. It is a useful prioritization aid across a busy Patch Tuesday, but it is a forecast, and forecasts on SharePoint have a poor record. This is the same on-premises product that attackers mass-exploited in mid-2025 through the ToolShell chain, and the one CISA already flagged this year when it added CVE-2026-32201, a lower-scored SharePoint flaw, to KEV back in April after real-world attacks. A defender who deferred the May patch because the score was 8.8 rather than 9-plus, or because the label said "less likely," bet against a product that keeps proving the optimistic read wrong.
The takeaway is not that Microsoft's ratings are useless. It is that they are the wrong input for a self-hosted SharePoint patch decision specifically. For this product, the exploitation history is the better predictor than the pre-release forecast, and the history says treat every SharePoint RCE as presumed reachable. KEV listings are the confirmation, and by the time one arrives the window you had to patch quietly is gone. That is the same lesson as the countdown that turns a patch into an emergency when exploitation catches up.
On SharePoint, "needs a login" is not the wall it looks like
The instinct with a post-authentication bug is to relax: an attacker needs valid access first, so the internet at large cannot reach it. On most products that reasoning holds. On SharePoint it has failed publicly and recently.
The 2025 ToolShell activity was not a single vulnerability. It was an authentication bypass chained to a deserialization RCE, so the "you need to be logged in" half of the exploit was supplied by the other half. SharePoint has furnished those bypass primitives more than once, which means a Site Member requirement is one auth-bypass away from unauthenticated code execution. Treating the low-privilege requirement on CVE-2026-45659 as a comfort assumes attackers will play by the single-bug rules, and on this product they have not. A deserialization RCE that needs only a low-privilege session is the exact back half of the chain the last SharePoint campaign already built. This is the deserialization weakness that keeps resurfacing across the stack, and gating it behind a weak login is thin insurance.
How you would know you were hit
Microsoft has not published how the flaw is being exploited, and there is no vendor IOC list yet. That is a reason to hunt by behavior, not to wait. Deserialization RCE against SharePoint produces the same tells regardless of the specific payload, and the 2025 SharePoint incident response work already wrote the playbook.
Watch the IIS worker process, w3wp.exe, for child processes it should never spawn: cmd.exe, powershell.exe, or anything launching under the SharePoint web application pool identity. Look for new or modified .aspx files in the SharePoint layouts directories under TEMPLATE\LAYOUTS, the classic webshell drop point in the ToolShell attacks. In that campaign attackers also stole the server's ASP.NET MachineKey material to forge trusted payloads, so any suspected compromise means rotating those keys, not just applying the patch. And because this bug rides an authenticated session, unusual POST activity from a low-privilege account into SharePoint application endpoints is worth a second look. None of this requires knowing the exploit; it requires watching the process tree and the file system where SharePoint RCE always lands. The same patch-the-box-then-hunt-the-breach discipline applies: the update closes the door, it does not tell you whether someone already walked through.
Patch to the May build, then hunt like it is ToolShell
The first action is simple: apply the May 12, 2026 security update for your SharePoint edition if you have not. That closes CVE-2026-45659 on Subscription Edition, 2019, and 2016. Do it ahead of the July 4 federal deadline even if you are not a federal agency, because that deadline is CISA's read on how fast this is moving.
The second action is the one the label almost talked you out of: assume the seven-week window was enough for someone to reach an unpatched box, and hunt it. Pull the process ancestry for w3wp.exe, inventory recently written files under the SharePoint layouts paths, and check authenticated request logs for low-privilege accounts touching endpoints they have no business touching. If you find anything, rotate the MachineKey and treat the server as a full compromise, the way the webshell-on-a-self-hosted-app cases have taught. On-premises SharePoint is not a quiet corner of your estate. It is one of the most reliably attacked servers you run, and the vendor's optimism about any single flaw is the one input to leave out of the decision.