CISA Urges SharePoint Patch Amid Active Exploitation

Federal agencies running on-premises Microsoft SharePoint Server have until July 4, 2026 to patch a high-severity remote code execution vulnerability that attackers are actively exploiting. The U.S. Cybersecurity and Infrastructure Security Agency confirmed on July 1 that CVE-2026-45659 is being used in the wild, reversing Microsoft’s earlier assessment that exploitation was unlikely.

The vulnerability was patched by Microsoft in a late-May out-of-band update. The five-week gap between that patch and CISA’s confirmation of active exploitation means organizations that delayed the update are now racing against adversaries who may already be inside their networks.

Reporters noted that CISA’s July 1 Known Exploited Vulnerabilities listing included confirmed evidence that exploitation is underway.

Why Site Member Access Makes Every Employee a Potential Attack Vector

CVE-2026-45659 works differently than most enterprise vulnerabilities. Attackers targeting most systems need privileged access — a domain administrator account, a service account, or at minimum a foothold on a privileged system. This flaw requires none of that.

Microsoft’s advisory states that any authenticated user with Site Member permissions can trigger it. Site Member is not an raised role. It is the standard access level granted to employees who collaborate on SharePoint document libraries — staff who need to view, upload, or edit files.

In most enterprise SharePoint deployments, Site Member access is distributed broadly: across teams, departments, contractors, and partner organizations with shared document workspaces. The attack surface for this flaw scales directly with an organization’s normal use of SharePoint as a collaboration platform.

This is a structural problem. The very feature that makes SharePoint useful — broad, delegated access to documents — becomes the primary attack vector. An intern, a temp, or a vendor with standard credentials can be enough to bring down the whole server.

How the Deserialization Flaw Works

The underlying vulnerability is classified as CWE-502, deserialization of untrusted data. When SharePoint transmits or stores structured data, it converts complex objects — document metadata, session state, application configuration — into a flattened byte stream for transit or storage. Deserialization reverses that: the system receives the byte stream and reconstructs it into working objects.

OWASP’s documentation on these flaws explains the core problem: when an application reconstructs objects without sufficiently verifying the result, an attacker who controls the input can cause the application to instantiate and execute a malicious object instead of legitimate data.

That is what CVE-2026-45659 allows. An attacker who sends a specially crafted serialized payload causes SharePoint to reconstruct and execute attacker-controlled code. That code runs inside the SharePoint worker process, w3wp.exe, under the application pool’s service identity.

Microsoft confirmed that the attack requires no prior knowledge of the target system and can achieve, in the company’s words, “repeatable success with the payload against the vulnerable component” — meaning once exploit code exists, it can be deployed reliably at scale against any unpatched SharePoint server an attacker can reach and authenticate to.

The vulnerability affects three on-premises SharePoint Server product lines. SharePoint Online — the Microsoft 365 cloud version — is not affected.

Product — Vulnerable Below Build

SharePoint Server Subscription Edition — 16.0.19725.20280
SharePoint Server 2019 — 16.0.10417.20128
SharePoint Enterprise Server 2016 — 16.0.5552.1002

To check a farm’s current build, run the following in the SharePoint Management Shell: Get-SPFarm | Select BuildVersion. If the build falls below the thresholds above, the server is actively vulnerable. Administrators running multi-server farms must check every node individually; a single updated web front-end does not protect the farm if other servers remain on a vulnerable build.

How to Apply the Microsoft SharePoint Patch

Microsoft released the fix as an out-of-band update in late May 2026. The flaw was inadvertently omitted from the standard May Patch Tuesday advisory, meaning organizations that rely on the security bulletin to prioritize patching may not have flagged this update as urgent at the time of release. CISA’s July 1 KEV listing makes that prior triage irrelevant: the patch exists and exploitation is confirmed.

The Microsoft Security Response Center advisory for CVE-2026-45659 lists the specific fixes:

SharePoint Server Subscription Edition → KB5002863
SharePoint Server 2019 → KB5002870
SharePoint Enterprise Server 2016 → KB5002868

After applying each update, two additional steps are required on every server in the farm. First, run the SharePoint Products Configuration Wizard on each server — application server first, then each web front-end. They wizard does not run automatically; skipping it leaves the farm in a partially configured state. Second, run iisreset /restart on each web front-end after the wizard completes. Leaving IIS in its pre-patch state on any node preserves a vulnerable endpoint even after the binaries have been updated.

Is the Server Already Compromised?

Organizations that have not applied the May 2026 update should treat patching and compromise assessment as simultaneous, not sequential activities. A successful exploit against this vulnerability runs attacker-controlled code inside the SharePoint worker process. Defenders should look for the following:

Anomalous process trees: Monitor for w3wp.exe spawning child processes — particularly cmd.exe, powershell.exe, or cscript.exe — on SharePoint servers. This is the most reliable post-exploitation indicator.

