← Back to Feed CACHED · 2026-05-17 09:42:19 · cache_key CVE-2025-29912
CVE-2026-45659 · CWE-502 · Disclosed 2026-05-22

Deserialization of untrusted data in Microsoft Office SharePoint

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
01 · The Real Story

This is a loaded keycard, not an unlocked front door

CVE-2026-45659 is a deserialization bug in on-prem Microsoft SharePoint that lets an authenticated attacker send crafted data and turn ordinary SharePoint access into remote code execution on the server. Microsoft and NVD describe it as affecting SharePoint Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition; NVD shows Subscription Edition fixed at 16.0.19725.20280, while Microsoft's May 2026 SharePoint security updates map to KB5002868 for 2016, KB5002870 for 2019, and KB5002863 for Subscription Edition.

Microsoft's HIGH 8.8 baseline is technically fair, but operational reality trims it down a bit. The decisive friction is authenticated access: this is not unauthenticated edge RCE, and many farms are internal or partner-limited, which means the bug is usually reached only after credential theft, VPN access, or some other initial foothold. That said, once an attacker has a low-priv SharePoint identity, the landing zone is a highly connected Windows server with ugly blast radius potential, so this is still a defender-priority HIGH, not routine backlog.

"Post-auth SharePoint RCE on a crown-jewel server stays high, but it is not an internet worm."
02 · The Attack Path

4 steps from start to impact.

STEP 01

Obtain a valid SharePoint identity

The attacker first needs authenticated access to the target SharePoint deployment. In practice this usually means a phished employee account, a reused partner credential, a stolen session, or an already-compromised internal user reaching the farm through normal SSO or VPN paths. Typical operator tooling here is ordinary credential-access tooling plus a browser, curl, Burp Suite, or a custom HTTP client; no credible CVE-specific public exploit kit was located in reviewed primary sources.
Conditions required:
  • Valid SharePoint-authenticated user context
  • Reachability to the on-prem SharePoint farm over the network
Where this breaks in practice:
  • Many enterprises do not expose on-prem SharePoint broadly to the internet
  • MFA, Conditional Access, VPN gating, and reverse proxies reduce reachable population
  • Stolen credentials are a prerequisite, which implies another success stage for the attacker
Detection/coverage: Identity telemetry and reverse-proxy logs usually cover this step well; vulnerability scanners can flag affected SharePoint versions but cannot prove attacker possession of working credentials.
STEP 02

Send crafted serialized payload to the vulnerable SharePoint path

With a valid session, the attacker targets the vulnerable SharePoint code path and submits malicious serialized data to trigger unsafe deserialization. Expected tooling would be Burp Suite, a custom .NET client, or gadget-generation workflows similar to ysoserial.net adapted to the specific reachable sink. This is the exploitation step that turns low privilege into server-side code execution.
Conditions required:
  • The vulnerable May 2026 SharePoint patch level is missing
  • The attacker can interact with the affected feature or endpoint as the authenticated user
Where this breaks in practice:
  • No reviewed primary source published a turnkey PoC, which slows commodity abuse
  • SharePoint exploitation usually needs version-aware request shaping, not generic spray-and-pray traffic
  • Some farms narrow reachable functionality by zone, role, or publishing configuration
Detection/coverage: Authenticated web exploitation is harder for perimeter tooling to distinguish from normal SharePoint traffic. Version-based scanners should detect missing KB5002863, KB5002870, or KB5002868; network IDS coverage is likely weak until signatures mature.
STEP 03

Execute code in the SharePoint application context

If deserialization succeeds, attacker code runs within the SharePoint server's process context, typically under IIS worker or associated SharePoint service privileges. At this point the actor can run PowerShell, drop tooling, access local secrets, and abuse the server as a trusted internal pivot. Common post-exploitation tooling would be PowerShell, cmd.exe, LOLBins, or C2 stagers.
Conditions required:
  • Successful exploit of the deserialization sink
  • Application pool or service context allows command execution and local resource access
Where this breaks in practice:
  • EDR on the SharePoint host may stop child-process creation or script execution
  • Constrained service accounts and application control reduce practical post-execution options
  • Well-managed tiering can contain lateral movement even after server compromise
Detection/coverage: This step is where defenders usually win: EDR, PowerShell logging, IIS logs, Sysmon, Defender for Endpoint, and child-process analytics can all surface w3wp.exe spawning shells or script hosts.
STEP 04

