CVE-2026-58644 — Microsoft SharePoint Server Deserialization RCE

CVE-2026-58644 is a critical (CVSS 9.8) deserialization-of-untrusted-data vulnerability in on-premises Microsoft SharePoint Server 2016, 2019, and Subscription Edition, patched in the July 2026 "Patch Tuesday". Per Microsoft: "In a network-based attack, an attacker authenticated as at least a Site Owner could write arbitrary code to inject and execute code remotely on the SharePoint Server." Microsoft revised its bulletin to confirm exploitation in the wild — it was weaponized as a zero-day before patches shipped. CISA added it to the KEV catalog on 2026-07-16 with an FCEB remediation due date of 2026-07-19.

Although 58644 nominally requires Site Owner authentication, that bar is low in practice: this same July cycle also patched CVE-2026-56164 (missing-authentication EoP) and CVE-2026-45659 (RCE), and the operative real-world pattern is to chain an auth-bypass to reach Site-Owner context, then fire the 58644 deserialization gadget for reliable RCE. Post-exploitation follows the now-familiar on-prem SharePoint ("ToolShell"-lineage) tradecraft: stealing IIS machine keys (ASP.NET ValidationKey/DecryptionKey), forging __VIEWSTATE for durable, patch-surviving re-entry, dropping ASPX web shells, and deploying follow-on malware.

Because the deserialization payload itself is opaque, the reliable endpoint signal is the small set of high-fidelity behaviors it produces: the IIS worker (w3wp.exe) spawning a command interpreter, w3wp invoking the .NET compilers (csc.exe/vbc.exe) to materialize a gadget or web shell, ASPX/ASHX writes into the SharePoint LAYOUTS/web directories, and commands touching machine keys / web.config. These are the anchor hunts below.

Defender priority: Treat any on-prem SharePoint as presumed-compromised until proven clean. Do three things today — (1) apply the July 2026 SharePoint updates (they fix 58644 and the chainable 56164/45659), (2) rotate IIS/ASP.NET machine keys and restart IIS (patching without rotation leaves signed-ViewState persistence intact), and (3) enable AMSI Full Request Body scanning. Then hunt with Q1–Q6.

Intel gap (perishability): As of the pack date no vendor has published atomic IOCs (web-shell filenames, hashes, C2 IPs) specific to CVE-2026-58644. This pack is therefore behavior-anchored; the IOC appendix ships REPLACE_WITH_… placeholders to fill the moment your IR team or a vendor report yields campaign atomics. No atomic indicator here is fabricated.

Hunt hypotheses (fidelity-ordered)

Attack chain

This is a behavior-first pack. The atomic rows below are placeholders to be populated from your IR findings or a vendor report; the behavioral rows are the operative indicators today.

• IIS access logs: Review POSTs to SharePoint _layouts endpoints with oversized or Base64-heavy request bodies and serialized-object payloads. Correlate suspicious client IPs and the authenticating account against the same window as any Falcon hit — 58644 requires an authenticated session, so the abused account is an investigative lead.
• SharePoint ULS logs: Search for deserialization exceptions, ViewState MAC validation errors, and unexpected application-pool identity actions.
• AMSI: After enabling AMSI Full Request Body scanning, monitor Defender/AMSI events on the SharePoint servers for blocked request bodies — a direct exploitation signal.
• web.config integrity: Baseline machineKey values; alert on any change to ValidationKey/DecryptionKey outside a planned rotation. An attacker-known key = live persistence.
• Filesystem sweep: Enumerate *.aspx/*.ashx under the SharePoint web root and LAYOUTS folders; diff against a known-good list and creation timestamps. Also review the ASP.NET Temporary ASP.NET Files tree for freshly compiled assemblies.

Promote Q1 and Q5 to blocking IOAs after a short baseline; keep Q2/Q3/Q4/Q6 as investigate-only scheduled searches until tuned to your farm.

• Telemetry ready: Confirm Falcon sensors are installed and reporting on every on-prem SharePoint web front end (not just app/DB tiers).
• Benign baseline: Run Q2, Q3 and Q6 across a normal patch/maintenance and app-pool-recycle window first to learn legitimate csc.exe first-compile, WSP-deploy, and agent noise, then apply the TUNING exclusions before alerting.
• Positive test: In a lab, launch cmd.exe as the SharePoint app-pool identity from w3wp context and confirm Q1 fires; drop a benign .aspx into LAYOUTS and confirm Q3 fires.
• Promotion: Promote Q1/Q5 to blocking IOAs only after the baseline shows zero benign hits for a rolling week; keep Q2 investigate-only given legitimate first-compile activity.

Rotate ASP.NET machine keys on a SharePoint farm (run after patching)

# Rotate the farm ViewState/machine keys via SharePoint management shell.
# Do this on ONE server; the farm propagates. Then IISRESET on each WFE.
Add-PSSnapin Microsoft.SharePoint.PowerShell -ErrorAction SilentlyContinue
Set-SPMachineKey -WebApplication (Get-SPWebApplication)   # rotate per web app
Update-SPMachineKey -WebApplication (Get-SPWebApplication) # push new key to farm
# On EACH web front end:
iisreset /noforce
# Verify old key no longer accepted: forged ViewState from the stolen key now fails MAC validation.

Enable AMSI Full Request Body scanning (interim mitigation)

# SharePoint Subscription / patched builds expose AMSI request-body scanning.
# Enable and set to Full Request Body mode, then recycle the app pools.
Set-SPManagedAccountAmsi -EnableAmsi $true    # where supported
# In Central Admin: Security -> Configure AMSI -> enable, mode = Full Request Body.
# Confirm Microsoft Defender / a compatible AV with AMSI is running on each WFE.
Restart-Service W3SVC

Enumerate suspect ASPX + freshly compiled assemblies

$roots = @(
  "C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS",
  "C:\inetpub\wwwroot\wss\VirtualDirectories"
)
Get-ChildItem -Path $roots -Recurse -Include *.aspx,*.ashx,*.asmx -ErrorAction SilentlyContinue |
  Sort-Object LastWriteTime -Descending |
  Select-Object FullName, CreationTime, LastWriteTime, Length | Format-Table -Auto
# Also review recently compiled deserialization gadgets under Temporary ASP.NET Files:
Get-ChildItem "C:\Windows\Microsoft.NET\Framework64\v4.0.30319\Temporary ASP.NET Files" -Recurse -Include *.dll -ErrorAction SilentlyContinue |
  Sort-Object LastWriteTime -Descending | Select-Object FullName, LastWriteTime -First 40

Gaps: The deserialization request itself is only visible in IIS/ULS logs (S7), and re-use of a stolen machine key produces valid-looking traffic that endpoint telemetry cannot distinguish — the only reliable control there is key rotation, not detection. Populate the atomic IOC placeholders (S10) once IR yields them to close the CVE-to-atomic gap.