CVE-2026-58644 is an unauthenticated deserialization remote code execution flaw (CWE-502) in on-premises Microsoft SharePoint Server. NVD scores it 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N). Microsoft shipped fixes in the July 14, 2026 updates, confirmed in-the-wild exploitation on July 15, and CISA added it to the Known Exploited Vulnerabilities catalog on July 16 with a July 19 federal remediation deadline. A working exploit was demonstrated at Pwn2Own Berlin and it was weaponized as a zero-day before patches shipped. This is a hunt-now, patch-now vulnerability for any organization running on-prem SharePoint. SharePoint Online / Microsoft 365 is not affected.
Am I vulnerable?
Any internet-facing or internally reachable on-premises SharePoint farm running a build below the July 2026 fixed level is exploitable without credentials. The flaw is in how the server deserializes attacker-supplied data, so exposure is a function of build version, not of which SharePoint features you have enabled.
Affected versions
| Product |
Vulnerable range |
Fixed build |
| SharePoint Enterprise Server 2016 |
16.0.0 to < 16.0.5556.1005 |
16.0.5556.1005 |
| SharePoint Server 2019 |
16.0.0 to < 16.0.10417.20153 |
16.0.10417.20153 |
| SharePoint Server Subscription Edition |
16.0.0 to < 16.0.19725.20384 |
16.0.19725.20384 |
Diagnostic commands
Read-only checks to confirm exposure:
- Farm build (SharePoint Management Shell):
(Get-SPFarm).BuildVersion. Vulnerable if the build is below your SKU's fixed threshold, for example 16.0.10417.x < 16.0.10417.20153 on Server 2019.
- Per-server inventory across the farm:
Get-SPServer | Select-Object Address, Role, Version. Any server below its SKU's fixed build is unpatched. Mixed versions mean a partially patched farm that is still exploitable through the lagging node.
- Unauthenticated build disclosure (from any host):
curl -sSI https://<sharepoint-host>/_layouts/15/start.aspx | grep -i "MicrosoftSharePointTeamServices". The response header leaks the build (e.g. MicrosoftSharePointTeamServices: 16.0.0.10417); a build below the fixed threshold on an internet-facing server confirms exposure.
- Confirm updates installed:
Get-SPProduct -Local | Select-Object ProductName, @{n='Patches';e={$_.PatchableUnitDisplayNames}}. Missing the July 2026 security update entries indicates the server still needs remediation.
"Vulnerable" here means any farm below the fixed build, regardless of whether the server is directly internet-facing. Internet exposure raises urgency but internal reachability is still exploitable by an attacker who already has a network foothold.
Vulnerability
The root cause is deserialization of untrusted data (CWE-502). SharePoint accepts a serialized object over a network request and reconstructs it without validating that the data is safe to instantiate. By supplying a crafted serialized payload, an unauthenticated attacker triggers arbitrary code execution in the context of the SharePoint IIS worker process (w3wp.exe), which runs under the farm's service account. No credentials, no user interaction, and low attack complexity are required, which is what drives the 9.8 rating and the network attack vector (AV:N/PR:N).
Deserialization RCE is the same bug class behind the 2025 SharePoint "ToolShell" chain (CVE-2025-53770 / CVE-2025-49704). CVE-2026-58644 is a distinct vulnerability, but it shares the post-exploitation playbook: gain code execution, then steal the server's ASP.NET machine keys to forge authentication material. Zero Day Initiative flagged that Microsoft initially listed "Exploit Maturity: Unknown" even though the bug was demonstrated with a working exploit at Pwn2Own Berlin, and advised defenders to treat it as immediately exploitable rather than trust that label. Reporting also surfaced a discrepancy where one Microsoft-attributed description mentioned a "Site Owner" privilege; the authoritative NVD vector is unauthenticated (PR:N), so plan defenses on the assumption that no credentials are needed.
Threat model
Who would exploit this: Because this is an unauthenticated network deserialization RCE against internet-facing on-prem SharePoint servers that are typically domain-joined and run under privileged service accounts, it appeals to the full spectrum of financially motivated and state-aligned operators. The most probable early exploiters are opportunistic ransomware affiliates and initial-access brokers mass-scanning for exposed SharePoint, followed by state-aligned espionage actors who value SharePoint as a document and credential repository. CISA confirms active exploitation and highlights machine-key theft as the post-exploitation pattern, but has not publicly attributed this CVE to a specific named group.
What they're after:
- Establish an unauthenticated code-execution foothold on the SharePoint server
- Steal ASP.NET / IIS machine keys to forge auth tokens and regain access after patching (persistence)
- Harvest and exfiltrate documents, PII, and cached credentials stored in SharePoint
- Lateral movement into Active Directory and connected back-end systems via the service account's privileges
- Deploy follow-on payloads (web shells, malware, or ransomware) for extortion
Attack chain: An attacker scans the internet for exposed on-prem SharePoint servers and sends a crafted request carrying a malicious serialized object, which the server deserializes without validation, yielding code execution as the SharePoint/IIS service account. Operators then typically drop a web shell and steal the server's machine keys, which lets them forge valid authentication payloads and retain access even after the patch is applied. From that privileged foothold they enumerate the environment and pivot toward Active Directory, file shares, and the SQL back-end.
Blast radius: A compromised on-prem SharePoint server hands the attacker code execution under a privileged, usually domain-joined service account, exposing the SQL content databases, connected file shares, and Office/identity integrations, plus every document, PII record, and credential the server stores or caches. Theft of the machine keys enables durable forged-authentication persistence that survives patching, and the service account's Active Directory reach opens a path to broader domain compromise. In practice this is a pivot point from one collaboration server to the organization's identity and data core.
Mitigation
Patch
Install the July 14, 2026 security updates on every server in the farm and bring each SKU to at least its fixed build:
| Product |
Patch to build |
| SharePoint Enterprise Server 2016 |
16.0.5556.1005 |
| SharePoint Server 2019 |
16.0.10417.20153 |
| SharePoint Server Subscription Edition |
16.0.19725.20384 |
Patch the entire farm. A single lagging front end leaves the whole environment exploitable. Per-SKU KB numbers were not published in a machine-readable form at write time; confirm the exact KB against the MSRC advisory linked below.
Critically, patching alone does not evict an attacker who already stole your machine keys. If you have any suspicion of prior compromise, complete a threat hunt first, then rotate keys (below), then recycle IIS.
Configuration mitigation
After patching and completing threat hunting, rotate the IIS ASP.NET machine keys on every server so that any keys an attacker may have stolen can no longer forge valid authentication payloads:
Rotate machine keys, then recycle IIS (run AFTER patching + threat hunt):
# SharePoint Management Shell (elevated). Rotate machine keys on every server in the farm.
Update-SPMachineKey -WebApplication "https://<your-sharepoint-web-app-url>"
# Confirm all target web applications first (read-only)
Get-SPWebApplication | ForEach-Object { $_.Url }
# Recycle IIS so the new keys load
iisreset /noforce
Rotating keys before you have evicted the attacker simply hands them a chance to steal the new keys. Order matters: hunt, then patch, then rotate.
Compensating controls
Where immediate patching is not possible, layer defense-in-depth. These buy time; they are not a substitute for the update:
- Enable AMSI Full Mode integration for SharePoint (full request-body scanning) and keep a supported AV/EDR running on the SharePoint servers. This is Microsoft's primary interim mitigation.
- Remove direct internet exposure. Place SharePoint behind a VPN or an authenticating reverse proxy rather than publishing it to the open internet.
- Restrict and monitor Central Administration access to a minimal administrative network segment.
- Constrain the service account to least privilege and monitor it for anomalous authentication and lateral movement, so a single-server compromise does not immediately translate to domain compromise.
Detection (starter rules — validate before deploying)
These rules are AI-generated starter content. Test against your own telemetry and tune falsepositives before deploying to production.
Network and log signals
- IIS web logs: POST to
/_layouts/15/ToolPane.aspx or /_layouts/16/ToolPane.aspx with DisplayMode=Edit, especially with a spoofed Referer of /_layouts/SignOut.aspx. This is the canonical SharePoint deserialization request pattern; treat unauthenticated hits as high priority.
- IIS web logs: GET to a newly created, non-stock
.aspx under /_layouts/15/ or /_layouts/16/ immediately following a ToolPane POST from the same client. Historically observed drop names include spinstall0.aspx and variants; alert on any unexpected _layouts .aspx, not a fixed filename.
- Filesystem: unexpected
.aspx files with recent write timestamps in C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\ or the site's \wss\VirtualDirectories\<port>\, owned by the app-pool identity. These are candidate web shells or machine-key dumpers.
- Process telemetry:
w3wp.exe (the SharePoint app-pool worker) spawning cmd.exe, powershell.exe, or pwsh.exe. This is near-absent in normal SharePoint operation and is the strongest post-exploitation signal.
- Network: outbound connections from
w3wp.exe to non-Microsoft / non-corporate IP space (C2 beacon, tool download, or key exfil).
- Anomalous crafted
__VIEWSTATE POSTs after any suspected compromise, indicating forged-authentication persistence via stolen machine keys.
YARA
rule CVE_2026_58644_sharepoint_aspx_webshell_starter
{
meta:
author = "CVE Brief"
description = "Starter heuristic for suspicious ASPX web shells / MachineKey dumpers dropped in SharePoint _layouts dirs during CVE-2026-58644 (SharePoint deserialization RCE) post-exploitation"
reference = "Behavioral patterns from public SharePoint ToolShell RCE writeups; generic web-shell heuristics"
warning = "AI-generated starter rule - validate in your environment before deploying; may match benign admin scripts"
cve = "CVE-2026-58644"
strings:
$aspx_page = "<%@ Page" ascii nocase
$aspx_asm = "<%@ Assembly" ascii nocase
$aspx_import = "<%@ Import" ascii nocase
// dynamic code-exec / process-spawn primitives common to ASPX shells
$x1 = "System.Diagnostics.Process" ascii nocase
$x2 = "ProcessStartInfo" ascii nocase
$x3 = "cmd.exe" ascii nocase
$x4 = "powershell" ascii nocase
$x5 = "eval(" ascii nocase
$x6 = "Request[" ascii nocase
$x7 = "Response.Write" ascii nocase
// SharePoint MachineKey / ViewState key theft markers
$k1 = "MachineKeySection" ascii nocase
$k2 = "ValidationKey" ascii nocase
$k3 = "DecryptionKey" ascii nocase
$k4 = "System.Web.Configuration" ascii nocase
condition:
// an ASPX file that is either an exec-style shell or a machinekey dumper
(1 of ($aspx_page, $aspx_asm, $aspx_import)) and
(
(2 of ($x*)) or
(2 of ($k*))
)
}
Sigma
title: SharePoint Worker Process (w3wp.exe) Spawning Command Shell - CVE-2026-58644 Post-Exploitation
id: 7b3f2c1a-9d4e-4a86-bf21-2c5a7e0d61f4
status: experimental
description: >
Detects the SharePoint IIS application pool worker process w3wp.exe spawning a command
interpreter (cmd.exe / powershell.exe / pwsh.exe). SharePoint's worker process should
not normally launch a shell; this behavior is a high-fidelity indicator of successful
exploitation of an unauthenticated SharePoint deserialization RCE (CVE-2026-58644) and
subsequent web-shell / hands-on-keyboard activity. AI-generated starter rule - validate
before deploying.
author: CVE Brief
date: 2026/07/17
tags:
- attack.execution
- attack.t1190
- attack.t1505.003
- attack.t1059.001
logsource:
product: windows
category: process_creation
detection:
selection_parent:
ParentImage|endswith: '\w3wp.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
condition: selection_parent and selection_child
falsepositives:
- Legitimate SharePoint timer jobs, provisioning, or admin PowerShell tasks invoked through the web front end (rare; baseline before enabling)
- Monitoring or backup agents that shell out from IIS worker processes
- Custom SharePoint solutions that legitimately spawn processes
level: high
Rule notes
The Sigma rule keys on w3wp.exe spawning a command interpreter, a behavior near-absent in normal SharePoint operation and the strongest post-exploitation signal across public SharePoint RCE writeups; baseline legitimate admin and timer-job shell activity before enabling. The YARA rule is a generic ASPX web-shell and machine-key-dumper heuristic meant to scan the SharePoint LAYOUTS directories; because it is behavioral rather than hash-based it can flag benign admin .aspx pages, so treat hits as triage leads, not confirmed compromise.
References