Vulnerability Analysis

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

Executive Summary

CVE-2026-58644 is a critical unauthenticated remote code execution vulnerability (CVSS 9.8) in on-premises Microsoft SharePoint Server, caused by unsafe deserialization of untrusted data. Patched on July 14, 2026, as part of Patch Tuesday, it was confirmed exploited in the wild the following day and added to CISA's Known Exploited Vulnerabilities (KEV) catalog on July 16 — with federal agencies ordered to remediate by July 19. Any organization running on-premises SharePoint should treat this as an emergency.

1. What Is This Vulnerability?

CVE-2026-58644 stems from SharePoint Server's improper handling of serialized objects received over the network (CWE-502: Deserialization of Untrusted Data). When a client sends a serialized payload to certain SharePoint endpoints, the server reconstructs the object graph without adequate validation. An attacker can craft a malicious serialized payload that, when deserialized by the server process, causes arbitrary code execution — with no authentication required.

This is the classic "gadget chain" exploitation pattern: serialized .NET objects carry references to classes already loaded in the process that, when instantiated in the wrong order, invoke OS-level commands.

Attack Vector

  1. Attacker identifies a SharePoint Server exposed to the network (or internet).
  2. Attacker crafts a malicious serialized .NET payload using known gadget chains (e.g., via ysoserial.net).
  3. Payload is delivered as an HTTP POST to a vulnerable SharePoint endpoint — no credentials needed.
  4. SharePoint deserializes the payload, executing attacker-controlled code under the IIS worker process (w3wp.exe).
  5. Attacker achieves SYSTEM-level access on the host.

Real-World Impact

CISA confirmed active exploitation of CVE-2026-58644 as part of a broader SharePoint attack campaign (alongside CVE-2026-32201, CVE-2026-45659, and CVE-2026-56164). Observed post-exploitation activity includes:

  • IIS machine key theft — attackers extract machineKey, validationKey, and decryptionKey values from IIS configuration, enabling persistent forged ViewState attacks even after patching.
  • Persistence via deserialization backdoors — malicious modules registered in IIS pipeline.
  • Lateral movement — using stolen credentials and tokens cached on the SharePoint host.
  • Malware deployment — web shells, remote access trojans, and credential harvesters dropped to the server filesystem.

2. Who Is Affected?

All supported on-premises SharePoint Server versions are vulnerable:

Product Affected
Microsoft SharePoint Enterprise Server 2016 ✅ Yes
Microsoft SharePoint Server 2019 ✅ Yes
Microsoft SharePoint Server Subscription Edition ✅ Yes
Microsoft SharePoint Online (Microsoft 365) ❌ No — cloud-hosted instances are not affected

Configuration risk factors:

  • SharePoint servers directly exposed to the internet face the highest risk.
  • Even intranet-only deployments are vulnerable if an attacker has any foothold on the network.
  • AMSI integration disabled or set to Off / RequestBody (not Full) removes a key detection layer.

3. How to Detect It (Testing)

Manual Testing Steps

Step 1 — Confirm SharePoint version

On the server, open SharePoint Central Administration → Upgrade and Migration → Review database and farm upgrade status

Or check via PowerShell:

(Get-SPFarm).BuildVersion

Compare against patched build numbers in Microsoft's advisory.

Step 2 — Check AMSI configuration

Get-SPWebApplication | ForEach-Object {
    Write-Host $_.Url
    $_.AMSIEnabled
    $_.AMSIScanLevel
}

Expected secure output: AMSIEnabled = True, AMSIScanLevel = Full

Step 3 — Review IIS logs for suspicious POST patterns

Look in C:\inetpub\logs\LogFiles\W3SVC* for:

  • Unusually large POST bodies to /_vti_bin/ endpoints
  • HTTP 200 responses to requests with content types of application/octet-stream or application/x-www-form-urlencoded that don't match normal SharePoint usage patterns
  • Requests from external IPs to internal SharePoint API endpoints

Step 4 — Check for IIS machine key exposure

# Search for machineKey presence in applicationHost.config and web.configs
Get-ChildItem -Path "C:\Windows\System32\inetsrv\" -Recurse -Filter "applicationHost.config" |
    Select-String -Pattern "machineKey|validationKey|decryptionKey"

Any result here means keys may already be known to attackers and must be rotated.

Step 5 — Hunt for web shells

# Search for recently modified .aspx files in SharePoint directories
Get-ChildItem -Path "C:\inetpub\wwwroot\wss\" -Recurse -Filter "*.aspx" |
    Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) } |
    Select-Object FullName, LastWriteTime

