SharePoint CVE-2026-58644: Active RCE Attacks

CVE-2026-58644 in on-premises Microsoft SharePoint Server is being actively exploited. The untrusted-data deserialisation vulnerability allows an unauthorised attacker to execute code over a network. Microsoft rated it 9.8 under CVSS 3.1, and CISA added it to the Known Exploited Vulnerabilities catalogue on 16 July 2026.

Patching and compromise assessment need to run in parallel. The NVD record for CVE-2026-58644 reports exploitation: active, automatable: yes and technicalImpact: total. CISA’s deadline for organisations subject to its directive is 19 July. Companies outside the US federal government should still treat that timeline as a strong operational signal, especially where SharePoint is Internet-accessible.

CVE-2026-58644 at a glance

Field	Confirmed information
Product	on-premises Microsoft SharePoint Server
Weakness	CWE-502 — Deserialisation of Untrusted Data
Vector	network, with no privileges or user interaction required
Impact	remote code execution
CVSS 3.1	9.8 Critical according to Microsoft
Exploitation	active according to CISA-ADP
KEV	added 16 July 2026, due 19 July 2026
Sources	NVD, CISA KEV and MSRC

Do not confuse this vulnerability with the earlier ToolShell chain or other July SharePoint defects. One product can have several independent RCE paths. Our Microsoft July 2026 SharePoint and AD FS briefing covers the broader security release; this article focuses only on CVE-2026-58644, its build matrix and response to confirmed exploitation.

Affected products and version thresholds

According to the data Microsoft supplied with the CVE, the issue affects:

SharePoint Enterprise Server 2016 before 16.0.5556.1005;
SharePoint Server 2019 before 16.0.10417.20153;
SharePoint Server Subscription Edition before 16.0.19725.20384.

NVD also displays an enriched CPE range that may show a different Subscription Edition build threshold from the CNA data block. Where data differs, the current MSRC bulletin and documentation for the specific package should drive deployment, not a number copied manually from an aggregator. Administrators must confirm that the package matches the edition and that every server in the farm completed the update.

SharePoint Online is not automatically within the scope of a CVE describing the on-premises product. An organisation may still run a hybrid environment: local servers, Web Application Proxy, reverse proxies, search, integrations and identity synchronisation. Inventory must distinguish SaaS from self-managed 2016, 2019 and Subscription Edition farms.

Why deserialisation can lead to code execution

Serialisation converts an object into a format that can be stored or transmitted. Deserialisation reconstructs the object on the receiving side. If an application accepts data from an untrusted client and lets the runtime invoke behaviour associated with the resulting object type, the attacker can influence execution flow rather than merely field values.

CWE-502 covers cases where untrusted data is deserialised without sufficient validation, type restrictions or integrity protection. In a .NET environment, a chain can combine available classes and methods to perform an unintended operation. The attacker does not necessarily need to upload a standalone executable as the first step; causing the server to construct a dangerous object graph may be enough.

Defenders do not need a public payload to understand priority. The official CVSS vector says network access, low complexity, no privileges, no user interaction and high confidentiality, integrity and availability impact. Reachable servers therefore belong at the top of the response queue.

Why a patch does not close the exposure window

The update removes the current exploitation path, but it does not remove accounts, webshells, scheduled tasks or credentials left earlier. Because CISA confirms active exploitation, each exposed affected farm needs forensic triage, not merely a routine overdue update.

The team should answer four questions:

Was the server vulnerable while attacks were active?
From which networks and through which proxies was it reachable?
Which logs and host evidence remain for that period?
Is there evidence of code execution, persistence or credential theft?

No EDR alert is not proof of no intrusion. An application worker can invoke legitimate system tools, while an attacker may use memory, existing accounts and SharePoint functionality. Correlate IIS, ULS, Windows, EDR, proxy, WAF and farm-change telemetry.

A four-hour response plan

Hour 0–1: inventory and traffic restriction

Find every farm server, test node, DR instance and old publication. Read the version from actual binaries. Document Internet → CDN/WAF → reverse proxy → IIS → SharePoint paths. If patching cannot begin immediately, restrict traffic to trusted sources or remove public publishing. Do not run a public proof of concept against production.

Hour 1–2: preserve evidence

Export IIS logs with full URI, method, response code, client address and timestamp. Preserve ULS, PowerShell logs, Windows Security, Sysmon or EDR data, file-change history, services, scheduled tasks, local accounts and privileged-group membership. Capture farm configuration and solution inventory without modifying suspicious artefacts.

Hour 2–3: patch and technical validation

Deploy the package under MSRC and SharePoint procedures, including required configuration steps. Check each node individually. A package marked “installed” in patch management does not prove binaries and farm schema reached the intended state.

