SharePoint RCE (CVE-2026-45659): what self-hosters must do now

The SharePoint bug ransomware crews are exploiting right now — and what it means if you host your own

Microsoft SharePoint Server has a critical remote-code-execution flaw, CVE-2026-45659, that ransomware crews are actively exploiting, and CISA ordered federal agencies to patch it by July 4, 2026. If you run SharePoint on your own servers, patch to the May 2026 update now and check whether it should be reachable from the internet at all.

By Paul Rudenko, Security ResearcherJul 6, 20266 min read

Update — July 16, 2026: SharePoint has since had more actively-exploited bugs and a CISA hardening alert. See the follow-up: SharePoint’s third active exploit in ten days.

What happened with the SharePoint vulnerability?

CVE-2026-45659 is a remote-code-execution bug in on-premises Microsoft SharePoint Server, rated CVSS 8.8. It comes from deserialization of untrusted data — where a server rebuilds an object from data it was sent without checking it first, letting an attacker smuggle in code the server then runs.

An attacker needs to be authenticated, with as little as “Site Member” permissions, to trigger it. That sounds like a high bar, but on a SharePoint box that’s open to the internet, low-privilege access is often the easy part.

On July 1, 2026, CISA added it to the Known Exploited Vulnerabilities catalog and, under Binding Operational Directive 26-04, set a federal patch deadline of July 4 (CISA alert). A KEV listing means one thing: this is not theoretical — it’s being used in real attacks.

Why is a May patch suddenly a July emergency?

Here’s the part most coverage skips. Microsoft actually fixed this in its May 2026 update and, at the time, rated exploitation as “less likely” (The Hacker News).

That rating aged badly. Attackers reverse-engineered the patch, and by July the flaw was being exploited in the wild — which is what pushed it onto the KEV list.

So the “emergency” isn’t a new bug. It’s a two-month-old fix that a lot of self-hosted servers never installed, now being weaponized. The lesson underneath it: a vendor’s “less likely to be exploited” label is a guess, not a guarantee, and it’s a weak basis for deciding what to patch first.

For the site owner (plain English)

If your company uses SharePoint through Microsoft 365 / SharePoint Online, Microsoft runs the servers and this is handled for you — you don’t need to do anything.

This matters if you run SharePoint on your own servers (SharePoint Server 2016, 2019, or Subscription Edition), often set up years ago by an IT contractor and quietly left running. Those are the targets. What to do, in order:

Apply the May 2026 (or later) SharePoint update — or have whoever manages it confirm it’s done.
Ask a blunt question: does this need to be reachable from the internet at all? A lot of self-hosted SharePoint is exposed with no business reason. If it can be internal-only or behind a VPN, that removes most of the risk on its own.
Because it’s already being exploited, patching isn’t the end — assume anything that was exposed and unpatched may have been touched, and have someone check (see the FAQ).

That second point is the real takeaway, and it’s not a SharePoint problem — it’s an attack-surface problem. You can’t defend, or even decide to retire, a system you’ve forgotten is facing the internet. Knowing exactly what of yours is exposed is the whole game. That’s what an external attack-surface scan is for: it looks at your domain from the outside, the way an attacker does, and shows you what’s reachable. It won’t tell you “you have CVE-2026-45659” — no honest external scan can — but it will tell you which of your systems are needlessly hanging out in the open.

How do developers and IT fix it?

Patch to the May 2026 security update for your edition (SharePoint Server Subscription Edition, 2019, or Enterprise Server 2016). Confirm the build number post-install.
Hunt for compromise. Reporting ties active exploitation to Storm-2603 deploying Warlock ransomware. Observed post-exploitation includes creation of new local and domain admin accounts, and persistence via Velociraptor, Cloudflare tunnels, Zoho Assist, and VS Code SSH sessions. Audit for unexpected admin accounts and those tools.
Reduce the surface. Put SharePoint behind a VPN or IP allow-list; don’t publish it to the open internet unless there’s a hard requirement.
References: the CISA KEV entry and Microsoft’s advisory for CVE-2026-45659.

What’s the real lesson here?

This is the same story we keep seeing: an internet-exposed enterprise app, a deserialization bug, a patch that shipped but never got installed, and a ransomware crew that industrialized the gap. SharePoint is just this month’s example — last quarter it was a file-transfer appliance, before that a VPN gateway.

The common thread is never the specific CVE. It’s the forgotten thing facing the internet. Patch cadence matters, but knowing your external footprint — and shrinking it — is what actually breaks the pattern.

Frequently asked questions

Do I need to worry about this if I use Microsoft 365?

No. CVE-2026-45659 affects on-premises SharePoint Server — the versions a company installs and runs on its own infrastructure (SharePoint Server 2016, 2019, and Subscription Edition). If your team uses SharePoint through Microsoft 365 or SharePoint Online, Microsoft operates and patches those servers, so this particular flaw is already handled on their side. The quickest way to tell which you have: if you sign in at a microsoft.com or office.com address and never think about "updating SharePoint," you're on the cloud version. If your IT team maintains a SharePoint server, applies its updates, and it has its own web address that you host and manage yourselves, then that's the on-premises product this advisory is about — and it's the one you need to check and patch today.

How do I know if my SharePoint server is exposed to the internet?

Start by asking whoever set it up two things: is there a SharePoint server we run ourselves, and can it be reached from outside our office network? Many self-hosted SharePoint installs are published to the public internet so staff can log in remotely, and that public exposure is exactly what turns an authenticated bug into a real risk. If nobody's certain, that uncertainty is the finding. An external attack-surface scan answers it from the outside: it looks at your domain the way an attacker would and lists what's reachable — login portals, admin panels, services that were never meant to be public. It won't confirm a specific CVE, but it shows you what's exposed so you can decide what to lock down, put behind a VPN, or retire entirely.

I've patched. Am I done, or could I already be compromised?

Patching stops future exploitation, but it doesn't undo an intrusion that already happened — and because this flaw has been exploited in the wild, that matters. If your server was exposed and unpatched for any stretch since May, treat it as possibly touched and have someone investigate. Concrete things to check: unexpected new local or domain administrator accounts, and remote-access or "living off the land" tooling that shouldn't be there — reporting on the Storm-2603 activity cites Velociraptor, Cloudflare tunnels, Zoho Assist, and VS Code SSH sessions used for persistence. If you find any of those and can't explain them, get incident-response help before assuming the patch closed the door. Cleaning up after ransomware operators is very different from installing an update.

What are Storm-2603 and Warlock ransomware?

"Storm-2603" is Microsoft's tracking name for a threat group that has been breaking into on-premises SharePoint servers since mid-2025 and deploying Warlock ransomware — malware that encrypts an organization's files and demands payment. Groups like this specialize in a repeatable playbook: find a known, unpatched vulnerability in an internet-facing enterprise app, use it to get in, quietly create admin accounts and remote-access channels so they keep control, then deploy ransomware once they're established. You don't need to track the group's name to protect yourself. The defenses are the same regardless of who's behind the campaign: install the patch, minimize what's exposed to the internet, and monitor for the unexpected accounts and tools that signal someone has already made themselves at home.