Suspicious IIS log entries: Review logs on all web front-end servers for unusual POST requests to /_layouts/ paths, particularly those with unusually large request bodies or content types inconsistent with normal SharePoint operations.

Unauthorized ASPX files: Search web-accessible SharePoint directories for any .aspx files that did not exist before the vulnerability’s disclosure window. Web shells planted through a deserialization exploit typically appear in these locations.

Credential and service account anomalies: Review authentication logs for unexpected logins from service accounts, geographic anomalies, or activity at unusual hours.

Temporary Mitigations for Organizations That Cannot Patch Immediately

Patching is the only complete fix. Organizations whose change management or testing processes prevent immediate deployment should implement the following as temporary risk reduction:

Restrict Site Member access: Review and tighten who holds Site Member permissions. Suspend accounts for contractors, former employees, or partner organizations that no longer require active access.

Network segmentation: Block direct internet access to SharePoint servers where possible. Restrict access to trusted internal networks or authenticated VPN connections.

Web application firewall rules: Deploy rules targeting anomalous POST requests to SharePoint deserialization endpoints.

Rotate service account credentials: Reset passwords for all SharePoint application pool identities, service accounts, and managed accounts regardless of whether a compromise has been identified.

These are stopgaps — not alternatives to the patch.

SharePoint Has Been a Persistent High-Value Target

This vulnerability arrives in the context of a documented pattern. In April 2026, Microsoft patched a different SharePoint vulnerability exploited as a zero-day. In March 2026, CISA warned of another SharePoint flaw being actively targeted. In July 2025, Chinese-linked nation-state actors Linen Typhoon and Violet Typhoon, alongside the financially motivated ransomware group Storm-2603, exploited a separate critical set of SharePoint vulnerabilities — the ToolShell chain — against more than 150 organizations including government agencies and critical infrastructure operators, according to Resecurity’s reporting. Microsoft’s Security Blog provides detailed analysis of that campaign.

The pattern reflects SharePoint’s structural position inside enterprise networks. A successfully compromised SharePoint server is not a file-storage incident — it is a foothold. The application pool service identity running SharePoint code typically has broad network access: to SQL Server databases, to Active Directory for user provisioning, and in many deployments to service accounts with privileges well beyond the document library. Attackers who achieve code execution on a SharePoint server through this vulnerability inherit whatever that server can reach — which in most enterprise deployments is considerably more than the documents themselves.

SharePoint Server 2016 Support Ends in Ten Days

Organizations running SharePoint Enterprise Server 2016 face a compounding deadline. Microsoft has confirmed that this product line reaches end of extended support on July 14, 2026 — ten days from today. After that date, the company will no longer release security updates for the 2016 product line, meaning any subsequent vulnerability discovered there will remain permanently unpatched on unupgraded deployments.

CISA’s July 4 remediation deadline covers CVE-2026-45659 specifically. The end-of-support deadline is a separate and permanent condition. Organizations still running SharePoint Server 2016 should treat both as simultaneous drivers for a migration decision.

Frequently Asked Questions

Does CVE-2026-45659 affect SharePoint Online or Microsoft 365? No. This flaw affects only on-premises SharePoint Server deployments — specifically SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016. Microsoft’s cloud-hosted SharePoint Online in Microsoft 365 is managed and patched by its own infrastructure and is not affected.

I applied the May update. Am I protected? Verify rather than assume. Check the farm’s build number using Get-SPFarm | Select BuildVersion and compare it against the fixed builds listed above. This vulnerability was inadvertently omitted from the original May security update bulletin but was addressed by the same May 2026 update packages. If the farm is running the fixed builds, it is protected against this specific flaw — but only if the SharePoint Products Configuration Wizard and an IIS reset were completed on every server in the farm after the update was installed.

Why did CISA classify this as actively exploited when Microsoft said exploitation was less likely? Microsoft’s initial assessment reflected the technical bar required at the time of disclosure in late May. CISA’s July 1 Known Exploited Vulnerabilities addition means the agency has confirmed evidence that exploitation is occurring in the wild. The two assessments are not contradictory: the vendor’s rating reflected the exploitation likelihood at disclosure; the agency’s listing reflects observed reality five weeks later. When a KEV listing contradicts an earlier vendor assessment, the KEV listing governs remediation priority.

What can an attacker do once they have code execution on a SharePoint server? Code execution in the SharePoint worker process gives an attacker the same network access and permissions that the application pool identity holds. In most deployments this includes read and write access to SharePoint content databases, access to the SharePoint administration service, and potentially access to other network resources the server can reach. Post-exploitation activity in similar incidents has included lateral movement to Active Directory, exfiltration of document library contents, deployment of web shells for persistent access, and in ransomware incidents, encryption of storage accessible from the server.