Abuse the server's trust to expand impact

A compromised SharePoint host can expose content, service credentials, farm configuration, and connectivity into other internal services. The attacker may harvest secrets, stage persistence, or pivot toward domain assets depending on how the farm is integrated. The blast radius can therefore exceed one web server even though the exploit itself is post-auth.
Conditions required:
  • The SharePoint server stores or can reach sensitive enterprise resources
  • Administrative segmentation and service account scoping are weak enough to permit follow-on abuse
Where this breaks in practice:
  • Not every SharePoint farm is a domain-admin shortcut
  • Network segmentation, PAM, JEA, and restricted service accounts sharply reduce follow-on blast radius
  • Content theft and lateral movement are separate operations that create more telemetry
Detection/coverage: Lateral movement and secret-access activity are usually visible to EDR, AD auditing, network detection, and privileged account monitoring, but only if those controls are actually tuned for server workloads.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed active exploitation found in reviewed primary sources as of 2026-05-30. CISA KEV does not list this CVE.
Public PoC availabilityNo credible public CVE-specific PoC located in reviewed primary-source coverage. Treat that as a temporary brake, not safety.
EPSS0.00621 (~0.621% probability in 30 days, user-supplied). That is low, which argues against emergency handling absent new exploitation evidence.
KEV statusNot KEV-listed. Contrast that with other recent SharePoint bugs that *were* added to KEV, which is an important downward pressure on urgency.
CVSS vector readoutAV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H means easy network reach after auth, no user clicks needed, and full CIA impact on success. The PR:L term is the whole story here.
Affected productsNVD lists SharePoint Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition. This is on-prem SharePoint, not SharePoint Online.
Fixed versionsPatch to KB5002868 (SharePoint 2016), KB5002870 (SharePoint 2019), or KB5002863 (Subscription Edition). NVD explicitly shows Subscription Edition fixed at 16.0.19725.20280; Microsoft support pages show build 16.0.5552.1002 for 2016 and 16.0.10417.20128 for 2019.
Exposure realityDirect internet exposure is material but limited versus mainstream edge software. For context, Censys observed about 9,762 on-prem SharePoint servers online during the 2025 ToolShell crisis, showing why exposed farms deserve priority.
Disclosure timingCVE record published by Microsoft on 2026-05-22; NVD shows last modification on 2026-05-27.
Reporting / attributionPublic record is from Microsoft Corporation as CNA. Reviewed public sources do not credit an external finder or publish exploit internals.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (7.6/10)

The single biggest factor is that exploitation requires authenticated SharePoint access, which makes this a post-credential or post-initial-access problem in many real environments rather than a pure edge-breaker. It stays HIGH because the target is a high-value Windows collaboration server where successful code execution can rapidly become data theft, persistence, and lateral movement.

HIGH Vendor metadata, affected product family, and fixed update mapping
MEDIUM Real-world exploitability assessment without a public technical root-cause write-up
MEDIUM Current absence of public exploitation or PoC

Why this verdict

  • Downgrade for attacker position: PR:L is not cosmetic. The attacker needs a working SharePoint identity first, which compounds with phishing resistance, MFA, VPN, and SSO controls.
  • Downgrade for reachable population: this hits on-prem SharePoint, not Microsoft 365 SharePoint Online. That sharply narrows affected population compared with Microsoft's broader cloud collaboration footprint.
  • Hold at HIGH for blast radius: once code lands, it lands on a trusted Windows server that often holds sensitive content and internal connectivity. SharePoint server compromise is rarely a one-box problem.
  • Downgrade for threat evidence: EPSS is low and there is no KEV listing or confirmed active exploitation in reviewed primary sources as of 2026-05-30.
  • Partial re-upgrade for privilege floor: the required privilege is only low, not admin. In environments where any ordinary user can authenticate to the farm, the credential bar is annoyingly attainable.

Why not higher?

This is not unauthenticated pre-auth edge RCE, and that distinction matters. The need for authenticated access plus the smaller on-prem deployment base means the reachable victim set is much narrower than the CVSS impact terms suggest in the abstract. The lack of active exploitation evidence also removes the strongest argument for a CRITICAL call.

Why not lower?

Successful exploitation yields server-side code execution on an enterprise collaboration platform, not a sandboxed user-session bug. Even with the auth prerequisite, the target system is typically high-value, often externally reachable to some user population, and positioned close to sensitive data and internal trust paths. That is too much upside for attackers to call this MEDIUM.

