SharePoint KEV: July 2026 Patch Playbook for Dallas

On July 1, 2026, the Cybersecurity and Infrastructure Security Agency did something that should reframe how every Dallas business treats its on-premises SharePoint servers: it added CVE-2026-45659 to the Known Exploited Vulnerabilities catalog and gave federal agencies until July 4 — three days — to patch it. What makes that timeline remarkable is that Microsoft had originally rated the flaw "Exploitation Less Likely" when it shipped the fix back in May [The Hacker News]. The attackers disagreed. Within weeks, a bug the industry had filed under "we'll get to it" was being used in the wild, and the federal government treated it as an emergency.

If your organization runs SharePoint Server on-premises — Subscription Edition, 2019, or 2016 — this is your playbook. It covers exactly what the vulnerability is, why the KEV listing compresses your timeline whether or not you answer to a federal deadline, and the step-by-step remediation sequence that actually closes the door: not just the patch, but the machine-key rotation and post-compromise verification that a "less likely" bug now demands.

What CVE-2026-45659 Is — and Why KEV Changes Your Timeline

CVE-2026-45659 is a remote code execution vulnerability caused by the deserialization of untrusted data. In plain terms: SharePoint can be tricked into taking attacker-supplied data and reconstructing it into live, executing code on the server. Microsoft addressed it in the May 2026 security updates for SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016 [The Hacker News]. The flaw does not touch SharePoint Online — this is strictly an on-premises problem, which is precisely why it disproportionately affects organizations still running their own SharePoint farms.

The KEV listing is the part that should reset your calendar. A CVSS score of 8.8 is serious but common; hundreds of such bugs are disclosed every year, and no team can patch all of them the day they land. What the KEV catalog tells you is that this specific vulnerability is being exploited today. The federal July 4 deadline does not apply to a private Dallas company — but the threat actors behind the exploitation do not check whether you are a government agency before they scan your perimeter. The moment a flaw is on KEV, its risk profile is no longer "someday"; it is "already."

The SharePoint On-Prem Pattern: This Keeps Happening

CVE-2026-45659 is not an isolated event. It is the latest entry in a pattern that on-premises SharePoint operators have been living through for the better part of a year, and understanding that pattern is what turns a one-time patch into a durable defensive posture.

Deserialization flaws let attacker-supplied data become executing code — turning a document server into an execution surface.

In July 2025, a cluster of SharePoint flaws collectively branded "ToolShell" (CVE-2025-49704, CVE-2025-49706, CVE-2025-53770, and CVE-2025-53771) enabled unauthenticated remote code execution against on-premises servers. That campaign was severe: CVE-2025-53770 carried a CVSS of 9.8, exploitation was widespread within days of proof-of-concept release, and Microsoft attributed activity to Chinese state-linked groups Linen Typhoon and Violet Typhoon for espionage, alongside a financially motivated actor, Storm-2603, that deployed Warlock and LockBit ransomware through the same opening [Microsoft]. The tell-tale artifact — a malicious spinstall0.aspx file dropped to harvest cryptographic secrets — became a household name for incident responders that summer.

The through-line from ToolShell to CVE-2026-45659 is unambiguous: on-premises SharePoint is a high-value, internet-adjacent, complex application that attackers return to again and again. Every farm is a rich target — it holds documents, integrates with identity, and often sits reachable from the corporate perimeter. If your remediation strategy is to react to each new CVE individually, you are perpetually one disclosure behind a motivated adversary. The businesses that came through 2025 and 2026 unscathed are the ones that treated SharePoint patching as a standing operational discipline, not a series of fire drills.

The Patch Playbook: Seven Steps to Close the Door

Applying the update is necessary but, on its own, insufficient — a hard lesson from ToolShell, where attackers who had already stolen a server's ASP.NET machine keys could forge access even after the patch was installed. A complete remediation follows the sequence Microsoft laid out in its on-premises guidance [Microsoft MSRC]. Work through these steps in order for every SharePoint server you operate.

