Vulnerability Analysis

CVE-2026-45659: Microsoft SharePoint Server Deserialization RCE — What It Is & How to Fix It

Executive Summary

CVE-2026-45659 is a high-severity remote code execution (RCE) vulnerability in Microsoft SharePoint Server caused by unsafe deserialization of attacker-controlled data. An authenticated attacker holding only Site Member permissions can execute arbitrary code on the server — no administrator privileges or user interaction required. Microsoft patched the flaw in May 2026, and organizations with on-premises SharePoint deployments should apply the update immediately given SharePoint's history as a high-value target for ransomware operators and nation-state actors.

1. What Is This Vulnerability?

Root Cause

CVE-2026-45659 is a deserialization of untrusted data vulnerability in Microsoft Office SharePoint. Deserialization is the process of converting a byte stream back into an in-memory object. When an application deserializes data that has been tampered with by an attacker, it can trigger unintended code paths — up to and including arbitrary code execution.

In SharePoint's case, the server processes serialized payloads sent from authenticated clients. Without sufficient validation or type restriction around deserialization, an attacker can craft a malicious payload using a "gadget chain" — a sequence of existing .NET classes whose methods, when chained together, execute OS-level commands.

Conceptual Attack Payload (Simplified .NET Gadget Chain)

// Attacker constructs a BinaryFormatter gadget chain targeting
// a dangerous class such as ObjectDataProvider or WindowsIdentity

// Pseudocode for crafting a serialized payload:
var payload = GadgetBuilder
    .New()
    .WithGadget("ObjectDataProvider")
    .Execute("cmd.exe /c whoami > C:\\inetpub\\wwwroot\\sharepoint\\out.txt")
    .Serialize(SerializationFormat.BinaryFormatter);

// Payload is embedded in an HTTP request to a vulnerable SharePoint endpoint
POST /_api/web/webinfos HTTP/1.1
Host: sharepoint.target.corp
Authorization: Bearer <valid_site_member_token>
Content-Type: application/json

{ "metadata": "<serialized_gadget_chain_base64>" }

Microsoft's CVSS assessment confirms:

  • Attack Vector: Network
  • Attack Complexity: Low
  • Privileges Required: Low (Site Member)
  • User Interaction: None
  • Scope: Changed
  • Confidentiality / Integrity / Availability Impact: High / High / High

Attack Vector

A typical exploitation flow looks like this:

  1. Credential acquisition — Attacker obtains a valid SharePoint user account via phishing, credential stuffing, or by purchasing access from an initial access broker.
  2. Payload crafting — Attacker serializes a malicious .NET object (gadget chain) targeting a dangerous class loaded in the SharePoint AppDomain.
  3. Request submission — Attacker sends the payload to a vulnerable SharePoint API or page endpoint that deserializes the input without proper type-checking.
  4. Code execution — SharePoint's worker process (w3wp.exe) deserializes the payload, triggering the gadget chain and executing attacker-supplied commands as the SharePoint service account (often NT AUTHORITY\NETWORK SERVICE or a domain service account).
  5. Post-exploitation — Attacker drops a web shell (.aspx file), exfiltrates MachineKey / DecryptionKey values from SharePoint's web.config, establishes persistence, or pivots laterally using the server's internal network position.

Common Post-Exploitation Artifact

C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\spinstall0.aspx

This ASPX web shell pattern has been observed in prior SharePoint RCE campaigns and allows the attacker to run commands via a simple HTTP GET request.

Real-World Impact

SharePoint has been targeted in multiple high-profile incidents:

  • STORM-2603 / ransomware operators abused SharePoint deserialization flaws in 2025 to deploy ransomware across enterprise environments, per Microsoft Threat Intelligence reporting.
  • Nation-state actors (including groups attributed to China and Russia) have repeatedly exploited SharePoint RCE vulnerabilities discovered in 2023–2026 as initial footholds into corporate and government networks.
  • Initial access brokers actively sell SharePoint sessions and credentials on underground markets, making low-privilege requirements particularly dangerous.

2. Who Is Affected?

Product Fixed Build Number
SharePoint Server Subscription Edition 16.0.19725.20280 or later
SharePoint Server 2019 16.0.10417.20128 or later
SharePoint Enterprise Server 2016 16.0.5552.1002 or later

SharePoint Online (Microsoft 365) is NOT affected — Microsoft manages patching for cloud instances. This vulnerability only impacts on-premises deployments.

High-risk configurations:

  • SharePoint servers accessible from the internet (extranet, partner portals, public intranets)
  • Environments without MFA enforced for SharePoint access
  • Sites with broad Site Member permissions (e.g., "all authenticated users")
  • SharePoint instances integrated with Active Directory where a single compromised AD account could provide access

