Critical SharePoint RCE Patched a Month Ago — Is Your Server Still Exposed?

On July 14, 2026, Microsoft published details of a remote code execution vulnerability in SharePoint Server that needs no authentication, no user interaction, and can be triggered over the network. The flaw, tracked as CVE-2026-58644, carries a CVSS score of 9.8—placing it in the “patch immediately” category for any organization running on-premises SharePoint.

But there’s a twist that throws the usual patch cadence out the window: the fix for this critical bug was included in the June 9, 2026 SharePoint security updates. Any SharePoint farm that already reached the specified build levels last month is protected. For everyone else, the disclosure turns a routine update into an emergency because attackers now know exactly which systems to target.

A Patch That’s Already in Your Update Pipeline

CVE-2026-58644 affects all three supported on-premises releases of SharePoint Server: 2016, 2019, and the Subscription Edition. Microsoft did not flag SharePoint Online as vulnerable, so the risk sits squarely with organizations that run their own farms on Windows Server.

The vulnerable builds and their corresponding fixed versions are:

These updates were released as part of the June 2026 Patch Tuesday cycle, but the vulnerability details remained under wraps until July 14. Microsoft’s Security Response Center did not issue any new SharePoint-specific packages in July for this CVE—the ship-the-fix-before-disclosure model means the protection was silently delivered in the previous month’s cumulative update.

Why Deserialization Is a Server Killer

Microsoft categorizes CVE-2026-58644 as CWE-502: deserialization of untrusted data. In plain English, a vulnerable SharePoint component accepts data from a remote user and reconstructs it into objects that can execute code. Because the attacker controls what gets deserialized, they can craft a payload that transforms a simple network request into full server-side remote code execution.

The CVSS 3.1 vector tells the story: attack vector Network, attack complexity Low, privileges required None, user interaction None. A successful exploit can compromise confidentiality, integrity, and availability—essentially handing an attacker the keys to your SharePoint server.

While no public exploit code has been published as of this writing, the technical ingredients are well understood. Deserialization bugs have a long and ugly history in enterprise software. SharePoint itself has been a recurrent target; in 2025, the ToolShell campaign demonstrated how quickly an unpatched SharePoint server could be turned into a beachhead for ransomware, credential theft, and lateral movement.

Microsoft’s CVSS data marks the exploit maturity as “Unproven,” meaning neither public proof-of-concept code nor active exploitation has been confirmed. But don’t let that lull you into complacency. When a vulnerability is this easy to trigger and this impactful, exploit development is often just a matter of time.

Who’s at Risk

If you operate any of the following, you are directly affected:

• A SharePoint Server 2016 farm with a build number below 16.0.5556.1005.
• A SharePoint Server 2019 farm with a build number below 16.0.10417.20153.
• A SharePoint Server Subscription Edition farm with a build number below 16.0.19725.20384.

Internet-facing SharePoint servers are the obvious high-value targets. But don’t forget servers reachable from partner networks, VPN pools, guest Wi-Fi, or even broad internal segments—attackers frequently pivot from a less-secure workstation to an internal server.

The vulnerability does not require authentication, so any exposed server can be attacked without credentials. That means a simple misconfiguration in a firewall rule or a compromised IoT device on the same network could provide the network path an attacker needs.

The June-July Timeline

The patch timeline for CVE-2026-58644 breaks from the usual “Patch Tuesday disclosure day” rhythm. Here’s how it played out:

• June 9, 2026: Microsoft ships monthly SharePoint security updates, including fixes for this flaw, but does not publish the CVE.
• July 14, 2026: The vulnerability is publicly disclosed on the MSRC website. By this point, the fix has been available for 35 days.

This isn’t unprecedented—Microsoft sometimes embeds fixes for unreported or undisclosed vulnerabilities in monthly updates to give customers a head start before the details leak. It creates a complicated risk calculation, though. If your patch management team skipped the June SharePoint updates because they didn’t seem critical, you now have a 35-day window of exposure that attackers can immediately probe.

Your 72-Hour Plan

Time is not on your side. Here’s a triage checklist for IT and security teams.

1. Inventory Every SharePoint Server

Run a complete inventory of all SharePoint servers in your environment—not just the front-end web servers. Application servers, search servers, and any node that hosts SharePoint components must be checked. A common pitfall is looking only at the server that receives inbound HTTPS requests; attackers can reach backend servers through crafted requests that bypass the front end.

2. Verify Build Numbers

On each server, check the actual build number of the SharePoint installation. You can find this in Central Administration under “Servers in Farm,” via PowerShell (Get-SPFarm | Select BuildVersion), or by examining the version stamp in the SharePoint hive. Compare against the fixed builds listed above.

The fact that Windows Update reports “fully patched” is not enough. SharePoint updates often require manual post-installation configuration steps, and if those steps were skipped, the farm may still be running old binaries.

3. Apply the Fix

If any server is below the fixed build, install the corresponding cumulative update immediately. The updates are:

• SharePoint 2016: KB5002880 and KB5002881
• SharePoint 2019: KB5002874
• Subscription Edition: KB5002873

After installing the binaries, run the SharePoint Products Configuration Wizard on every server in the farm to ensure database schema updates and other post-patch actions complete. A multi-server farm must be updated in a coordinated way; failing to update a single backend node can leave the farm vulnerable.

4. Restrict Network Access While You Patch

As an interim measure, limit access to SharePoint servers. Use firewall rules, reverse proxies, or virtual private networks to restrict which IP addresses can reach the servers. If the server does not need to be internet-facing, remove the public listener entirely. Even if you’ve already patched, this is a good hardening step.

5. Hunt for Signs of Compromise

Although there are no known indicators of compromise (IOCs) specific to CVE-2026-58644, you should still look for generic signs of SharePoint exploitation. Monitor for:

• Unusual POST requests to SharePoint web services or endpoints.
• New or modified .ASPX files in the SharePoint layouts or virtual directories.
• Suspicious child processes spawned by the IIS worker process (w3wp.exe).
• Unexpected scheduled tasks or service accounts.
• Changes to machine keys or security token service configuration.

The 2025 ToolShell attacks showed that SharePoint servers are often used to deploy web shells and extract secrets. If you find any anomalies, initiate incident response immediately.

What Comes Next

The disclosure of CVE-2026-58644 without a simultaneous patch drop is a test of patch management maturity. Companies that keep SharePoint farms consistently up to date are already protected. Those that lagged on June updates are now in a race against attacker scan-and-exploit cycles.

We’ve seen this movie before. Within days—sometimes hours—of a SharePoint RCE disclosure, scanning traffic spikes as threat actors hunt for exposed servers. If exploit code surfaces, unpatched servers will be owned in minutes.

In the coming weeks, watch for:

• A public proof-of-concept (PoC) exploit published on GitHub or social media.
• Microsoft updating the CVE to indicate active exploitation.
• Additional guidance from CISA or other national cybersecurity agencies.

For now, the best defense is a simple one: check your build numbers, apply the updates you might have missed, and breathe a little easier knowing that the fix has been sitting in your update catalog for over a month. If you were already on the June patch level, document it and move on. If not, today is the day to close the gap.