Automated Scanning

Tool: Tenable Nessus / InsightVM / Nexpose

  • Authenticated check for CVE-2026-58644 is available as of the July 14, 2026 content release.
  • Run a credentialed scan against all SharePoint servers and filter for Plugin ID matching CVE-2026-58644.

Tool: Microsoft Defender for Endpoint

  • Look for the following AMSI detections in the Defender portal:
    • Exploit:Script/SuspSignoutReqBody.A — POST body scanning (Subscription Edition)
    • Exploit:Script/ToolPaneAuthBypass.A — Request header scanning (all versions)
    • Exploit:Script/ToolPaneAuthBypass — General pattern (all versions)

Tool: Sysinternals / Process Monitor

Filter: Process Name = w3wp.exe AND Operation = Process Create

Legitimate SharePoint shouldn't spawn child processes like cmd.exe, powershell.exe, or mshta.exe.

Code Review Checklist

If you maintain custom SharePoint solutions:

  • Avoid using BinaryFormatter, NetDataContractSerializer, or ObjectStateFormatter for untrusted input
  • Use JsonSerializer or XmlSerializer with strict type allowlisting
  • Validate and sanitize all HTTP POST body content before processing
  • Ensure ViewState is MAC-validated and that machine keys are stored securely (not in web.config in plaintext)
  • Confirm that custom ISAPI filters and HTTP modules don't introduce additional deserialization paths

4. How to Fix It (Mitigation)

Step-by-Step Remediation

Priority 1: Apply the July 2026 Patch Tuesday updates immediately.

  1. Download updates from the Microsoft Update Catalog for your SharePoint version:

    • SharePoint Server Subscription Edition: KB article linked in MSRC advisory
    • SharePoint Server 2019: KB article linked in MSRC advisory
    • SharePoint Server 2016: KB article linked in MSRC advisory

  2. Apply updates in the correct order — SharePoint updates often have prerequisites (language packs, cumulative updates). Follow Microsoft's documented update order.

  3. Run the SharePoint Products Configuration Wizard (or psconfig.exe) on every server in the farm after patching:

    PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures

  4. Verify patch application:

    (Get-SPFarm).BuildVersion

    Confirm the build number matches the patched release in the MSRC advisory.

  5. Enable AMSI in Full Mode on all SharePoint web applications (see Configuration Hardening below).

  6. Rotate IIS machine keys (see below) — assume keys may already be compromised.

Code Fix Example

If using custom .NET code that deserializes SharePoint data:

Before (vulnerable):

// UNSAFE: BinaryFormatter deserializes arbitrary types
var formatter = new BinaryFormatter();
object result = formatter.Deserialize(inputStream);

After (safe):

// SAFE: Use JSON with explicit type handling
var options = new JsonSerializerOptions
{
    PropertyNameCaseInsensitive = true
};
MyExpectedType result = JsonSerializer.Deserialize<MyExpectedType>(inputStream, options);

Configuration Hardening

Enable AMSI integration in Full mode:

# Enable AMSI for all web applications
$webApps = Get-SPWebApplication
foreach ($webApp in $webApps) {
    $webApp.AMSIEnabled = $true
    $webApp.AMSIScanLevel = [Microsoft.SharePoint.Administration.SPAMSIScanLevel]::Full
    $webApp.Update()
    Write-Host "AMSI enabled on: $($webApp.Url)"
}

# Apply changes via IIS reset
iisreset /noforce

Rotate IIS machine keys (critical if compromise is suspected):

# Generate new machine key values
$rng = [System.Security.Cryptography.RNGCryptoServiceProvider]::new()
$validationKey = New-Object Byte[] 64
$decryptionKey = New-Object Byte[] 32
$rng.GetBytes($validationKey)
$rng.GetBytes($decryptionKey)

$validationKeyHex = [BitConverter]::ToString($validationKey) -replace '-',''
$decryptionKeyHex = [BitConverter]::ToString($decryptionKey) -replace '-',''

Write-Host "New validationKey: $validationKeyHex"
Write-Host "New decryptionKey: $decryptionKeyHex"
# Apply these in IIS Manager → Machine Key settings for each application pool

Reduce internet exposure:

  • Place SharePoint behind a Web Application Firewall (WAF) or reverse proxy.
  • Block direct internet access to SharePoint if not required.
  • Restrict access to /_vti_bin/, /sites/, and API endpoints by IP allowlist where possible.

5. How to Test the Fix (Validation)

