← Back to Feed CACHED · 2026-07-05 06:12:22 · CACHE_KEY CVE-2026-26114
CVE-2026-26114 · CWE-502 · Disclosed 2026-03-10

Deserialization of untrusted data in Microsoft Office SharePoint

ASSESSED — NOISGATE V0.5
Vendor
Reassessed
Verdict:
Do you agree?
01 · The Real Story

A guest with a library card who can rewrite the building's blueprints

CVE-2026-26114 is a .NET deserialization flaw in on-premises SharePoint's request/handler pipeline (CWE-502). An attacker with Site Member permissions POSTs a specially crafted serialized payload that SharePoint's binary/XML deserializer inflates into a malicious gadget chain, executing arbitrary code in the context of the SharePoint web application pool (typically a domain-joined service account). Affected builds are SharePoint Server 2016, SharePoint Server 2019, and SharePoint Subscription Edition; the fixes ship in KB5002850 (2016), KB5002845 (2019), and the Subscription Edition March 2026 cumulative update.

Vendor scored this 8.8 HIGH and that is the right call for the average deployment. It is not a *Critical* because PR:L is real — Site Member is not anonymous — but on any SharePoint farm used the way SharePoint is actually used (broad AD-group-based Site Member grants, guest access via B2B, self-service site creation), the population of eligible attackers is measured in thousands per tenant. The impact is domain-adjacent code execution on a server that typically holds keys to SQL back-ends, Search indexes, and secrets in the SharePoint configuration DB. No downgrade.

"Authenticated SharePoint RCE with Site Member privs — vendor score holds. Assume any collaborative tenant has thousands of eligible attackers."
02 · The Attack Path

5 steps from start to impact.

STEP 01

Obtain Site Member access to a target SharePoint site

Attacker acquires credentials for any account holding Site Member (contribute) rights on any site collection on the target farm. In practice this is either a phished internal user, a stale contractor account, or — in tenants that federate guests — an external B2B invite. No admin, no elevated role required.
Conditions required:
  • Valid AD or SharePoint account
  • That account is a Site Member of at least one site collection
Where this breaks in practice:
  • Farms behind VPN/ZTNA restrict reachability to employees only
  • MFA on the primary account slows credential replay
  • Farms that disable external sharing eliminate B2B guest vector
Detection/coverage: Sign-in anomaly detection (impossible travel, new device) in Entra ID / ADFS logs — but noisy in large tenants.
STEP 02

Reach the vulnerable deserialization endpoint

Attacker authenticates to the SharePoint web front end (HTTPS) and locates the request handler that accepts the attacker-controllable serialized blob. This is a network-reachable ASP.NET endpoint exposed to any authenticated user of the affected site — no special app or feature needs to be enabled beyond default site functionality.
Conditions required:
  • Network path to SharePoint WFE on 80/443
  • Valid authenticated session cookie or FedAuth token
Where this breaks in practice:
  • Perimeter WAF (F5 ASM, Azure Front Door, Cloudflare) with SharePoint rulesets may flag oversized/binary POST bodies
  • Farms fronted by an application proxy (Entra App Proxy, NetScaler) reduce direct exposure
Detection/coverage: IIS logs will show the specific handler URI; Defender for Endpoint and Rapid7 InsightIDR added signatures post-March 2026 patch.
STEP 03

Weaponize a .NET gadget chain (ysoserial.net)

Attacker generates a payload with ysoserial.net — typically the TypeConfuseDelegate or ObjectDataProvider gadget against BinaryFormatter / LosFormatter / ObjectStateFormatter. The payload triggers command execution during deserialization inside the SharePoint w3wp.exe worker process.
Conditions required:
  • Knowledge of which formatter the vulnerable sink uses
  • Ability to base64/URL-encode payload into the parameter
Where this breaks in practice:
  • AMSI hooks in modern .NET Framework instances catch some gadget signatures
  • Defender Antimalware Scan Interface on IIS is enabled by default on SharePoint SE
