Four separate SharePoint Server vulnerabilities are being exploited against on-premises deployments right now, and the July update that closes them does not remove the attacker who got in first. CISA published an alert on July 14, 2026, urging every organization running SharePoint on-prem to harden and hunt, naming CVE-2026-32201, CVE-2026-45659, CVE-2026-56164, and CVE-2026-58644 as flaws under active exploitation. Two days later, on July 16, CISA added CVE-2026-58644 - a CVSS 9.8 unauthenticated remote code execution bug - to the Known Exploited Vulnerabilities catalog with a three-day federal remediation deadline.
The reason this cluster matters more than a normal Patch Tuesday line item is the post-exploitation behavior CISA describes: attackers are stealing the server's ASP.NET machine keys. Once they have those keys, a fully patched SharePoint box is still forgeable. This is the same failure pattern that turned the 2025 SharePoint incidents into months of cleanup, and it is playing out again with a fresh set of CVE numbers.
Who is exposed, and who is not
This is an on-premises problem. If your organization runs SharePoint entirely through SharePoint Online in Microsoft 365, none of these four CVEs apply to you - Microsoft patches the service side, and you can close this tab. The people who need to act today are the ones running SharePoint Server Subscription Edition, SharePoint Server 2019, or SharePoint Enterprise Server 2016 on their own hardware or in their own cloud tenant, and especially anyone whose SharePoint front end is reachable from the internet.
That population is larger than the "everyone moved to the cloud" narrative suggests. Manufacturers, law firms, healthcare groups, government contractors, and mid-market companies that adopted SharePoint a decade ago for document management routinely still run it on-prem, often behind a reverse proxy that does nothing to stop an unauthenticated request from reaching the vulnerable endpoint. If you have a SharePoint farm and you are not certain it took the July 2026 updates, treat it as exposed until you prove otherwise.
Exposure comes down to two questions. First, is the farm reachable from the internet - directly, through a load balancer, or through a published reverse proxy that forwards /_layouts/ requests straight to the front end? An external check for the SharePoint sign-in and layouts paths from an off-network host answers that faster than reading firewall rules. Second, does anything sit in front of it that would blunt an unauthenticated request - a VPN requirement, an identity-aware proxy, a web application firewall with current rules? Two similarly patched farms can carry very different risk based purely on whether an anonymous request from the open internet can reach the vulnerable endpoint at all. Internet-facing and unauthenticated-reachable is the profile being hit; that is the one to fix first.
The four flaws, and how they fit together
These are not four independent bugs you patch in any order. They form the two halves attackers actually need: a way in without credentials, and a way to run code once inside.
The chain, in the order that matters
CVE-2026-56164- Missing authentication for a critical function. An unauthenticated attacker reaches a function that should require a login and elevates privileges over the network. Microsoft rates it moderate (CVSS 5.3); the National Vulnerability Database scored it 9.8. Added to KEV on July 14 with a July 17 deadline. This is the front door.CVE-2026-58644- Deserialization of untrusted data, CVSS 9.8. An unauthenticated attacker sends a crafted serialized payload that SharePoint rebuilds without validating, and the object executes code. Added to KEV on July 16, due July 19. This is code execution.CVE-2026-45659- An earlier deserialization RCE requiring authentication, added to KEV on July 1. It is the reason the access-bypass bugs are dangerous: an attacker who bypasses authentication and then feeds a deserialization payload gets the full pre-auth-to-RCE result.CVE-2026-32201- The oldest of the set, on the KEV catalog since April. Its continued presence in CISA's July alert is a signal that unpatched farms from the spring are still being found and hit.
Microsoft has confirmed exploitation in the wild for the two July zero-days, and Rapid7 reported live attacks against CVE-2026-58644 within days of disclosure. The July 2026 Patch Tuesday that shipped the fixes was itself a record - 622 CVEs - which is precisely the kind of volume that lets a 9.8 slip past an overloaded patch cycle.
Why patching is the start, not the finish
Here is the part most coverage skips. When an attacker reaches code execution on SharePoint, the high-value loot is not your documents. It is the machineKey from the server's ASP.NET configuration - the validationKey and decryptionKey that SharePoint uses to sign and encrypt __VIEWSTATE. With those two values, an attacker can craft a valid, signed ViewState payload from anywhere and have the server deserialize it into code execution, on demand, with no vulnerability required. The bug got them in once; the stolen keys let them back in forever.
The mechanics are worth understanding because they dictate the fix. SharePoint uses the machine key to sign the __VIEWSTATE field that rides along with every page post-back, so the server trusts a ViewState blob only if the signature matches. Steal the key and an attacker can sign their own ViewState containing a serialized object, POST it to any endpoint that processes ViewState, and the server deserializes it into code execution - no login, no exploit, just a validly signed request. The signature that was supposed to be a trust boundary becomes the attacker's authorization.
This is why CISA's alert leads with machine-key theft rather than just "apply the update." Installing the July patch closes the hole an attacker used to arrive. It does nothing to the keys they may have already copied. A farm that was internet-facing and unpatched at any point this month should be treated as an assume-breach situation: patch it, then rotate every machine key across every server in the farm, then look for what was left behind. Rotation has to be farm-wide because a single server still holding the old key keeps the forged-ViewState path alive. Skip the rotation and you have welded the front gate shut while the attacker still holds a working copy of the key.
Patch, rotate, and hunt: the response
Run these three moves in order. The sequence matters - rotating keys before the patch is installed just hands the attacker the new keys through the same open hole.
1. Confirm the update is actually on every server
Check the build number on every server in the farm, not just the one you remember patching. A single un-updated web front end keeps the whole farm exploitable. Consult the MSRC advisory for CVE-2026-58644 and the advisory for CVE-2026-56164 for the exact security-update builds per version.
2. Rotate the ASP.NET machine keys, then restart IIS
After the update is confirmed, rotate the keys from the SharePoint Management Shell and recycle the web application so the new keys take effect. This is the step that evicts a key-theft foothold:
# SharePoint Management Shell, run as farm admin, AFTER the July update is installed
# Rotate the machine key for every web application in the farm
Get-SPWebApplication | ForEach-Object {
Set-SPMachineKey -WebApplication $_
Update-SPMachineKey -WebApplication $_
}
# Push the change and recycle so the old, possibly-stolen keys stop working
iisreset /noforce3. Hunt for the webshell and the child process
Exploitation of this class drops a small .aspx file into the SharePoint web directories and runs commands as the IIS worker process. Two hunts catch most of it: recently written .aspx files under the SharePoint layouts path, and w3wp.exe spawning a shell. Run this on each web front end:
# 1) New/modified .aspx dropped into the SharePoint web root in the last 14 days
$roots = @(
"$env:CommonProgramFiles\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS",
"C:\inetpub\wwwroot\wss\VirtualDirectories"
)
Get-ChildItem -Path $roots -Recurse -Include *.aspx,*.ashx -ErrorAction SilentlyContinue |
Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-14) } |
Select-Object FullName, LastWriteTime, Length | Sort-Object LastWriteTime -Descending
# 2) IIS worker process spawning a command interpreter (classic webshell tell)
Get-CimInstance Win32_Process -Filter "Name='cmd.exe' OR Name='powershell.exe'" |
Where-Object { (Get-CimInstance Win32_Process -Filter "ProcessId=$($_.ParentProcessId)").Name -eq 'w3wp.exe' } |
Select-Object ProcessId, CommandLineIf Microsoft Defender is deployed, it now ships AMSI-backed detections for this activity - Exploit:Script/SuspSignoutReqBody.A and Exploit:Script/ToolPaneAuthBypass.A among them. Confirm AMSI integration is enabled for SharePoint (it is off by default on older farm builds) so those signatures actually fire on request bodies, not just files at rest. Cross-check your findings against the current CISA KEV catalog and the agency's July 14 SharePoint hardening alert, and read Rapid7's analysis of CVE-2026-58644 for the exploitation timeline.
Rotate the machine keys before you call this patched
Order your week around one fact: for on-prem SharePoint, the patch and the key rotation are two different jobs, and only doing the first leaves a signed skeleton key in the attacker's pocket. Inventory every farm, apply the July 2026 updates on every server, rotate the machine keys, restart IIS, and then run the two hunts above before you sign off. If either hunt returns something you cannot explain, you are past patching and into incident response - preserve the box, pull the IIS logs, and work it as a live intrusion rather than a maintenance ticket.
Need an incident response plan before the next attack?
If a SharePoint box has been internet-facing and unpatched this month, patching it does not answer whether someone is already inside. We help organizations hunt for post-exploitation persistence and build incident response playbooks they can actually run. Book a session with our team.