On 1 July 2026, CISA added CVE-2026-45659 to its Known Exploited Vulnerabilities (KEV) catalogue and gave US federal agencies three days to patch. The awkward part: Microsoft fixed the flaw through its May SharePoint updates and assessed exploitation as “less likely”. Reality overruled that assessment in just over six weeks.Reality overruled that assessment in just over six weeks.
The flaw carries a CVSS score of 8.8 and can allow an authenticated user with low site-member privileges to execute code on the server. This is not a paper risk: CISA’s KEV listing confirms that exploitation is already happening, even if public sources have not yet identified the actor behind it or the final objective of the activity. The concern is amplified by the 2025 ToolShell precedent, where Storm-2603 exploited on-premises SharePoint to deploy Warlock ransomware. For any organisation still running internet-facing SharePoint on-premises, the clock is ticking.
What CVE-2026-45659 is, and why it matters now
CVE-2026-45659 is a deserialisation-of-untrusted-data vulnerability in SharePoint Server. Microsoft fixed it on 12 May 2026 in updates KB5002863, KB5002868 and KB5002870, and it affects SharePoint Server Subscription Edition, SharePoint Server 2019 and SharePoint Enterprise Server 2016.
Described at a conceptual level, the mechanism is the usual one for this class of bug: the application rebuilds objects from externally supplied data without validating its contents thoroughly enough, and processing that data ends with the server running logic the attacker controls. What makes it dangerous is not complexity but accessibility. Help Net Security notes the attack complexity is low and that a site-member account is enough — a level of access that is extremely common in internal deployments with thousands of users.
That nuance is easy to miss. Many teams dismissed the May advisory because it required authentication, reading that as a barrier. In SharePoint, where member access is handed out generously and stolen credentials circulate freely in dumps and forums, prior authentication is a minor obstacle for a well-resourced actor.
The ToolShell precedent: why on-premises SharePoint stays a target
To grasp the urgency, look back a year. In July 2025 the chain known as ToolShell (CVE-2025-49704, CVE-2025-49706 and the CVE-2025-53770 / 53771 bypasses) triggered a mass campaign against on-premises SharePoint. Microsoft documented active exploitation by three China-linked groups: Linen Typhoon, Violet Typhoon and Storm-2603 itself, the last of which focused on ransomware.
The reach was significant. Palo Alto Networks' Unit 42 tracked the campaign as it evolved, and public counts described dozens of compromised servers in the first waves, climbing further as proof-of-concept code appeared. Storm-2603 paired initial access with DLL search-order hijacking to deploy Warlock, according to The Hacker News' analysis of the group.
The lesson from 2025 recurs in 2026: on-premises SharePoint concentrates sensitive data, sits deep inside corporate identity, and — when exposed to the internet — offers a surface that ransomware operators understand well. CVE-2026-45659 does not open a new problem; it reactivates one that was never fully closed.
Why the patch alone is not enough
Applying the May update is essential but insufficient if the server may have been exposed before patching. ToolShell made it clear that these attackers steal cryptographic material from the server — ASP.NET machine keys — to keep persistent access even after the fix lands. A patched-but-previously-compromised server is still a compromised server.
This is why the right response is not simply “patch and forget”. As we set out in our guide to prioritising exploitable vulnerabilities with KEV, EPSS and SSVC, a CVE landing in CISA's KEV catalogue is the clearest signal that exploitation is already under way and that the reaction window is measured in days, not weeks.
Detection: what to look for in telemetry
Without describing how the attack is built, it helps to know the trace it leaves so threat hunting can be directed. Indicators observed during the ToolShell campaign, including activity later associated with Storm-2603, give a useful starting point:
- Anomalous child processes of w3wp.exe (the IIS worker that serves SharePoint) spawning command interpreters or system utilities. A web server suddenly invoking cmd.exe or PowerShell is a strong signal.
- Writing of .aspx files into LAYOUTS directories or web-served SharePoint paths. Earlier campaigns used web shells named like spinstall0.aspx; the name changes, the pattern of a new, illegitimate .aspx does not.
- Access to or exfiltration of ASP.NET machine keys, and their reuse to forge valid tokens.
- DLL search-order hijacking: legitimate binaries loading expected DLL names from unusual paths — the technique Storm-2603 used to deploy the encryptor.
- Unusual requests to SharePoint endpoints, especially when correlated with unexpected worker-process behaviour, CPU spikes or new files appearing in web-served directories.
These signals feed detection rules in the EDR and the SIEM. A team running a managed SOC with continuous threat hunting can turn these indicators into standing queries rather than waiting for a generic alert to fire.
Practical defence
Beyond the patch, an exposed on-premises SharePoint server calls for a set of concrete controls:
- Apply the May 2026 updates (KB5002863/68/70) across all affected editions, without exception, prioritising internet-facing servers.
- Rotate ASP.NET machine keys after patching, assuming the cryptographic material may have been exposed. It is the step most teams skip and the one that neutralises persistence.
- Remove on-premises SharePoint from direct internet exposure wherever feasible, placing it behind a gateway with strong authentication or a VPN.
- Enable and verify AMSI (Antimalware Scan Interface) in full mode for SharePoint, which blocked part of the exploitation in the 2025 campaign when correctly configured.
- Review and reduce site-member permission grants: the fewer authenticated accounts that can interact with vulnerable components, the smaller the surface.
- Hunt retrospectively for signs of compromise predating the patch, not just watch going forward.
If the retrospective review finds a trace of intrusion, the scenario stops being vulnerability management and becomes incident response. The difference is substantial: a compromised server with persistent access and a possible ransomware deployment needs containment, forensics and eradication, not a patch ticket.
Compliance implications
For organisations under NIS2, a vulnerability actively exploited in a system that underpins business processes falls squarely within risk-management and incident-notification obligations. A SharePoint compromise with a ransomware deployment is, almost by definition, a significant incident with strict reporting deadlines.
Traceability matters as much as remediation. Documenting when the patch was applied, when keys were rotated and what evidence rules out a prior compromise is what turns a technical response into one you can defend to a regulator. Our NIS2 compliance team and our MSSP service work precisely at that junction of operations and evidence.
At a glance
CVE-2026-45659 is striking not for its complexity but for its context: on-premises SharePoint, low-threshold authentication, recent ransomware precedent against the same platform, and a known-exploited catalogue that confirms the urgency.Microsoft judged it unlikely; reality disproved that in weeks. The operational takeaway is simple and uncomfortable — patch now, rotate keys, hunt backwards, and treat an exposed SharePoint server as a target, not a possibility.