Detection/coverage: EDR process-tree alert on w3wp.exe spawning cmd.exe/powershell.exe is the highest-fidelity signal.
STEP 04

Execute as SharePoint service account

Code runs as the web application pool identity — commonly a domain user with local admin on the WFE and DB-owner on the content DB. Attacker drops a web shell (ASPX in _layouts or TEMPLATE\LAYOUTS), harvests the MachineKey, decrypts the farm passphrase, and pivots to the config DB.
Conditions required:
  • w3wp identity has typical SharePoint privileges
  • File-system writable under the web root
Where this breaks in practice:
  • Least-privilege farm accounts (rare) limit blast radius
  • Read-only content deployment blocks web-shell drop
Detection/coverage: New ASPX files under LAYOUTS, unusual outbound from the WFE — both high-signal.
STEP 05

Escalate to farm compromise and AD lateral movement

With MachineKey + farm account, attacker forges ViewState across all WFEs, dumps stored credentials from the Secure Store Service, and uses the domain-joined service account for AD recon (BloodHound, Rubeus) — often reaching Tier-0 via SharePoint's Kerberos delegation configurations (unconstrained or constrained-with-protocol-transition are common on SP farms).
Conditions required:
  • SharePoint account is domain-joined (default)
  • Kerberos delegation or SPN abuse path exists
Where this breaks in practice:
  • Protected Users group on service account blocks delegation abuse
  • Tiered admin model contains blast radius
Detection/coverage: AD anomaly analytics (Defender for Identity, Falcon Identity Protection) flag Kerberoasting and delegation abuse from a SharePoint host.
03 · Intelligence Metadata

The supporting signals.

In-the-wild statusNo confirmed exploitation of CVE-2026-26114 specifically as of July 2026. Sibling CVE-2026-45659 (also SharePoint deserialization) *was* added to CISA KEV in July 2026 — same class, same product, active abuse — which materially raises the priority of every SharePoint deserialization bug.
Proof-of-conceptNo public weaponized PoC targeting this specific CVE at time of writing. Class-level tooling (ysoserial.net by Alvaro Muñoz / pwntester) is trivially adaptable and has been used against every prior SharePoint deserialization bug (ToolShell, CVE-2023-29357, CVE-2024-38094).
EPSS0.02408 (~2.4% probability of exploitation in next 30 days) — modest, likely to climb given the KEV pressure on sibling CVEs.
KEV statusNot listed. Sibling CVE-2026-45659 *is* on KEV (July 2026). Treat this CVE as one-degree-of-separation KEV-adjacent.
CVSS vectorCVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H — network, low complexity, low-priv auth required, no user interaction, full CIA impact. PR:L is the only friction knob.
Affected versionsSharePoint Server 2016, 2019, and Subscription Edition (all currently-supported on-prem SKUs). SharePoint Online is not affected.
Fixed versionsKB5002850 (SharePoint 2016), KB5002845 (SharePoint 2019), March 2026 CU for Subscription Edition. Patches released 2026-03-10.
Exposure dataShodan shows ~180k Internet-exposed SharePoint WFEs globally (mostly 2019/SE). Censys puts on-prem SP farms with authenticated endpoints reachable from the Internet in the mid-five-figures. Internal-only farms are 5–10x that.
Disclosure date2026-03-10 — coordinated release via Microsoft Patch Tuesday.
ReporterCredited to a private MSRC-coordinated researcher; Microsoft has not published the finder's name in the advisory.
04 · The Call

noisgate verdict.

Final Verdict
= UNCHANGED to HIGH (8.4/10)

The single most decisive factor is role multiplier: SharePoint on-prem farms canonically hold the enterprise's document trove, are domain-joined with Kerberos delegation, and w3wp runs as a service account with SQL DB-owner on the content DB — a successful chain ends in farm-wide compromise and often AD lateral movement. PR:L authentication is not enough friction to overcome that blast radius when Site Member is granted broadly by AD group in almost every real deployment.

