On-Prem SharePoint Is Under Active Attack — And Patching Alone Will Not Remediate It (2026)

On July 14, 2026, CISA published a hardening alert confirming active exploitation of four vulnerabilities in on-premises Microsoft SharePoint Server. Those are CVE-2026-32201, CVE-2026-45659, CVE-2026-56164, and CVE-2026-58644. All four affect supported on-premises builds: SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016.

The short version of each, per CISA and Tenable's analysis:

• CVE-2026-32201 - a spoofing flaw rooted in improper input validation (CVSS 6.5), exploitable by an unauthenticated remote attacker with no user interaction. Added to the KEV catalog on April 14, 2026.
• CVE-2026-45659 - remote code execution via deserialization of untrusted data (CVSS 8.8). Patched by Microsoft in an out-of-band update in late May 2026, added to KEV July 1, 2026.
• CVE-2026-56164 - elevation of privilege exploitable remotely by an unauthenticated attacker, added to KEV July 14, 2026. Note the severity disagreement: NVD scores this 9.8 while Microsoft's own advisory scores it 5.3. Treat it as the higher number until that gap is resolved.
• CVE-2026-58644 - an unauthenticated deserialization-of-untrusted-data RCE (CVSS 9.8), disclosed July 14, 2026 and added to KEV July 16, 2026 after confirmed in-the-wild use.

On attribution, be precise about who is saying what. As of mid-July 2026, neither CISA nor Microsoft had issued an official attribution for the cluster as a whole. Early security reporting, however, links exploitation of CVE-2026-45659 to Storm-2603 (also tracked as GOLD SALEM), the group that deploys Warlock ransomware on compromised on-premises SharePoint servers and that used the 2025 ToolShell chain for the same purpose. Read that as at least one organized ransomware crew already operating in this space, with others likely following.

CVE-2026-45659 deserialization RCE only needs Site Member permissions

This is the detail that changes your risk math. The CVE-2026-45659 deserialization RCE is technically "authenticated," which sounds reassuring until you read the privilege requirement. Microsoft's advisory puts it at PR:L - an attacker with a minimum of Site Member permissions can trigger it. No admin rights. No farm account.

Think about who has Site Member on your legacy document library. Every employee. Probably several former employees whose accounts were never disabled. Possibly a vendor, a contract engineer, or a shared "docs" login that has been passed around since a 2019 project. Combine that with CVE-2026-32201, CVE-2026-56164, and CVE-2026-58644, which need no authentication at all, and the "authenticated" qualifier stops being a control.

Here is the mechanic that makes this campaign different from an ordinary RCE. Once attackers get code execution on a SharePoint front end, the documented post-exploitation step is to steal the server's IIS machine keys - the ASP.NET validation and decryption keys that SharePoint uses to sign and encrypt ViewState and other serialized payloads.

With those keys in hand, an attacker no longer needs the vulnerability. They can forge a validly signed serialized object and send it to your server as a normal, well-formed web request. The server verifies the signature, deserializes the payload, and executes it. You patched the bug. The key you never rotated is now the backdoor. This is the same pattern security teams learned the hard way during the 2025 ToolShell campaign (CVE-2025-53770 and CVE-2025-53771), where attackers extracted the ValidationKey and DecryptionKey to forge __VIEWSTATE payloads that survived patching. The industry is repeating the mistake.

SharePoint IIS machine key rotation is the step everyone skips

SharePoint IIS machine key rotation is not optional cleanup. It is the step that actually closes the door. In SharePoint you rotate with the Set-SPMachineKey cmdlet per web application, use Update-SPMachineKey to deploy the keys to the other servers in the farm, or trigger the Machine Key Rotation timer job from Central Administration (Monitoring, then Review job definitions) - then restart IIS farm-wide with iisreset.exe so the worker processes pick up the new keys.

Worth knowing: automatic machine key rotation is available starting with SharePoint Server Subscription Edition version 25H1 and the September 2025 public update for SharePoint Server 2016 and 2019. If you are on those builds, confirm whether it is actually enabled rather than assuming it.

One ordering caveat that CISA calls out explicitly, and that DIY cleanups get backwards: hunt for and remediate intrusion artifacts, including machine-key harvesters, before rotating keys. If an attacker still has an active foothold when you rotate, they simply harvest the new key and you have accomplished nothing but a maintenance window.