Hour 3–4: begin threat hunting

Investigate unusual requests, IIS child processes, new files in application directories, web.config changes, unknown assemblies, tasks, services and accounts. Review outbound traffic, database access, secret operations and administrator logins. Start the investigation at the last confirmed clean state, not merely the CVE publication date.

Telemetry worth correlating

Source	Analytical questions
IIS and reverse proxy	unusual POSTs, elevated 500 responses, new agents, sources and paths
ULS	deserialisation exceptions, request anomalies, type and assembly loading errors
Windows/EDR	`w3wp.exe` child processes, PowerShell, cmd, transfer and archiving tools
filesystem	new or changed ASPX, DLL, configuration and web-directory artefacts
identity	new accounts, group changes, service and administrator logons
network	new outbound connections, DNS, tunnels and traffic to rare ASNs
SQL	unusual queries, data exports, new logins and permission changes

These are hypotheses based on the potential result of RCE, not an official IOC list for one attacker tool. Post-exploitation can change. Behavioural detection is more durable than a single filename. Integrate the work with Sigma and SIEM detection engineering and an incident-response tabletop exercise.

Correct isolation and rotation order

Where evidence indicates code execution, do not stop after deleting one file. Remove the suspect node from traffic, preserve disk and memory evidence, and move service to a clean patched system. Establish which secrets the application-pool identity and farm accounts could access.

Rotation may cover farm accounts, service identities, database credentials, certificates and integration secrets. Sequence changes around dependencies so evidence is preserved and uncontrolled downtime is avoided. If the attacker could modify configuration, rebuilding from a trusted source is more defensible than manually “cleaning” the host.

Segment SharePoint servers from domain controllers, management systems and administrator workstations. Our internal network segmentation penetration testing guide explains how to validate these paths. RCE on an application server should not create an automatic route to the whole domain.

Validating the whole farm

After deployment, verify:

binary versions on every 2016, 2019 or Subscription Edition server;
services, timer jobs, search and queue health;
completion of required farm configuration steps;
authentication, upload, download, search and integration functions;
absence of an old node from the load balancer, DR and automation pools;
log completeness after restart;
a safe negative test of the vulnerable behaviour class.

Record update identifier, before-and-after versions, time exposure ended, approvers and threat-hunting result. This creates audit evidence and distinguishes “package sent” from “risk closed”. Our vulnerability management process develops this practice further.

Relationship to earlier SharePoint attacks

Teams may assume work performed for ToolShell CVE-2025-53770 automatically protects against the new issue. WAF rules, IOCs and a checker for the earlier path do not replace the CVE-2026-58644 update. Better telemetry may help, but the deserialisation mechanism and post-exploitation artefacts can differ.

That is why a playbook should focus on behaviour classes: unexpected execution by an IIS worker, file changes, new identities, secret access and outbound traffic. A signature for one payload ages quickly.

Reporting status without a misleading “no IOCs” claim

An executive report should separate vulnerability, exposure, telemetry completeness, anomalies and remediation progress. “No indicators detected” is misleading where ULS retention is two days, EDR arrived after the exposure window began or the reverse proxy omits the full URI.

A better statement is: “three of four nodes were publicly reachable; 30 days of IIS and 14 days of EDR data were retained; the update is confirmed across the farm; account and outbound-traffic review is complete; absence of ULS data before 10 July limits confidence.” The reader can then distinguish evidence from evidence gaps.

Do not close the incident on package status alone. Closure criteria should cover exposure-window analysis, the credential-rotation decision, confirmation that no unknown artefacts remain, restored monitoring and formal acceptance of residual uncertainty by the risk owner.

Criteria for restoring full traffic

Restore full traffic only after explicit criteria are met: every node reports the fixed build, farm configuration completed successfully, critical business functions passed testing, and IIS, ULS and EDR telemetry is reaching the analytical platform again. Confirm separately that the load balancer, disaster-recovery environment and automation do not reference an old image.

If threat hunting is still in progress, the risk owner should know which data has been reviewed and which retention gaps remain. Restoring availability does not automatically close the incident. The service can resume on a clean farm while the investigation remains open, provided evidence is preserved, credential rotation is controlled and monitoring of the replacement nodes is increased.

The management decision

An Internet-facing affected SharePoint farm is a high-priority incident today. The technical owner is accountable for patching and version evidence. The SOC owns exposure-window analysis. IAM and integration owners prepare controlled rotation. The business owner accepts the maintenance window or the risk of continued publication with full knowledge that exploitation is confirmed.

Need rapid validation after this actively exploited SharePoint flaw? Contact BreachRoad for a safe review of exposure, versions, attack paths, logs and segmentation, with defensible evidence that the risk has been closed.