3. How to Detect It (Testing)

Manual Testing Steps

Step 1 — Identify your SharePoint build number

Navigate to SharePoint Central Administration:

Central Administration > Upgrade and Migration > Review database status

Or check via PowerShell (on the SharePoint server):

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
(Get-SPFarm).BuildVersion

Compare the output against the fixed build numbers in the table above.

Step 2 — Check the patch installation date

Get-HotFix | Where-Object { $_.Description -eq "Security Update" } |
    Sort-Object InstalledOn -Descending |
    Select-Object -First 20 |
    Format-Table HotFixID, InstalledOn, InstalledBy

Look for the May 2026 Cumulative Update for your SharePoint version (KB articles listed in the References section).

Step 3 — Verify deserialization endpoint exposure

From an external or segmented network perspective, check whether SharePoint API endpoints respond to unauthenticated requests. Authenticated deserialization flaws still require network reachability:

# Check if SharePoint REST API is accessible
curl -s -o /dev/null -w "%{http_code}" \
  https://sharepoint.example.com/_api/web/title

# 401 = reachable but requires auth (still exploitable with valid creds)
# 403 = may have additional access controls
# Connection refused = network-layer protection in place

Step 4 — Hunt for web shell artifacts

On the SharePoint server, check for unexpected ASPX files in layout directories:

# Search for recently created or modified ASPX files
Get-ChildItem -Path "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\" `
    -Recurse -Filter "*.aspx" |
    Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) } |
    Select-Object FullName, LastWriteTime, Length |
    Sort-Object LastWriteTime -Descending

Suspicious filenames to watch for: spinstall0.aspx, random-named .aspx files, files with .aspx.bak double extensions.

Automated Scanning

Tool: Nessus / Tenable

  • Plugin ID search: "SharePoint" + "deserialization" or CVE-2026-45659
  • Scan type: Credentialed patch audit
  • Configuration: Provide a Windows service account with access to the SharePoint server for registry/file-based build number checks

Tool: Qualys

  • QID: Search for CVE-2026-45659 in Qualys VM
  • Run authenticated scan against SharePoint server
  • Expected result: CVSS 8.8 finding flagged if build is unpatched

Tool: Microsoft Defender for Endpoint

// KQL query for MDE — detect suspicious SharePoint worker process activity
DeviceProcessEvents
| where InitiatingProcessFileName == "w3wp.exe"
| where ProcessCommandLine contains "cmd.exe"
    or ProcessCommandLine contains "powershell"
    or ProcessCommandLine contains "certutil"
| where FolderPath contains "SharePoint"
| project Timestamp, DeviceName, InitiatingProcessFileName, 
          ProcessCommandLine, AccountName
| order by Timestamp desc

Tool: OWASP ZAP / Burp Suite (for API fuzzing)

  • Intercept serialized requests to /_api/ endpoints
  • Use Ysoserial.NET to generate test gadget chains
  • Note: Only perform against systems you own and have explicit authorization to test

Code Review Checklist

For organizations that have customized SharePoint or built SharePoint solutions:

  • Audit all uses of BinaryFormatter, NetDataContractSerializer, and LosFormatter in custom SharePoint code
  • Verify that TypeNameHandling in Newtonsoft.Json is not set to All or Auto
  • Confirm that allowInsecureDeserializationBinderBypass is not enabled in web.config
  • Check for any custom HTTP modules or handlers that process serialized input
  • Review all API controllers that accept application/octet-stream or base64-encoded parameters

4. How to Fix It (Mitigation)

Step-by-Step Remediation

1. Determine current SharePoint build version (see above)

2. Download the appropriate update from Microsoft Update Catalog

Product KB Article Download
SharePoint Server Subscription Edition KB5002700 (May 2026 CU) Microsoft Update Catalog
SharePoint Server 2019 KB5002701 (May 2026 CU) Microsoft Update Catalog
SharePoint Enterprise Server 2016 KB5002685 (May 2026 CU) Microsoft Update Catalog

Note: Microsoft confirmed that CVE-2026-45659 was inadvertently omitted from the original May 2026 Patch Tuesday release notes but is included in those updates. Organizations that installed the May 2026 CU are already protected.

3. Stage the update in a test environment first

# On SharePoint server — run as administrator
# Mount the update package
$updatePath = "C:\Updates\sts2019-kb5002701-fullfile-x64.exe"

# Execute the installer
Start-Process -FilePath $updatePath -ArgumentList "/quiet /norestart" -Wait

# Verify the update installed
Get-HotFix -Id KB5002701

4. Run the SharePoint Products Configuration Wizard

After applying the binary patch, the configuration wizard must run on every server in the farm:

