On-prem SharePoint had a brutal July. Here's what a small business running it needs to do

If your business runs Microsoft SharePoint Server on its own hardware, rather than the SharePoint Online piece of Microsoft 365, July 2026 was a bad month. CISA published an alert on July 14 urging organizations to harden their SharePoint deployments after finding active exploitation of a cluster of new vulnerabilities. One of them, CVE-2026-58644, is a 9.8-out-of-10 severity unauthenticated remote code execution bug, and it was already being used against real targets before the patch shipped.

This only affects on-premises SharePoint Server (Subscription Edition, 2019, and 2016). If you’re on SharePoint Online through Microsoft 365, this particular problem isn’t yours. If you or a vendor is running SharePoint on servers you own or rent, keep reading.

What actually happened

Microsoft’s July Patch Tuesday addressed a set of related flaws in on-prem SharePoint. The two that matter most:

• CVE-2026-58644 (CVSS 9.8): a deserialization bug that lets an attacker run arbitrary code on the server without logging in first. CISA added it to the Known Exploited Vulnerabilities catalog on July 16, confirming it was already being used in the wild.
• CVE-2026-55040 (CVSS 9.1): an authentication bypass that lets an attacker impersonate a SharePoint user, including an administrator, by forging a token. Researchers showed it can be chained with other bugs to reach full remote code execution without any valid credentials at all.

Alongside those, CISA flagged CVE-2026-56164 (an unauthenticated privilege-escalation bug), CVE-2026-45659 (CVSS 8.8, another deserialization RCE), and two more, CVE-2026-50522 and CVE-2026-32201, in the same family of issues.

Once an attacker is in, the pattern researchers observed is consistent: steal the server’s IIS machine keys, use those keys to forge trusted requests and keep coming back even after the box is patched, and drop a web shell for persistence. That machine-key theft is the part that makes this worse than a normal “patch and move on” bug. If your keys were stolen before you patched, patching alone doesn’t evict the attacker. The keys still work.

The good news, such as it is: VulnCheck, one of the firms tracking exploitation, describes the current activity as targeted rather than a mass, spray-everything campaign. That’s a meaningful difference from 2025’s “ToolShell” SharePoint campaign, which did hit broadly. It’s not a reason to relax, since targeted often means someone picked your organization on purpose, but it does mean this isn’t (yet) the kind of automated internet-wide sweep that catches every unpatched box within hours.

What to actually do

If you’re running on-prem SharePoint, in order:

1. Confirm you’re patched. Check that the July 2026 cumulative update is installed, and watch for Microsoft’s August 11 release in case it includes follow-up fixes for this cluster. Don’t assume your IT provider already did this; ask them to confirm the specific KB and date.
2. Rotate your IIS machine keys after patching, not just before. Because keys can be stolen prior to the patch, rotating them after applying the update is the step that actually locks a prior intruder out. Do this even if you have no evidence of compromise.
3. Look for the specific signs of compromise. Unexpected files in SharePoint’s LAYOUTS or web application folders, admin accounts that weren’t created by your team, and outbound traffic from the SharePoint server that has no reason to exist. If you don’t have logging that could catch this, that’s itself worth fixing.
4. Turn on AMSI (Antimalware Scan Interface) integration for every SharePoint web application, and enable request-body scanning if your security stack supports it. This is one of the mitigations CISA specifically called out, and it catches exploitation attempts even against not-yet-known variants of the bug.
5. Get SharePoint off the open internet if it doesn’t need to be there. Central Administration in particular should never be reachable from outside your network. If remote access is required, put it behind a VPN.
6. Ask, honestly, whether you still need on-prem SharePoint. This is the second SharePoint Server mass-exploitation event in about a year. Microsoft’s own security investment goes overwhelmingly into the cloud product. If nothing is tying you to the on-prem version (a legacy integration, a data-residency requirement that SharePoint Online genuinely can’t meet), migrating removes you from this entire class of problem going forward.

Why this keeps happening to SharePoint specifically

On-prem SharePoint has been a recurring target for a few structural reasons: it’s usually internet-facing (people need to reach it from outside the office), it runs as a privileged IIS application with broad filesystem access, and it accepts a lot of untrusted, complex input (documents, workflows, web parts) that gets deserialized somewhere in the stack. Deserialization bugs are exactly what you’d expect from that combination, and this is not the first time SharePoint has produced one. It won’t be the last.

None of that is a knock on the businesses running it. On-prem SharePoint was a reasonable choice for a long time, and for some organizations with real data-residency constraints it still is. But “reasonable choice a decade ago” and “still the right architecture in 2026” are different questions, and this July is a good prompt to ask the second one honestly.

If you’re not sure whether your SharePoint deployment is patched, whether it should be internet-facing at all, or whether it’s time to move off it entirely, send us a note and we’ll help you work through it.