HIGH vulnerability class and affected products
HIGH blast radius on typical farm topology
MEDIUM in-the-wild exploitation of this specific CVE (sibling is KEV, this one is not yet)

Why this verdict

  • PR:L is a soft ceiling, not a floor. Site Member in most enterprises is granted via broad AD groups — the pool of eligible attackers is any phished internal user or federated guest, not a privileged handful.
  • Role multiplier — SharePoint on-prem farm: the vulnerable component *is* the crown-jewel collaboration server; chain outcome is w3wp code execution → MachineKey extraction → farm-wide ViewState forgery → Secure Store credential dump → AD lateral movement via the domain-joined service account. Fleet-scale outcome on the affected component. This alone floors the verdict at HIGH.
  • Class precedent is bad. Every prior SharePoint deserialization bug (ToolShell, CVE-2023-29357/24955, CVE-2024-38094) was weaponized within weeks and used in ransomware pre-cursor activity. Sibling CVE-2026-45659 is already on KEV in July 2026.
  • Friction that keeps it out of CRITICAL: PR:L (auth required), no public weaponized PoC for *this specific* CVE yet, EPSS still ~2.4%, and most farms are not directly Internet-exposed.

Why not higher?

Not CRITICAL because authentication (PR:L) is genuinely required — this is not an unauthenticated ToolShell-class bug — and there is no confirmed in-the-wild exploitation of *this* CVE yet. If a weaponized PoC drops or CISA adds it to KEV, upgrade to CRITICAL same-day.

Why not lower?

Not MEDIUM because the role multiplier is too strong: 100% of installs of the affected product occupy the high-value role (SharePoint farm holding org documents, domain-joined, service-account-privileged). Downgrading below HIGH would ignore both the class precedent (every prior SharePoint deser bug was exploited) and the KEV-listed sibling CVE.

05 · Compensating Control

What to do — in priority order.

  1. Apply March 2026 SharePoint CUs (KB5002850 / KB5002845 / SE March CU) — The only durable fix. For a HIGH verdict, the noisgate mitigation SLA gives you 30 days to stand up a temporary control and 180 days to complete rollout — but given the KEV-listed sibling CVE, pull that forward: mitigate within 7 days, patch within 30.
  2. Rotate SharePoint farm MachineKey and Secure Store master key AFTER patching — Any prior exposure means MachineKey may already be exfiltrated. Post-patch rotation invalidates forged ViewState. Complete within 7 days of patching.
  3. Restrict Site Member grants — audit and prune broad AD-group memberships — PR:L is only meaningful if the L-privilege pool is small. Run a report of every AD group nested into Site Member on every site collection, prune stale contractor and cross-department entries within 14 days.
  4. Front the WFE with a WAF and block oversized/binary POST bodies to non-upload handlers — F5 ASM, Azure Front Door WAF, or Cloudflare with SharePoint managed rules can drop deserialization payloads. Deploy within the 30-day mitigation SLA.
  5. Enable AMSI on IIS worker processes and validate SharePoint SE Antimalware integration — Catches known ysoserial.net gadget signatures during deserialization. Should already be on for SE; validate for 2016/2019 with the AMSI-enabled config.
  6. Move the SharePoint service account into Protected Users and remove unconstrained Kerberos delegation — Breaks the AD-lateral-movement leg of the chain even if RCE succeeds. Complete within 30 days.
What doesn't work
  • MFA on Site Members — session cookies / FedAuth tokens are what the attacker replays; MFA raises the phishing bar but doesn't stop the deser payload once authenticated.
  • Read-only publishing content DBs — the vulnerable handler processes the request in memory before any content write; DB write posture is irrelevant.
  • Network segmentation of the WFE from SQL — code execution happens on the WFE itself; the WFE→SQL boundary doesn't stop RCE on the WFE.
  • Blocking anonymous access — anonymous was never the vector; authenticated Site Member is.
