Microsoft released a SharePoint patch on July 14. Two days later, CISA put the vulnerability in its Known Exploited Vulnerabilities catalog and gave US federal agencies until July 19 to act.

That timeline changes the job. This is no longer just patch management. If a vulnerable SharePoint Server was reachable during the exposure window, the question is not only “Did we install the update?” It is also “What happened before we did?”

TL;DR

  • CVE-2026-58644 is a critical deserialization vulnerability in on-premises SharePoint Server
  • Microsoft scores it 9.8; exploitation is network-based, low-complexity, and requires no user interaction
  • CISA added it to the KEV catalog on July 16 based on evidence of active exploitation
  • Patch SharePoint 2016, 2019, and Subscription Edition to the fixed build, then run the SharePoint Products Configuration Wizard
  • For exposed servers, hunt for suspicious IIS worker-process children, web shells, persistence, and credential access; a successful update does not prove the server was clean beforehand

Three Days From Patch to KEV Deadline

The dates tell the story:

DateWhat changed
July 14, 2026Microsoft published CVE-2026-58644 and security updates
July 16, 2026CISA added the vulnerability to its KEV catalog
July 19, 2026CISA’s remediation deadline for US federal civilian agencies

CISA’s deadline does not apply to every organization, but the evidence behind it does. KEV means exploitation has crossed the line from plausible to observed.

The timing is particularly awkward for legacy deployments. SharePoint Server 2016 and 2019 reached the end of extended support on July 14 — the same day this vulnerability was published. Applying the available fix is still essential. Keeping either product in service after that is now an unsupported-platform risk, not a sustainable patch strategy.

SharePoint Online is not listed as affected. This issue concerns customer-managed SharePoint Server installations.

What Actually Broke

CVE-2026-58644 is classified as CWE-502: Deserialization of Untrusted Data.

Serialization turns an object into data that can be stored or transmitted. Deserialization builds the object again. The dangerous version of this pattern appears when a server accepts attacker-controlled serialized data and reconstructs it without enforcing what that data is allowed to create or invoke.

At a high level, the path looks like this:

Crafted network request
        ↓
SharePoint accepts attacker-controlled serialized data
        ↓
Unsafe object reconstruction reaches executable behavior
        ↓
Code runs inside the SharePoint server environment

Microsoft’s current CVSS vector is AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H: network-accessible, low complexity, no privileges, and no user interaction. That is the basis for the 9.8 score.

There is a wrinkle worth stating plainly. Some early Patch Tuesday analyses described the attack as requiring at least Site Owner access, while Microsoft’s published CVE record now says no privileges are required. Public technical details remain limited, so defenders should use the more conservative operational assumption: an unpatched reachable server may be exploitable without a valid account. Do not let an authentication requirement reported in early coverage lower the priority.

Why SharePoint RCE Rarely Stays a SharePoint Problem

Remote code execution is not automatically proof of total domain compromise. It is, however, a credible starting point for one.

SharePoint web front ends sit beside authentication systems, content databases, service accounts, search components, scheduled jobs, and internal document stores. Code execution in that environment can give an attacker opportunities to:

  • deploy a web shell for durable HTTP access;
  • steal application secrets or credentials available to the compromised process;
  • alter SharePoint content or configuration;
  • use the server’s network position to enumerate internal services;
  • create scheduled tasks, services, or other persistence;
  • stage data for collection or exfiltration.

These are post-exploitation possibilities, not CVE-2026-58644-specific indicators reported by Microsoft. That distinction matters: hunt for them because the primitive makes them possible, not because every exploited server will show the same sequence.

Affected Builds

Microsoft’s CVE record lists these fixed build thresholds:

ProductVulnerable belowFixed build
SharePoint Enterprise Server 201616.0.5556.100516.0.5556.1005 or later
SharePoint Server 201916.0.10417.2015316.0.10417.20153 or later
SharePoint Server Subscription Edition16.0.19725.2038416.0.19725.20384 or later

Check the farm build from the SharePoint Management Shell:

Terminal window
(Get-SPFarm).BuildVersion

Do not treat an installed Windows update as the end of the deployment. Apply the update on every SharePoint server and complete Microsoft’s required SharePoint update procedure, including the SharePoint Products Configuration Wizard. Then verify the farm build and health rather than trusting the installer exit code.

Patch First, Preserve Evidence at the Same Time

Incident response and remediation pull in opposite directions. Patching quickly reduces exposure; restarting services and changing the system can also overwrite useful volatile evidence.

