If your organisation runs Microsoft SharePoint on its own servers rather than through Microsoft 365, there is a SharePoint server vulnerability you need to deal with this week. CISA added it to its Known Exploited Vulnerabilities catalogue on 1 July 2026, confirming attackers are already using it. Federal US agencies have been told to patch by 4 July. UK businesses have no such deadline, but the exploit does not care which country your server sits in.
Table of Contents
What the bug actually does
This SharePoint server vulnerability, tracked as CVE-2026-45659, carries a CVSS score of 8.8. It lives in how SharePoint handles deserialisation, the process of turning stored or transmitted data back into something the program can use. Feed it a specially crafted piece of data and, instead of reading it safely, SharePoint runs it as code.
The detail that should worry small IT teams most is the low bar for entry. An attacker does not need administrator credentials. A standard Site Member account, the kind handed out to ordinary staff, contractors or partners who need to view and edit documents, is enough to trigger it. Anyone who already has that level of access, or who steals or guesses a password belonging to someone who does, can potentially run code on your server.
It helps to understand why deserialisation bugs are so consistently dangerous. When SharePoint receives certain kinds of data, it converts that data back into working objects the software can act on. A deserialisation flaw means SharePoint does not check carefully enough what it is converting. A crafted piece of data can turn into a set of instructions rather than a harmless document reference. That is the mechanism behind this bug, and behind plenty of serious vulnerabilities disclosed in enterprise software over the past few years.
Does This SharePoint Server Vulnerability Affect You?
Only on-premises SharePoint is affected: SharePoint Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition. If your organisation moved fully to SharePoint Online inside Microsoft 365, this particular bug is not yours to fix, Microsoft patches that side directly. If you are not certain which one you run, that uncertainty is itself worth resolving, because it usually means nobody currently owns the decision. A basic vulnerability assessment of your SharePoint estate would settle that question quickly.
Microsoft shipped a fix for this bug back in May, as part of a routine update alongside a related, slightly less severe deserialisation flaw, CVE-2026-47294. At the time, Microsoft judged exploitation “less likely” and many teams will have deprioritised it behind more urgent tickets in their patch management queue. That assessment has now been overtaken by events.
Four things to do this week
Fixing this SharePoint server vulnerability does not require a specialist security team, just four concrete steps completed this week.
First, find your build number. Compare it against the fixed builds Microsoft published in May and confirm whether the update has actually been applied, not just scheduled. Change logs get missed more often than people admit.
Second, apply the patch if it is missing. Test it against a non-production copy if you have one, but do not let testing become an excuse to delay past this week; the exploitation is already happening.
Third, review who holds Site Member access or higher. Because the exploit needs only a low-privilege account, every stale contractor login, shared service account or forgotten guest invitation is a route in. Trim what you do not need.
Fourth, check whether the SharePoint server is exposed directly to the internet. Many organisations set this up years ago for remote staff to reach documents without a VPN, then never revisited it. If yours is one of them, put it behind a VPN or reverse proxy with proper authentication. An open front door with a new lock is still an open front door.
It is worth explaining to non-technical colleagues why “authenticated” does not mean “safe” here. Plenty of businesses treat internal accounts as low risk almost by default, on the assumption that anyone who has logged in is already trusted. This vulnerability shows why that assumption breaks down. A compromised contractor laptop, a reused password caught in an unrelated breach, or a disgruntled leaver whose account was never disabled are all realistic paths to a Site Member login. From there, it is a short step to full code execution on the server.
Why this deserves priority over routine patching
On-premises SharePoint has been hit before. In July 2025, a separate flaw known as ToolShell let attackers into SharePoint servers with no login at all. Microsoft confirmed the Storm-2603 group used that access to deploy Warlock ransomware within days. This SharePoint server vulnerability needs a login first, so it is not the same scale of emergency. But the underlying weakness, an internet-facing server that quietly falls behind on patches, is identical. Treat this one seriously enough that it does not become next year’s cautionary example.
Subscribe to our newsletter for a weekly round up of what's happening in the cyber security world