The AMSI-and-key-rotation nuance trips up teams that treat this as a routine Patch Tuesday. Microsoft's guidance is explicit: if you cannot enable AMSI, key rotation and an IIS restart after installing the update are mandatory, not optional. The order matters, too — installing the patch without rotating keys leaves any previously stolen secrets valid.

# Run in the SharePoint Management Shell on a farm server
# 1. Rotate the farm's ASP.NET machine keys
Set-SPMachineKey -WebApplication https://your-sharepoint-url
Update-SPMachineKey -WebApplication https://your-sharepoint-url

# 2. Propagate the change across the farm timer service
Start-SPTimerJob job-spmachinekeymanager

# 3. Cycle IIS so the rotated keys load into worker processes
iisreset.exe /noforce

# 4. Confirm the build is at or above the fixed May 2026 level
(Get-SPFarm).BuildVersion

Managing this sequence across a multi-server farm, during a maintenance window, without breaking authentication for users, is where a disciplined managed IT services practice earns its value. The commands are simple in isolation; the risk is in the choreography.

A controlled patch window — inventory, update, rotate keys, restart IIS, verify — beats an ad-hoc scramble under an active-exploitation clock.

Assume Breach: Post-Compromise Verification

The single most important mindset shift for a KEV-listed vulnerability is this: by the time you are patching, you have to consider that you may already be too late. Because CVE-2026-45659 was exploited while it was still rated "less likely," any unpatched, internet-reachable SharePoint server should be treated as potentially compromised until proven otherwise. Patching stops future exploitation; it does nothing about access an attacker established last week.

If your hunt surfaces anything ambiguous, escalate to formal incident response rather than trying to clean it in place — forging access from stolen keys means a superficially "patched" server can still be under an attacker's control. ITECS maintains an emergency breach response capability for exactly this scenario, and pairs it with continuous endpoint detection and response so post-exploitation behavior is caught in real time instead of discovered months later. For organizations that want to know their exposure before an attacker finds it, penetration testing services can confirm whether an internet-facing SharePoint farm is reachable and exploitable from the outside.

What Dallas Businesses Should Do This Week

The uncomfortable truth behind CVE-2026-45659 is that the technical fix has been available since May — the gap is operational. Plenty of North Texas organizations run on-premises SharePoint for document management, intranets, and line-of-business applications, and many do not have a patch-management cadence fast enough to act inside the window between a KEV listing and mass exploitation. That gap, not the vulnerability itself, is what turns a routine update into a breach.

A pragmatic sequence for a Dallas business this week: confirm whether you run SharePoint on-premises at all; if you do, execute the seven-step playbook above on every instance; if you cannot patch immediately, restrict the servers' internet exposure through managed firewall segmentation as a stopgap; and run the post-compromise hunt regardless. Longer term, the strategic question is whether you should be operating your own SharePoint farm at all — for many mid-market organizations, a migration to SharePoint Online through Microsoft 365 consulting removes this entire class of on-premises RCE exposure by shifting patch responsibility to Microsoft.

CVE-2026-45659 will not be the last KEV-listed SharePoint flaw — the pattern of the last twelve months guarantees another is coming. The organizations that stay ahead are not the ones with the biggest security budgets; they are the ones that can inventory, patch, rotate, restart, and verify inside a three-day window without it becoming a crisis. Build that muscle now, on this CVE, and the next one becomes a routine Tuesday instead of an emergency.

Sources

• The Hacker News — SharePoint RCE CVE-2026-45659 Added to CISA KEV After Active Exploitation
• The Register — Microsoft said exploitation was 'less likely' … but CISA just added SharePoint RCE to KEV list
• CISA — Known Exploited Vulnerabilities Catalog
• Microsoft MSRC — Customer guidance for SharePoint vulnerability (AMSI, machine key rotation, IIS restart)
• Microsoft Security Blog — Disrupting active exploitation of on-premises SharePoint vulnerabilities (ToolShell)