For an internet-facing or otherwise untrusted-network-accessible server, run these tracks in parallel where the team permits:

  1. Reduce reachability. Remove direct internet exposure or restrict access at the load balancer, reverse proxy, firewall, or VPN boundary.
  2. Preserve evidence. Record running processes and network connections, export relevant Windows event logs, retain IIS and SharePoint logs, and capture volatile evidence when your response capability supports it.
  3. Patch the entire farm. Update every SharePoint node and complete the configuration wizard.
  4. Hunt across the exposure window. Start before July 14. The patch publication date is not proof of the first exploitation date.
  5. Scope downstream access. Identify the service accounts, databases, file shares, certificate material, and management systems the affected nodes could reach.

If compromise is confirmed, do not “clean” the server and return it to production on intuition. Rebuild from known-good media or a trusted image, restore validated content, and rotate exposed credentials and secrets according to the established incident-response plan.

Hunt the Process Boundary

Public reporting does not yet provide a dependable, CVE-specific request path or payload signature. A narrow URL rule would therefore create more confidence than coverage.

The more durable detection point is the process boundary. SharePoint web requests are commonly handled by IIS worker processes. Shells, script engines, download utilities, and system-management tools launched by w3wp.exe deserve investigation.

The following Microsoft Defender XDR query is a behavioral hunt, not proof of exploitation:

DeviceProcessEvents
| where Timestamp > ago(14d)
| where InitiatingProcessFileName =~ "w3wp.exe"
| where FileName in~ (
    "cmd.exe", "powershell.exe", "pwsh.exe",
    "cscript.exe", "wscript.exe", "mshta.exe",
    "rundll32.exe", "certutil.exe"
  )
| project Timestamp, DeviceName, FileName, ProcessCommandLine,
          InitiatingProcessCommandLine, AccountName, SHA256
| order by Timestamp desc

Tune the time range to when the server was vulnerable and reachable. Validate hits against known administration and application behavior; some environments legitimately invoke supporting processes. The valuable signal is the unusual parent-child relationship combined with an unexpected command line, account, destination, or time.

Also examine:

  • newly created or modified .aspx files in web-accessible SharePoint and IIS paths;
  • unusual outbound connections from SharePoint worker processes;
  • new services, scheduled tasks, local administrators, or startup entries;
  • access to IIS machine keys, configuration secrets, or service-account material;
  • Defender or AMSI alerts related to SharePoint request processing;
  • authentication and privilege changes around suspicious web activity.

Do not stop at the web front end. Correlate findings across every farm node, the load balancer, identity provider, SQL Server, EDR, and perimeter telemetry. An attacker only needs one forgotten node; defenders need the complete farm inventory.

AMSI Is a Layer, Not an Alibi

Microsoft integrates SharePoint Server with the Windows Antimalware Scan Interface (AMSI) so an AMSI-capable engine can inspect incoming requests before SharePoint processes them. Current supported configurations enable AMSI integration by default, and Subscription Edition can scan HTTP request bodies in Balanced or Full mode.

For Subscription Edition, consider Full Mode where performance testing permits it. Confirm the setting separately for each web application and test that the security engine is actually receiving and blocking the official harmless AMSI test pattern.

AMSI can disrupt known malicious request content. It does not replace the security update, exposure reduction, or compromise assessment. An enabled checkbox is not evidence that signatures existed when the request arrived—or that the integration was healthy.

What to Do Today

SharePoint administrators

  1. Inventory every on-premises SharePoint node and identify its exact build.
  2. Apply the fixed build across the complete farm and run the configuration wizard.
  3. Remove unnecessary internet exposure and restrict Central Administration.
  4. Verify AMSI integration and evaluate Full request-body scanning on Subscription Edition.
  5. Begin migration from SharePoint 2016 or 2019 to a supported platform.

Security operations

  1. Treat CISA’s KEV entry as the start of a compromise assessment, not just a patch ticket.
  2. Hunt for IIS worker-process children, web-shell writes, outbound connections, and persistence.
  3. Retain raw IIS, SharePoint ULS, EDR, identity, and perimeter logs.
  4. Escalate suspicious findings into farm-wide and identity-wide scoping.

Incident responders

  1. Establish the earliest possible exposure date from asset, firewall, and update records.
  2. Preserve evidence before avoidable cleanup destroys it.
  3. Determine which identities, secrets, databases, and internal systems were reachable from the affected server.
  4. Rebuild and rotate credentials when compromise is confirmed or system integrity cannot be established.

The patch closes the vulnerable code path. It does not close the investigation.

Sources