# Run PSConfig to complete the upgrade
& "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\BIN\PSConfig.exe" `
    -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install `
    -cmd installfeatures -cmd secureresources -cmd services -install

5. Verify the updated build number

Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
(Get-SPFarm).BuildVersion
# Should show 16.0.10417.20128 or higher (SP 2019)

6. Repeat on all servers in the farm (front-end web servers, application servers, and search servers).

Code Fix Example

If you have custom SharePoint code using unsafe deserialization, replace it:

Before (vulnerable):

// DO NOT USE — BinaryFormatter is dangerous with untrusted input
var formatter = new BinaryFormatter();
using (var ms = new MemoryStream(requestBody))
{
    var result = formatter.Deserialize(ms); // ← VULNERABLE
}

After (safe):

// Use a type-safe, contract-based serializer
using System.Text.Json;

var options = new JsonSerializerOptions
{
    PropertyNameCaseInsensitive = true
};
// Only deserialize to known, expected types
var result = JsonSerializer.Deserialize<MyExpectedType>(requestBody, options);

For scenarios requiring binary serialization:

// Use DataContractSerializer with known types only
var knownTypes = new List<Type> { typeof(MyExpectedType) };
var serializer = new DataContractSerializer(typeof(MyExpectedType), knownTypes);
using (var ms = new MemoryStream(requestBody))
{
    var result = (MyExpectedType)serializer.ReadObject(ms);
}

Configuration Hardening

Restrict SharePoint to internal networks only (if extranet access is not required):

# Windows Firewall — restrict SharePoint ports to internal subnets
New-NetFirewallRule -DisplayName "SharePoint HTTPS Internal Only" `
    -Direction Inbound -Protocol TCP -LocalPort 443 `
    -RemoteAddress 10.0.0.0/8,172.16.0.0/12,192.168.0.0/16 `
    -Action Allow

Enforce MFA for SharePoint via Azure AD Conditional Access (for hybrid environments):

  • Navigate to Azure AD → Security → Conditional Access
  • Create a policy targeting SharePoint Online / on-prem via App Proxy
  • Require MFA for all users, including service accounts where possible

Reduce Site Member blast radius:

# Audit and remove stale Site Member permissions
Add-PSSnapin Microsoft.SharePoint.PowerShell
$web = Get-SPWeb "https://sharepoint.example.com/sites/targetsite"
$group = $web.SiteGroups["Team Site Members"]
$group.Users | ForEach-Object {
    Write-Host "$($_.Name) - $($_.Email) - Last Login: (check AD)"
}

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: Verify patched build number matches or exceeds the fixed build (16.0.10417.20128 for SP 2019, etc.)
  • Scenario B: Confirm all farm servers are at the patched build — a mixed-version farm is still vulnerable on unpatched nodes
  • Scenario C: Verify SharePoint functionality works post-patch (document libraries, search, workflows, custom solutions)
  • Scenario D: Confirm authentication and MFA enforcement is working correctly and users can still log in normally

Security Test Cases

Test Case 1: Verify patch is applied on all farm members

Add-PSSnapin Microsoft.SharePoint.PowerShell
$servers = Get-SPServer | Where-Object { $_.Role -ne "Invalid" }
foreach ($server in $servers) {
    $version = (Get-SPFarm).BuildVersion
    Write-Host "Server: $($server.Name) | Build: $version"
    if ([version]$version -lt [version]"16.0.10417.20128") {
        Write-Warning "UNPATCHED: $($server.Name)"
    } else {
        Write-Host "PATCHED: $($server.Name)" -ForegroundColor Green
    }
}

Test Case 2: Confirm no web shell artifacts are present

# Check layout directories for unexpected ASPX files (run on all WFE servers)
$suspiciousFiles = Get-ChildItem `
    -Path "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\" `
    -Recurse -Include "*.aspx" |
    Where-Object {
        $_.Name -match "^[a-f0-9]{8,}\.aspx$" -or  # Random hex filenames
        $_.Name -eq "spinstall0.aspx" -or
        $_.LastWriteTime -gt (Get-Date).AddDays(-60)
    }

if ($suspiciousFiles) {
    Write-Warning "SUSPICIOUS FILES FOUND:"
    $suspiciousFiles | Select-Object FullName, LastWriteTime
} else {
    Write-Host "No suspicious ASPX files detected." -ForegroundColor Green
}

Test Case 3: Validate that attack surface (authenticated API endpoints) requires MFA

Using a test account:

  1. Attempt to access https://sharepoint.example.com/_api/web/title without MFA
  2. Confirm the request is blocked or challenged with MFA prompt
  3. Log the test result in your remediation ticket

Automated Tests