• 1. Contain first. Get the server off the public internet today. CISA recommends avoiding direct internet exposure unless necessary, blocking external access to SharePoint Central Administration, restricting farm and database communication to required systems, and placing any necessarily exposed server behind a Layer 7 reverse proxy or similar application-layer control. Better still: put it behind identity-aware access so only authenticated, device-verified sessions reach it. Our take on that model is here: zero trust network access.
• 2. Patch and verify. You likely need more than one update: CVE-2026-45659 was fixed in the late-May 2026 out-of-band release, while CVE-2026-56164 and CVE-2026-58644 were fixed in the July 14, 2026 Patch Tuesday. Apply the correct updates for your exact build, then confirm the build number actually changed. Verification failures are common on multi-server farms, and CISA specifically calls out verifying successful installation.
• 3. Enable AMSI and antivirus. Turn on Windows Antimalware Scan Interface integration for SharePoint web applications - Microsoft's Full Mode scans request bodies, not just query strings - and run Microsoft Defender Antivirus (or an enterprise equivalent) on every farm node.
• 4. Hunt and remove artifacts. See the next section.
• 5. Rotate machine keys, then iisreset. Per web application, replicated across the farm.
• 6. Reset service account credentials. Farm account, application pool identities, search service, and any SQL account reachable from the SharePoint tier. If the box was owned, those secrets were in memory. This one is standard incident-response practice rather than a specific CISA instruction, but skip it at your peril.
• 7. Re-hunt to validate. Confirm no persistence survived the rotation. This is the step that proves eviction rather than assuming it.

SharePoint webshell persistence hunting: what to look for

SharePoint webshell persistence hunting means going beyond antivirus alerts. Concretely, look for unexpected .aspx or .ashx files in the LAYOUTS directory and other IIS-served paths with recent write times; IIS worker processes (w3wp.exe) spawning cmd.exe or powershell.exe; new or altered scheduled tasks running under SharePoint service identities; application pool identities that were changed or added; new local accounts and group memberships; and outbound connections from the SharePoint tier to hosts nobody can explain. CISA also advises establishing tailored logging to detect exploitation activity and reviewing telemetry for anomalous requests, suspicious worker-process activity, webshells, and machine-key access. Then check whether your logging retention even goes back far enough to answer the question. For most small and mid-size firms it does not, which is exactly the gap managed detection and response is built to close with continuous automated monitoring.

Federal civilian agencies operate under Binding Operational Directive deadlines when a CVE lands in the Known Exploited Vulnerabilities catalog, and those deadlines got shorter this year. BOD 26-04, "Prioritizing Security Updates Based on Risk," superseded and revoked the long-standing BOD 22-01 on June 10, 2026. For the highest-risk class of vulnerability - internet-exposed, KEV-listed, automatable - agencies now get roughly 72 hours to remediate and run a forensic triage to determine whether they have already been breached.

You can see it in this cluster's due dates, each three days from listing: CVE-2026-45659 added July 1 with a July 4 due date, CVE-2026-56164 added July 14 with a July 17 due date, CVE-2026-58644 added July 16 with a July 19 due date. Private companies are not legally bound by any of it. You should still treat 72 hours as the standard, because attackers are moving well inside that window and because auditors under SOC 2 and similar frameworks increasingly ask how fast you close known-exploited findings.

The timing here is almost cruel. July 14, 2026 was also the end of extended support for SharePoint Server 2016 and SharePoint Server 2019 - meaning that Patch Tuesday was the last one those products will ever get. Microsoft has not announced a paid Extended Security Update program for either, unlike the short paid ESU bridge offered for Exchange Server. So the SharePoint Server 2016 2019 security risk is no longer a patching problem you can stay ahead of. It is a permanent, unpatchable exposure that compounds with every future CVE.

To be clear about scope: SharePoint Online is not affected. If your documents live in Microsoft 365, this campaign does not touch you. This is strictly a SharePoint Server 2016, 2019, and Subscription Edition problem.

Across Greater Houston and The Woodlands, we see the same profile repeatedly: an engineering firm, a mid-size law practice, an energy-services company, or an architecture studio with a SharePoint or WSS document library that was stood up years ago for drawings, case files, or project records. Nobody owns it. It was never decommissioned because "somebody might still need the old CAD folder." And because it was set up before anyone thought hard about remote access, it is quietly published to the internet on port 443 with a certificate that still renews.

That is the exact target profile. Texas energy-services and engineering firms carry an additional wrinkle: those legacy libraries often hold client-confidential drawings and contract documents that trigger notification obligations and prime-contractor flow-down requirements if exposed, including NIST 800-171 obligations for anyone in a defense or federal supply chain.

