Am I vulnerable?
CVE-2026-45659 affects on-premises Microsoft SharePoint Server only. SharePoint Online (Microsoft 365) is not in scope. A server is vulnerable if its farm build is below the May 2026 fixed build for its SKU.
Affected versions
| Product |
Vulnerable range |
Fixed build (KB) |
| SharePoint Server Subscription Edition |
prior to 16.0.19725.20280 |
16.0.19725.20280 (KB5002863) |
| SharePoint Server 2019 |
prior to 16.0.10417.20128 |
16.0.10417.20128 (KB5002870) |
| SharePoint Enterprise Server 2016 |
prior to 16.0.5552.1002 |
16.0.5552.1002 (KB5002868) |
Diagnostic checks
Run these read-only commands from the SharePoint Management Shell on a farm server:
- Farm build:
(Get-SPFarm).BuildVersion. Vulnerable if the build is below the fixed build for your SKU (Subscription Edition < 16.0.19725.20280, 2019 < 16.0.10417.20128, 2016 < 16.0.5552.1002).
- Per-node patch level:
Get-SPProduct -Local | Format-List ProductName, PatchableUnitDisplayName, PatchableUnitVersion. Any PatchableUnitVersion below the May 2026 build means that node has not been updated — build version is farm-wide, but the update must be installed and the config wizard run on every server.
- KB presence:
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object InstalledOn, HotFixID, Description. Absence of KB5002863 / KB5002870 / KB5002868 (or later) is consistent with an unpatched host.
"Vulnerable" here means an unpatched farm reachable by any account holding at least Site Member permissions — the exploit needs low-privilege authentication, not admin. Installing the update on some but not all farm nodes leaves the farm exposed until the configuration wizard has run everywhere.
Vulnerability
CVE-2026-45659 is a deserialization of untrusted data flaw — CWE-502 per NVD — in on-premises SharePoint Server. SharePoint reconstructs .NET objects from attacker-influenced input without adequately constraining the types it will materialize, so a crafted request drives the deserializer into instantiating a gadget chain that ends in arbitrary code execution. The code runs in the context of the SharePoint application-pool identity (the w3wp.exe IIS worker process).
NVD scores it CVSS 8.8 with vector CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H. The vector is the operationally important part: network-reachable (AV:N), low complexity (AC:L), no user interaction (UI:N), and low privileges required (PR:L) — a standard Site Member account is enough. It is not a fully unauthenticated bug, but on internet-facing farms the authentication bar is routinely cleared with stolen, phished, or purchased credentials, or by chaining a separate access flaw. Microsoft's Exploitability Assessment rated in-the-wild abuse "Less Likely," yet CISA added the CVE to KEV on confirmed active exploitation weeks after the May 2026 patch — treat the KEV listing, not the vendor forecast, as the operative signal.
This bug class sits in the same family as the 2025 "ToolShell" SharePoint deserialization/ViewState RCE chain, and the detection signals below draw on that campaign's observed tradecraft.
Threat model
Who would exploit this: The most likely operators are financially motivated criminal groups — initial-access brokers and ransomware affiliates — who prioritize internet-reachable SharePoint because it sits inside the corporate perimeter and frequently runs under high-privilege service accounts. Because exploitation needs only a low-privilege Site Member account, actors who already hold stolen, phished, or purchased credentials (or who chain this with a separate access flaw) are best positioned. State-aligned actors are plausible for espionage given SharePoint's role as a document repository, but no primary source attributes this specific CVE to any named group.
What they're after:
- Foothold and RCE on the SharePoint server as the service account
- Persistence via remote-access tooling and newly created admin accounts
- Privilege escalation to local or domain administrator
- Lateral movement into the wider Windows/AD estate and the SQL back-end
- Data exfiltration of stored documents (PII, IP, embedded credentials)
- Ransomware staging or deployment
Attack chain: An attacker reaches an internet-facing SharePoint server and, using a low-privilege authenticated account, sends a crafted request that triggers unsafe deserialization, yielding code execution as the SharePoint service account. In observed SharePoint intrusions, operators then install legitimate remote-management and tunneling tools for persistence and create new local or domain administrator accounts to retain access, before pivoting toward directory services and back-end databases.
Blast radius: Because SharePoint commonly runs under privileged service accounts and holds machine keys, a compromised on-prem server can expose Active Directory credentials, the SharePoint SQL back-end, and every document stored in the farm. Theft of the ASP.NET machine keys is especially damaging: it lets an attacker forge valid __VIEWSTATE payloads and re-enter even after a patch, which is why key rotation is part of the official remediation. Escalation to domain administrator turns one exposed collaboration server into a launch point for estate-wide lateral movement, data theft, and ransomware.
Mitigation
Patch
Apply the May 2026 security updates (released May 12, 2026) to every farm node, then run the SharePoint Products Configuration Wizard and perform an IIS reset on each server. Per-SKU fixed builds:
| Product |
Fixed build |
KB |
| SharePoint Server Subscription Edition |
16.0.19725.20280 |
KB5002863 |
| SharePoint Server 2019 |
16.0.10417.20128 |
KB5002870 |
| SharePoint Enterprise Server 2016 |
16.0.5552.1002 |
KB5002868 |
After patching, rotate the SharePoint ASP.NET machine keys and restart IIS — a pre-patch compromise may already have exfiltrated the keys, and rotation is required to invalidate forged ViewState. Farms already on the May 2026 updates need no further action for this CVE.
Configuration mitigation
If patching cannot be completed immediately, enable AMSI integration so request payloads are inspected before SharePoint deserializes them. AMSI is a mitigation layer, not a substitute for the update.
Enable the AMSI integration feature for a SharePoint web application:
Enable-SPFeature -Identity 4cf046f3-38c7-495f-a7da-a1292d32e8e9 -Url <web application URL>
Set the AMSI request-body scan mode to Full (Subscription Edition 25H1+):
$webApp = Get-SPWebApplication -Identity "http://spwfe"
$webApp.AMSIBodyScanMode = 2 # 0 = Off, 1 = Balanced, 2 = Full
$webApp.Update()
AMSI integration is enabled by default since the September 2023 updates and mandatory from the September 2025 PU; Full/Balanced body-scan mode is available on Subscription Edition 25H1 and later. Pair it with Microsoft Defender Antivirus (or another AMSI-capable AV) and Defender for Endpoint.
Compensating controls
- Remove internet exposure. On-prem SharePoint should sit behind a VPN or reverse proxy with authentication enforced at the edge, not published directly to the internet. This alone blunts opportunistic mass-scanning.
- Constrain the service account. Run the application pool under a least-privilege account; avoid domain-admin-equivalent service accounts so a
w3wp.exe compromise does not immediately yield the domain.
- Segment the farm. Isolate SharePoint web front-ends and the SQL back-end so a foothold cannot pivot freely to directory services or databases.
- Monitor for the post-exploitation deltas below — new admin accounts, remote-management tooling, and
w3wp.exe child processes — as a backstop while patching completes.
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
w3wp.exe (SharePoint IIS worker process) spawning cmd.exe or powershell.exe — especially the chain w3wp.exe → cmd.exe /c → powershell.exe -EncodedCommand, which is not normal on a SharePoint host.
- New or modified
.aspx files written under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS (or ...\15\...), particularly spinstall-family filenames (spinstall0.aspx, spinstall.aspx, and variants).
- IIS log: anomalous POST requests to
/_layouts/15/ToolPane.aspx?DisplayMode=Edit carrying an HTTP Referer of /_layouts/SignOut.aspx — a signature of the ToolShell auth-bypass pattern.
__VIEWSTATE / ViewState deserialization abuse: large or malformed __VIEWSTATE POST parameters processed without a valid MAC, or requests crafted after machine-key theft to forge valid ViewState.
- Requests to attacker-dropped
.aspx endpoints returning MachineKey / ValidationKey / DecryptionKey material (post-exploit key exfiltration).
- Unexpected outbound connections from the SharePoint server to unfamiliar external IPs immediately after
ToolPane.aspx activity (possible C2 or key exfil callback).
- New
.aspx files under inetpub\wwwroot\wss\VirtualDirectories that did not ship with SharePoint.
YARA
rule CVE_2026_45659_SharePoint_Deserialization_Webshell_starter
{
meta:
author = "CVE Brief - Detection Engineering (AI-generated starter rule)"
description = "AI-generated starter rule - validate in your environment before deploying. Heuristic detection of suspicious .aspx webshell / ViewState-deserialization artifacts associated with SharePoint RCE exploitation (CVE-2026-45659, ToolShell-style)."
reference = "https://www.microsoft.com/en-us/security/blog/2025/07/22/disrupting-active-exploitation-of-on-premises-sharepoint-vulnerabilities/"
cve = "CVE-2026-45659"
confidence = "medium"
date = "2026-07-06"
strings:
// ASP.NET webshell scaffolding commonly seen in dropped .aspx files
$aspx1 = "<%@ Page Language=\"C#\"" ascii nocase
$aspx2 = "<%@ Page Language=\"Jscript\"" ascii nocase
// MachineKey / ValidationKey theft strings (post-exploit key exfil)
$key1 = "MachineKeySection" ascii nocase
$key2 = "ValidationKey" ascii nocase
$key3 = "DecryptionKey" ascii nocase
$key4 = "GetApplicationConfig" ascii nocase
// Generic .aspx webshell / command-exec markers
$sh1 = "System.Diagnostics.Process" ascii nocase
$sh2 = "ProcessStartInfo" ascii nocase
$sh3 = "cmd.exe /c" ascii nocase
$sh4 = "eval(Request" ascii nocase
$sh5 = "Request.Form" ascii nocase
$sh6 = "Response.Write" ascii nocase
// ToolShell-style artifact naming
$ts1 = "spinstall" ascii nocase
$ts2 = "ToolPane.aspx" ascii nocase
// ViewState deserialization gadget markers
$gad1 = "__VIEWSTATE" ascii
$gad2 = "LosFormatter" ascii nocase
$gad3 = "ObjectStateFormatter" ascii nocase
$gad4 = "TypeConfuseDelegate" ascii nocase
condition:
// .aspx page context plus either key-theft behavior, webshell command exec,
// known ToolShell naming, or a ViewState gadget marker
(any of ($aspx*)) and
(
(2 of ($key*)) or
(2 of ($sh*)) or
(any of ($ts*)) or
(any of ($gad2, $gad3, $gad4))
)
}
Sigma
title: SharePoint IIS Worker Process (w3wp.exe) Spawning Command Shell - Possible Deserialization RCE
id: 8f3c2a1e-4d6b-4e9a-9c7f-2b5a1d6e0f34
status: experimental
description: >
AI-generated starter rule - validate in your environment before deploying.
Detects the SharePoint IIS worker process w3wp.exe spawning a command
interpreter (cmd.exe, powershell.exe, pwsh.exe) or other living-off-the-land
binaries. On a SharePoint server this child-process pattern is a strong
indicator of exploitation of an insecure deserialization / ViewState RCE
(CVE-2026-45659, ToolShell-style), where attacker code runs in the context of
the SharePoint application pool.
references:
- https://www.microsoft.com/en-us/security/blog/2025/07/22/disrupting-active-exploitation-of-on-premises-sharepoint-vulnerabilities/
- https://www.cisa.gov/news-events/analysis-reports/ar25-218a
author: CVE Brief - Detection Engineering
date: 2026-07-06
tags:
- attack.execution
- attack.t1190
- attack.t1505.003
- attack.t1059.001
- attack.t1059.003
logsource:
product: windows
category: process_creation
detection:
selection_parent:
ParentImage|endswith: '\w3wp.exe'
selection_child:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\csc.exe'
- '\vbc.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\net.exe'
- '\whoami.exe'
condition: selection_parent and selection_child
falsepositives:
- Legitimate SharePoint timer jobs, custom web parts, or administrative/deployment scripts that shell out from the application pool identity
- Monitoring or backup agents that spawn processes under w3wp.exe
- PowerShell-based health checks or STSADM/PSConfig operations coinciding with the worker process
level: high
Rule notes
The YARA rule is a heuristic on dropped .aspx artifacts (webshell scaffolding plus MachineKey theft, ToolShell naming, or ViewState gadget markers) and will need tuning against benign custom SharePoint pages. The Sigma rule reliably flags the abnormal w3wp.exe → shell/LOLBin child-process chain that characterizes SharePoint deserialization RCE, but legitimate SharePoint jobs and deployment scripts can shell out from the application pool — pair it with the network/IIS signals (ToolPane.aspx + SignOut.aspx Referer) to confirm before escalating.
References