05 · Compensating Control

What to do — in priority order.

  1. Reduce exposure — Remove direct internet reachability for on-prem SharePoint where business permits, or gate it behind a reverse proxy/VPN with strong identity controls. For a HIGH verdict, deploy this compensating control within 30 days if you cannot patch immediately.
  2. Enforce MFA on every external auth path — The exploit starts from authenticated access, so hardening the login path directly attacks the main prerequisite. Require phishing-resistant MFA where possible and close legacy or bypass auth paths within 30 days.
  3. Shrink SharePoint user reach — Audit broad site-member assignments, stale partner accounts, service identities, and dormant users that can authenticate to the farm. Reduce that low-priv population within 30 days to make PR:L materially harder to satisfy.
  4. Hunt for server-side execution from IIS — Alert on w3wp.exe or SharePoint service processes spawning powershell.exe, cmd.exe, cscript.exe, mshta.exe, or unsigned binaries. This does not prevent exploitation, but it gives you the best chance to catch successful abuse while remediation is being completed within 30 days.
  5. Constrain service account blast radius — Review SharePoint application pool and service account privileges, local admin rights, secret storage, and lateral access paths. Tightening those controls within 30 days reduces what an attacker gets after code execution.
What doesn't work
  • MFA by itself does not neutralize the vulnerability; it only makes the required authenticated foothold harder to obtain.
  • A generic WAF rule set is not a reliable fix for deserialization sinks hidden inside normal authenticated SharePoint traffic.
  • Network segmentation that leaves the SharePoint farm broadly reachable to users does not remove the core risk; it only affects follow-on pivoting.
  • EDR alone is not a mitigation. It may catch post-exploitation behavior, but it does not guarantee the deserialization trigger is blocked.
06 · Verification

Crowdsourced verification payload.

Run this on each SharePoint server in the farm from an elevated PowerShell session. Example: powershell.exe -ExecutionPolicy Bypass -File .\Test-CVE-2026-45659.ps1. Local administrator rights are recommended because the script reads HKLM and program file metadata. It reports VULNERABLE, PATCHED, or UNKNOWN based on installed SharePoint build and/or the presence of the May 2026 SharePoint security KBs.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
# Test-CVE-2026-45659.ps1

# Detect patch state for CVE-2026-45659 on Microsoft SharePoint servers.

# Exit codes: 0=PATCHED, 1=VULNERABLE, 2=UNKNOWN


$ErrorActionPreference = 'SilentlyContinue'

function Write-Result {
    param(
        [string]$State,
        [string]$Detail,
        [int]$Code
    )
    Write-Output ("{0} - {1}" -f $State, $Detail)
    exit $Code
}

function Get-InstalledKbMatch {
    param([string[]]$KbIds)

    $roots = @(
        'HKLM:\SOFTWARE\Microsoft\Windows\CurrentVersion\Uninstall',
        'HKLM:\SOFTWARE\WOW6432Node\Microsoft\Windows\CurrentVersion\Uninstall'
    )

    foreach ($root in $roots) {
        Get-ChildItem $root | ForEach-Object {
            $p = Get-ItemProperty $_.PSPath
            foreach ($kb in $KbIds) {
                if (($p.DisplayName -match $kb) -or ($p.ReleaseType -match $kb) -or ($p.PSChildName -match $kb)) {
                    return $kb
                }
            }
        }
    }
    return $null
}

function Get-FileVersionSafe {
    param([string]$Path)
    if (Test-Path $Path) {
        try {
            return [version](Get-Item $Path).VersionInfo.FileVersion
        } catch {
            return $null
        }
    }
    return $null
}

# Fixed minimum builds from Microsoft/NVD review

$fixedSE    = [version]'16.0.19725.20280'
$fixed2019  = [version]'16.0.10417.20128'
$fixed2016  = [version]'16.0.5552.1002'

# Known KBs for May 2026 SharePoint security updates

$kbSE   = 'KB5002863'
$kb2019 = 'KB5002870'
$kb2016 = 'KB5002868'

# Quick path checks

$spRoot = Join-Path ${env:CommonProgramFiles} 'microsoft shared\Web Server Extensions\16'
$binDll = Join-Path $spRoot 'BIN\Microsoft.SharePoint.dll'

if (-not (Test-Path $spRoot)) {
    Write-Result 'UNKNOWN' 'SharePoint 16 hive not found on this host' 2
}