Containment buys you weeks, not years. The durable answer is to migrate SharePoint on-prem to SharePoint Online. A realistic path for a small or mid-size firm:

• Days 1 to 14 - inventory and decide. Site collections, total content size, active versus dormant libraries, custom workflows and web parts, and who actually uses what. Most legacy farms are largely cold archive that belongs in an archive tier, not a live migration.
• Days 15 to 45 - pilot. Move one department with a migration tool such as ShareGate, AvePoint, or Quest Content Matrix (formerly Metalogix). Budget honestly here: published market pricing for these tools runs roughly $7,000 to $40,000 depending on data volume and feature set, with ShareGate commonly cited around $15,000 per year. Microsoft's own free SharePoint Migration Tool is worth evaluating first for simple estates.
• Days 46 to 90 - waves and cutover. Migrate in waves, redirect users, then decommission the on-prem farm rather than leaving it running "just in case." An unowned farm left online is the whole reason you are reading this.

Effort scales with content sprawl and customization, not user count. Market rates for professional migration services span a wide band - commonly around $5,000 to $50,000 for a small or mid-size document estate, climbing into six figures and beyond for large enterprise programs. Custom workflows and heavily customized branding are what blow up budgets, not gigabytes. Pairing the migration with proper Microsoft 365 management is what keeps the new tenant from becoming the next unowned sprawl.

Stop and bring in incident response if you find any of the following: an unexplained .aspx file in a SharePoint-served directory, evidence of w3wp.exe launching a shell, a service account with a password you did not change, or logs that simply do not go back far enough to rule out compromise. Also escalate if the server was domain-joined with a privileged farm account, because SharePoint compromise has a well-documented path to broader domain compromise.

Know what that costs before you need it. Published market rates for digital forensics and incident response generally run about $175 to $600 per hour when you have a retainer in place, and roughly $500 to $1,500 per hour for emergency engagements without one. Annual retainers themselves commonly run $10,000 to $100,000 depending on prepaid hours and response SLA. That is real money. It is far less than the cost of a re-entry three months after you thought you were done, and dramatically less than a ransomware recovery engagement after the same access is sold on to a ransomware affiliate - which, given the Warlock activity already tied to this bug class, is the realistic end state.

Is SharePoint Online affected by the 2026 SharePoint exploits?

No. SharePoint Online, the Microsoft 365 cloud service, is not affected by CVE-2026-32201, CVE-2026-45659, CVE-2026-56164, or CVE-2026-58644. These vulnerabilities affect on-premises SharePoint Server 2016, 2019, and Subscription Edition only.

If I already patched, am I safe?

Not necessarily. If an attacker reached your server before the patch and stole the IIS machine keys, they can continue forging signed serialized payloads that the patched server will still accept and execute. Patching closes the entry point but does not revoke stolen keys. You must hunt for artifacts, rotate machine keys, restart IIS across the farm, and reset service account credentials.

What does rotating IIS machine keys actually do?

It replaces the ASP.NET validation and decryption keys used to sign and encrypt serialized data such as ViewState. Any payload signed with the old stolen key is rejected after rotation. Rotate only after you have removed active footholds and machine-key harvesters, otherwise the attacker harvests the new key immediately.

My SharePoint server is internal only. Do I still need to act?

Yes, though your urgency is lower. CVE-2026-45659 needs only Site Member permissions, so any compromised employee credential or a foothold elsewhere on the network puts an internal server in reach. Patch it, and put it on a decommissioning plan given the July 14, 2026 end of support for SharePoint Server 2016 and 2019.

How quickly should a private company patch a KEV-listed flaw?

Use the federal deadline as your benchmark. Under BOD 26-04, CISA gave agencies roughly 72 hours - three days - from KEV listing for each flaw in this cluster. Known-exploited vulnerabilities on internet-facing systems should be treated as emergency change, not next month's maintenance window.

If you are not certain whether your firm still has an on-prem SharePoint or WSS instance reachable from the internet, that uncertainty is the finding. LayerLogix works with engineering, legal, energy-services, and professional firms across Greater Houston and The Woodlands to find forgotten infrastructure, contain it, hunt for the artifacts that indicate someone got there first, and build a realistic migration path to Microsoft 365 with 100% Texas-based support and 20+ years of experience behind it. Start with a conversation about managed IT services in The Woodlands, or reach us at 713-571-2390 if you need someone on this today.