CISA confirms hackers exploited a SharePoint flaw before Microsoft had a patch ready

Microsoft's July 2026 Patch Tuesday release quietly included a fix for one of the more serious SharePoint vulnerabilities disclosed this year — and it turns out attackers were already using it before the patch existed. The US Cybersecurity and Infrastructure Security Agency confirmed on July 16 that CVE-2026-58644 had been exploited in the wild as a zero-day, adding it to its Known Exploited Vulnerabilities catalog and giving federal agencies until July 19 to apply the fix.

What the flaw actually does

CVE-2026-58644 is a deserialization of untrusted data vulnerability carrying a CVSS score of 9.8 out of 10 — close to the maximum severity a vulnerability can receive. In practice, it lets an attacker who already holds Site Owner-level access to a SharePoint site write and execute arbitrary code remotely on the underlying server. Site Owner privileges are common in enterprise SharePoint deployments — they're routinely granted to team leads and department heads managing their own document libraries, not just IT administrators — which widens the practical pool of accounts an attacker could compromise as a stepping stone.

The vulnerability affects all supported on-premises SharePoint Server editions: Subscription Edition, 2019, and 2016. Notably, this is an on-premises issue — SharePoint Online, Microsoft's cloud-hosted version, is not affected, since Microsoft manages patching directly on that platform.

What attackers did with it

Once inside, attackers used the flaw for a specific and dangerous form of persistence: stealing Internet Information Services (IIS) machine keys. These keys are what IIS servers use to validate and encrypt session data — with a stolen machine key, an attacker can forge authentication tokens that survive password resets and even survive the original vulnerability being patched, unless the keys themselves are rotated. This is precisely the kind of post-exploitation technique that turns a single vulnerability into a long-term foothold.

The zero-day timing problem

Microsoft shipped the patch for CVE-2026-58644 on July 14, as part of its regular Patch Tuesday cycle. CISA's confirmation that the flaw was already being exploited before that release date means this falls into the zero-day category — attackers had working exploits before defenders had a fix to apply. That's a materially worse position than a vulnerability disclosed and patched simultaneously, since organizations had zero window to prepare before exploitation began.

What CISA is telling organizations to do

Beyond simply applying the July 14 patch, CISA's guidance for affected organizations includes enabling Microsoft's Antimalware Scan Interface (AMSI) integration for SharePoint, actively scanning environments for intrusion artifacts consistent with this campaign, establishing enhanced logging to catch follow-on activity, and — critically — avoiding direct internet exposure of on-premises SharePoint servers where it can be avoided. Organizations that were compromised before patching should also rotate their IIS machine keys, since patching the vulnerability alone does not invalidate keys already stolen.

Why this keeps happening to SharePoint

This is not the first time on-premises SharePoint has been targeted this year — CISA issued a related hardening advisory for the platform in mid-July after a separate wave of exploitation attempts. On-premises SharePoint remains a high-value target precisely because it sits at the center of enterprise document management and often holds broad internal access, making a single compromised instance a launchpad into the rest of a corporate network.

What organizations should do now

If your organization runs on-premises SharePoint Server (Subscription Edition, 2019, or 2016), verify the July 14 patch is applied immediately — the federal deadline of July 19 is a reasonable benchmark even for organizations outside government. Enable AMSI integration if it isn't already active, audit Site Owner-level accounts for signs of compromise, and rotate IIS machine keys if there's any indication of exploitation prior to patching. If your SharePoint deployment doesn't strictly need direct internet exposure, this is a good moment to put it behind a VPN or internal network boundary instead.