$fileVersion = Get-FileVersionSafe -Path $binDll
$kbHit = Get-InstalledKbMatch -KbIds @($kbSE, $kb2019, $kb2016)

# If the exact security KB is visible, trust that first.

if ($kbHit) {
    Write-Result 'PATCHED' ("Detected installed security update {0}" -f $kbHit) 0
}

# Heuristic edition detection

$isSubscription = $false
$subHints = @(
    'HKLM:\SOFTWARE\Microsoft\Office Server\Subscription',
    'HKLM:\SOFTWARE\Microsoft\Office Server\16.0\Subscription'
)
foreach ($hint in $subHints) {
    if (Test-Path $hint) { $isSubscription = $true }
}

# Read product version hints from registry if present

$regPaths = @(
    'HKLM:\SOFTWARE\Microsoft\Office Server\16.0',
    'HKLM:\SOFTWARE\Microsoft\Office Server\16.0\SharePoint'
)
$productHint = $null
foreach ($rp in $regPaths) {
    $props = Get-ItemProperty $rp
    if ($props.ProductVersion) { $productHint = $props.ProductVersion }
    if ($props.Version) { $productHint = $props.Version }
}

if (-not $fileVersion) {
    Write-Result 'UNKNOWN' 'Unable to read Microsoft.SharePoint.dll version and no matching KB found' 2
}

# Subscription Edition is safest to identify by higher build train or explicit registry hint.

if ($isSubscription -or $fileVersion -ge [version]'16.0.15000.0') {
    if ($fileVersion -lt $fixedSE) {
        Write-Result 'VULNERABLE' ("Subscription Edition build {0} is below fixed {1}" -f $fileVersion, $fixedSE) 1
    } else {
        Write-Result 'PATCHED' ("Subscription Edition build {0} meets/exceeds fixed {1}" -f $fileVersion, $fixedSE) 0
    }
}

# Distinguish 2019 vs 2016 by build range.

# SharePoint 2019 uses a much higher 16.0.10xxx build train; 2016 uses 16.0.5xxx.

if ($fileVersion.Build -ge 10000) {
    if ($fileVersion -lt $fixed2019) {
        Write-Result 'VULNERABLE' ("SharePoint 2019 build {0} is below fixed {1}" -f $fileVersion, $fixed2019) 1
    } else {
        Write-Result 'PATCHED' ("SharePoint 2019 build {0} meets/exceeds fixed {1}" -f $fileVersion, $fixed2019) 0
    }
}
elseif ($fileVersion.Build -ge 5000) {
    if ($fileVersion -lt $fixed2016) {
        Write-Result 'VULNERABLE' ("SharePoint 2016 build {0} is below fixed {1}" -f $fileVersion, $fixed2016) 1
    } else {
        Write-Result 'PATCHED' ("SharePoint 2016 build {0} meets/exceeds fixed {1}" -f $fileVersion, $fixed2016) 0
    }
}
else {
    Write-Result 'UNKNOWN' ("Unrecognized SharePoint build train: {0}" -f $fileVersion) 2
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning, treat this as a post-auth server RCE on a crown-jewel app, not as a fire-drill internet worm. First, identify every on-prem SharePoint 2016/2019/Subscription farm, sort by external reachability and user population, and apply exposure-reduction controls on any internet-reachable farms within the noisgate mitigation SLA for HIGH findings: ≤30 days. Then complete vendor patch deployment to KB5002868, KB5002870, or KB5002863 across the farm within the noisgate remediation SLA for HIGH findings: ≤180 days; exposed or partner-accessible farms should go in the very next approved maintenance window, not the tail end of that window.

Sources

  1. NVD CVE-2026-45659
  2. Microsoft Support: May 2026 Office updates
  3. Microsoft Support: SharePoint Server 2019 KB5002870
  4. Microsoft Support: SharePoint Server 2016 KB5002868
  5. Microsoft Support: SharePoint Server Subscription Edition KB5002863
  6. CISA Known Exploited Vulnerabilities Catalog
  7. FIRST EPSS overview
  8. Censys advisory on exposed on-prem SharePoint population during 2025 ToolShell
Peer Review

What defenders are saying.

Submit a review attribution: handle + country only
0 flags selected · stored anonymously
Validation Results

Crowdsourced verification outputs.

Results submitted by users who ran the verification payload against their environment.