06 · Verification

Crowdsourced verification payload.

Run on each SharePoint Server (WFE and app servers) as a local administrator in an elevated PowerShell. Invoke as .\Check-CVE-2026-26114.ps1. Reports VULNERABLE / PATCHED / UNKNOWN based on installed build vs. the March 2026 patched builds.

noisgate-verify.ps1
POWERSHELLREAD-ONLYSAFE
#requires -RunAsAdministrator
# Check-CVE-2026-26114.ps1
# Detects unpatched SharePoint Server 2016 / 2019 / Subscription Edition
# for CVE-2026-26114 (deserialization RCE, March 2026 CU).

$ErrorActionPreference = 'Stop'

# Patched build floors from March 2026 CU
$patchedBuilds = @{
    '16.0.5' = [Version]'16.0.5513.1000'   # SharePoint Server 2016  (KB5002850)
    '16.0.10'= [Version]'16.0.10417.20038' # SharePoint Server 2019  (KB5002845)
    '16.0.17'= [Version]'16.0.17928.20164' # Subscription Edition March 2026 CU
}

function Get-SPBuild {
    try {
        $key = 'HKLM:\SOFTWARE\Microsoft\Shared Tools\Web Server Extensions\16.0\WSS'
        if (-not (Test-Path $key)) { return $null }
        $v = (Get-ItemProperty -Path $key -Name 'BuildVersion' -ErrorAction Stop).BuildVersion
        return [Version]$v
    } catch { return $null }
}

$build = Get-SPBuild
if (-not $build) {
    Write-Output 'UNKNOWN: SharePoint not detected on this host.'
    exit 2
}

$majorMinorRev = '{0}.{1}.{2}' -f $build.Major, $build.Minor, $build.Build
$sku = switch -Regex ($majorMinorRev) {
    '^16\.0\.5'   { '16.0.5' ; break }
    '^16\.0\.10'  { '16.0.10'; break }
    '^16\.0\.1[6-9]' { '16.0.17'; break }
    default { $null }
}

if (-not $sku) {
    Write-Output "UNKNOWN: unrecognized SharePoint build $build"
    exit 2
}

$floor = $patchedBuilds[$sku]
if ($build -ge $floor) {
    Write-Output "PATCHED: build $build >= required $floor (SKU $sku)"
    exit 0
} else {
    Write-Output "VULNERABLE: build $build < required $floor (SKU $sku) — apply March 2026 CU"
    exit 1
}
07 · Bottom Line

If you remember one thing.

TL;DR
Monday morning: identify every on-prem SharePoint farm (2016 / 2019 / Subscription Edition), inventory the March CU state with the verification script, and stage KB5002850 / KB5002845 / the SE March 2026 CU into a maintenance window this week. Under the noisgate mitigation SLA for HIGH the deadline is 30 days for a compensating control — but with sibling CVE-2026-45659 already on CISA KEV, pull that forward: WAF rule + Site Member audit within 7 days. Under the noisgate remediation SLA for HIGH you have 180 days to finish patching; do not use it. Complete production rollout within 30 days, rotate MachineKey and Secure Store master key post-patch, and treat any SharePoint farm you cannot patch in that window as a Tier-0-adjacent asset requiring compensating isolation.

Sources

  1. Rapid7 vulndb — CVE-2026-26114
  2. SentinelOne vulnerability database — CVE-2026-26114
  3. Cisco Talos — Microsoft Patch Tuesday March 2026
  4. CVEDetails — CVE-2026-26114
  5. Windows Forum — March 2026 Patch analysis
  6. The Hacker News — Sibling SharePoint CVE-2026-45659 added to KEV
  7. SecurityWeek — CISA warns of actively exploited SharePoint vulnerability
  8. TheHackerWire — Microsoft SharePoint Deserialization RCE analysis
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.