On-prem SharePoint had a brutal July. Here's what a small business running it needs to do
Five critical vulnerabilities hit on-premises Microsoft SharePoint Server in July 2026, one of them a 9.8 unauthenticated RCE already being exploited. If you run SharePoint on your own servers, this is what to check. Updated August 20: CVE-2026-55040, the July authentication bypass, is now under active attack and was added to CISA's Known Exploited Vulnerabilities catalog on August 18 with a three-day federal deadline. The July update fixes it. Corrected August 22: that three-day deadline is no longer exceptional. It is now CISA's default under BOD 26-04.
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.
Correction and update, August 18, 2026. When we first published this we treated all three on-prem versions as equally patchable. They are not. SharePoint Server 2016 and SharePoint Server 2019 both reached end of support on July 14, 2026, per Microsoft’s lifecycle pages, and unlike Windows Server and SQL Server, SharePoint has no Extended Security Updates program. There is no paid extension to buy. If you are on 2016 or 2019, the “install the patch” advice below applies only up to the updates that shipped while they were still supported; for anything found from now on, there will not be a patch. Subscription Edition remains in support and is unaffected by this. We should have said so in the original post, because it changes the answer to step 6 from “worth asking” to “this is the only remaining fix.” The rest of this post, including the machine-key rotation step, still stands and is still worth doing today. See our rundown of the 2026 and 2027 Microsoft end-of-support dates for the wider list.
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:
- Confirm you’re patched. Check that the July 2026 cumulative update is installed, and that the August 11 update is too (see the update below, which is not optional). Don’t assume your IT provider already did this; ask them to confirm the specific KB and date.
- 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.
- 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.
- 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.
- 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.
- If you’re on 2016 or 2019, plan the move now. Both went out of support on July 14, 2026, and there is no ESU program to buy time with, so this is no longer an architectural preference. It is the only remaining remediation for whatever gets found next. The destinations are SharePoint Server Subscription Edition if it has to stay on your own hardware, or SharePoint Online. Worth checking first whether what you actually use it for is a document library and a few pages, in which case the migration is much smaller than the word suggests. On Subscription Edition, this step is the softer version it always was: this is the second SharePoint Server mass-exploitation event in about a year, Microsoft’s security investment goes overwhelmingly into the cloud product, and if nothing ties you to on-prem (a legacy integration, a data-residency requirement SharePoint Online genuinely can’t meet), migrating removes you from this entire class of problem.
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.
Update, August 2026: the August release did matter, and it completes the picture
We suggested watching Microsoft’s August 11 Patch Tuesday for follow-up fixes to this cluster. It delivered them, and one of them changes how you should read the July advisory.
Rapid7 and Microsoft disclosed CVE-2026-63520 on August 11, an unsafe .NET type instantiation in SharePoint’s Business Connectivity Services rated 8.1. On its own it needs some form of access to trigger, so in isolation it reads like a middling bug. It is not in isolation. Chained with CVE-2026-55040, the July authentication bypass described above, it produces unauthenticated remote code execution: forge a token to become a site user, then use that access to run an operating system command as the SharePoint service account. Neither half gets there alone.
Two things follow from that.
If you applied the July update, the chain is already broken for you. CVE-2026-55040 is the first and necessary link, so patching it is enough to stop this specific path. That is the reassuring half, and it is the argument for a patch cadence rather than a patch panic: the July update bought protection against an exploit chain that did not exist publicly until August.
Install the August update anyway. CVE-2026-63520 affects SharePoint Server Subscription Edition, 2019, and 2016, plus Project Server and Office Web Apps Server, and Microsoft shipped fixes as KB5002893, KB5002894, KB5002896, KB5002905, and KB5002906. Confirm with your IT provider which of those apply to the versions you actually run: Subscription Edition is the only on-prem SharePoint still in support, so if you are on 2016 or 2019, check what you are eligible to receive rather than assuming an August update is waiting for you. August also brought four more SharePoint issues Microsoft rated critical (CVE-2026-62827, CVE-2026-64921, CVE-2026-65665, and CVE-2026-70332). Rapid7 reported no in-the-wild exploitation of CVE-2026-63520 at disclosure, which is the good news and also the expiry date on the good news.
One detail worth sitting with: Rapid7 has said the chain was found and weaponized through an AI-assisted research workflow run by its own team, on the order of 120 hours of agent runtime across 24 days. Whatever you think of that as a research method, assume the people attacking on-prem SharePoint have access to the same method. The gap between “patch shipped” and “working exploit exists” is getting shorter, and the practical response is not to read more security news. It is to shorten your own gap between “patch shipped” and “patch installed.”
Update, August 20, 2026: the expiry date arrived, and it took one day
The sentence above about the expiry date on the good news did not need long to age.
Rapid7 published its technical analysis of CVE-2026-55040, the July authentication bypass, together with a proof-of-concept script on August 11. By August 12, threat intelligence firm Defused was reporting exploitation attempts against its SharePoint honeypots using that same public proof of concept. On August 18, CISA added CVE-2026-55040 to the Known Exploited Vulnerabilities catalog and set the remediation deadline for federal agencies at August 21, a three-day window.
Correction, August 22, 2026. We described that three-day window as “not how routine KEV entries are handled.” That was true until June and is not true now. We pulled CISA’s own KEV feed and counted: of the 57 entries added since BOD 26-04 took effect on June 10, 2026, 49 carry a three-day deadline, and none carry more than 14 days. In the first five months of 2026, three quarters of entries got 14 or 21 days. So a three-day deadline is no longer a signal that CISA considers this vulnerability exceptional; it is the new default for anything internet-facing, automatable, and already being exploited. The urgency of this particular SharePoint bug is unchanged, and everything else in this section still holds. We have written up what BOD 26-04 changed and how to use its four questions separately.
So the status of the July bug has changed twice in this post’s lifetime: from “patch it, it is serious” to “patch it, it is one half of a remote code execution chain” to “patch it, people are actively using it against real servers.” The vulnerability is rated 9.1 and works by chaining four separate weaknesses in SharePoint’s JSON Web Token validation to forge a token and act as any site user, up to and including an administrator. It affects SharePoint Server Subscription Edition, 2019, and 2016. SharePoint Online is not affected.
The remediation has not changed, which is the one piece of good news. Microsoft’s July cumulative update fixes CVE-2026-55040. If you installed it, you are not exposed to this. If you have been putting the July update off, the honest framing is no longer “you should get to this”; it is that a working exploit is public, it is being fired at internet-facing SharePoint servers, and your server is internet-facing or you would not be reading this.
The wider lesson is the interval. One day passed between a public proof of concept and observed attacks. Seven days passed between the proof of concept and a three-day federal deadline. A monthly patch cycle is no longer a fast patch cycle for anything internet-facing, and the machine-key rotation step above is what limits the damage if someone reached you first.
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.