Regression Test Scenarios

  • Scenario A: After patching, re-scan with Nessus/InsightVM — CVE-2026-58644 check should return no findings.
  • Scenario B: Confirm normal SharePoint functionality (document upload, site navigation, search) works correctly post-patch.
  • Scenario C: Verify AMSI detections are active by reviewing Defender portal — alerts should appear if test payloads are blocked.
  • Scenario D: Confirm IIS machine key rotation did not break existing sessions/ViewState for legitimate users.

Security Test Cases

Test Case 1: Verify patch is applied

  • Precondition: July 14, 2026 patch applied and PSConfig completed
  • Steps: Run (Get-SPFarm).BuildVersion and compare to patched build in MSRC advisory
  • Expected Result: Build version matches patched release

Test Case 2: Verify AMSI is blocking malicious payloads

  • Precondition: AMSI enabled in Full mode
  • Steps: Monitor Defender for Endpoint for Exploit:Script/ToolPaneAuthBypass.A detections when a security researcher tests with PoC payload in a controlled lab environment
  • Expected Result: Detection fires, request is blocked with HTTP 400/403

Test Case 3: Verify no web shells present

  • Precondition: Post-patch and post-investigation
  • Steps: Run file system sweep for recently modified .aspx files in SharePoint directories
  • Expected Result: No unexpected .aspx modifications in the past 30+ days

Automated Tests

# SharePoint patch validation script
$requiredBuildVersion = "16.0.X.XXXX" # Replace with patched build from MSRC advisory

$currentBuild = (Get-SPFarm).BuildVersion.ToString()
if ($currentBuild -ge $requiredBuildVersion) {
    Write-Host "[PASS] SharePoint build $currentBuild is patched" -ForegroundColor Green
} else {
    Write-Host "[FAIL] SharePoint build $currentBuild is VULNERABLE — patch immediately" -ForegroundColor Red
}

# AMSI validation
$webApps = Get-SPWebApplication
foreach ($webApp in $webApps) {
    if ($webApp.AMSIEnabled -and $webApp.AMSIScanLevel -eq "Full") {
        Write-Host "[PASS] AMSI Full mode active on $($webApp.Url)" -ForegroundColor Green
    } else {
        Write-Host "[FAIL] AMSI not in Full mode on $($webApp.Url)" -ForegroundColor Red
    }
}

6. Prevention & Hardening

Best Practices

  • Patch cadence: Subscribe to Microsoft Security Response Center (MSRC) notifications and treat Patch Tuesday SharePoint updates as priority-1 deployments.
  • Minimize attack surface: Avoid exposing on-premises SharePoint directly to the internet. If external access is required, use a reverse proxy or zero-trust access gateway.
  • Disable legacy serialization: Audit custom solutions for use of BinaryFormatter, SoapFormatter, or LosFormatter and replace with safe alternatives.
  • Principle of least privilege: Run SharePoint application pools under dedicated low-privilege service accounts, not SYSTEM or domain admins.
  • IIS hardening: Remove unused HTTP handlers and modules. Restrict the /_vti_bin/ endpoint to known-good IP ranges.
  • Regular security scanning: Run credentialed vulnerability scans against SharePoint monthly at minimum, or after every Patch Tuesday.
  • Maintain a SharePoint inventory: Know which SharePoint versions and patch levels are deployed across your environment at all times.

Monitoring & Detection

Key log sources to monitor:

Source What to Look For
IIS Access Logs (W3SVC*) Unusually large POST bodies, unexpected 200 responses to /_api/ endpoints
SharePoint ULS Logs Deserialization exceptions, authentication bypass indicators
Windows Event Log (Security) Unexpected process spawns from w3wp.exe (Event 4688)
PowerShell Script Block Logging (Event 4104) PowerShell activity originating from IIS worker processes
Microsoft Defender Alerts Exploit:Script/SuspSignoutReqBody.A, Exploit:Script/ToolPaneAuthBypass.A
File System Unexpected .aspx or .ashx files created in SharePoint directories

SIEM Detection Rule (pseudo-logic):

ALERT when:
  process.name == "w3wp.exe"
  AND process.parent.name IN ["cmd.exe", "powershell.exe", "mshta.exe", "wscript.exe"]
  AND NOT process.command_line CONTAINS [known-good SharePoint maintenance patterns]

Incident response trigger: If you detect machineKey, validationKey, or decryptionKey values being read or transmitted by any process other than the IIS worker, assume full compromise — rotate all keys, initiate IR procedures, and audit all SharePoint-hosted content for web shells.

References

Latest from the blog

See all →