# Pester test — SharePoint CVE-2026-45659 patch validation
Describe "CVE-2026-45659 Patch Validation" {

    BeforeAll {
        Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
        $minVersions = @{
            "SharePoint Server Subscription Edition" = [version]"16.0.19725.20280"
            "SharePoint Server 2019"                 = [version]"16.0.10417.20128"
            "SharePoint Enterprise Server 2016"      = [version]"16.0.5552.1002"
        }
    }

    It "Farm build version meets minimum patched version" {
        $currentBuild = (Get-SPFarm).BuildVersion
        $currentBuild | Should -Not -BeNullOrEmpty
        Write-Host "Detected build: $currentBuild"
        # Assert at least SP 2019 minimum (adjust for your version)
        [version]$currentBuild | Should -BeGreaterOrEqual ([version]"16.0.10417.20128")
    }

    It "No unexpected ASPX files in LAYOUTS directory" {
        $files = Get-ChildItem `
            "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS" `
            -Filter "*.aspx" |
            Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-60) }
        
        # Known legitimate files should be identified and allowlisted
        $suspicious = $files | Where-Object { $_.Name -eq "spinstall0.aspx" }
        $suspicious | Should -BeNullOrEmpty
    }

    It "SharePoint REST API requires authentication" {
        $response = Invoke-WebRequest `
            -Uri "https://localhost/_api/web/title" `
            -UseDefaultCredentials:$false `
            -ErrorAction SilentlyContinue
        
        $response.StatusCode | Should -Be 401
    }
}

6. Prevention & Hardening

Best Practices

Practice 1 — Patch on a defined SLA tied to severity

Establish a patch management SLA: CVSS 8.0+ vulnerabilities in internet-facing systems should be patched within 72 hours of a patch becoming available. CVE-2026-45659 qualifies.

Practice 2 — Enforce MFA for all SharePoint access

Since this vulnerability requires authentication, MFA dramatically raises the bar. An attacker with stolen credentials still cannot exploit the flaw if MFA is enforced.

Azure AD Conditional Access policy:
  Users: All users
  Cloud apps: SharePoint / Office 365 SharePoint Online
  Conditions: Any location
  Access controls: Require multi-factor authentication

Practice 3 — Apply least-privilege access controls

Audit and trim Site Member group membership quarterly. Use SharePoint's built-in "Check Permissions" tool to audit who can access sensitive sites.

Practice 4 — Disable legacy serialization in custom code

If your organization develops SharePoint solutions or SharePoint Framework (SPFx) web parts, enforce a no-BinaryFormatter policy in code review:

<!-- Add to build pipeline as a Roslyn analyzer rule -->
<PackageReference Include="Microsoft.AspNetCore.Analyzers" Version="*" />
<!-- Rule: CA2300 — Do not use BinaryFormatter -->

Practice 5 — Subscribe to Microsoft Security Response Center (MSRC) alerts

https://msrc.microsoft.com/update-guide/

Subscribe to the MSRC email digest to receive Patch Tuesday notifications immediately.

Monitoring & Detection

Windows Event Log — IIS / SharePoint:

Enable and monitor for deserialization-related exceptions in SharePoint ULS logs:

# Tail SharePoint ULS log for deserialization exceptions
$ulsPath = "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\LOGS"
Get-ChildItem $ulsPath -Filter "*.log" | Sort-Object LastWriteTime -Descending |
    Select-Object -First 1 | Get-Content -Tail 500 |
    Where-Object { $_ -match "Deserializ|BinaryFormatter|gadget|TypeName" }

Microsoft Sentinel / KQL — Detect SharePoint process spawning shells:

SecurityEvent
| where EventID == 4688  // Process creation
| where ParentProcessName endswith "w3wp.exe"
| where NewProcessName in~ (
    "cmd.exe", "powershell.exe", "powershell_ise.exe",
    "wscript.exe", "cscript.exe", "mshta.exe", "regsvr32.exe",
    "certutil.exe", "bitsadmin.exe", "net.exe", "net1.exe"
  )
| project TimeGenerated, Computer, Account, 
          ParentProcessName, NewProcessName, CommandLine
| order by TimeGenerated desc

File Integrity Monitoring:

Monitor the SharePoint LAYOUTS directory for new or modified ASPX files using tools like Wazuh, Tripwire, or Microsoft Defender for Endpoint's file monitoring capability:

Path: C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\
Alert on: New file creation, modifications to .aspx files
Severity: High

SIEM alert — Authentication anomaly preceding API access:

Flag accounts that:

  1. Authenticated from a new IP or geolocation
  2. Within 5 minutes accessed SharePoint REST API endpoints (/_api/, /_vti_bin/)
  3. Followed by a new process spawned by w3wp.exe

References

Latest from the blog

See all →