March 2026 Patch Fixes SharePoint CVE-2026-26114 Deserialization RCE

  • Thread Author
Microsoft released a security update on March 10, 2026 that closes a high‑severity remote code execution (RCE) vulnerability in on‑premises Microsoft SharePoint Server tracked as CVE‑2026‑26114; the flaw is a deserialization of untrusted data issue that could allow an attacker with low privileges to execute code over the network, and Microsoft’s March SharePoint updates for affected SKUs explicitly include fixes that resolve this CVE. (support.microsoft.com)

Background​

Microsoft SharePoint Server is a widely deployed on‑premises collaboration and content platform that historically has been a high‑value target for attackers because it often exposes internal files, configuration data, and long‑lived cryptographic material to intranet and sometimes internet‑facing access. In 2025 a chain of deserialization and spoofing bugs (publicly tracked as the “ToolShell” incidents) demonstrated how incomplete or rushed patching can leave on‑prem SharePoint installations susceptible to web‑shell drops, machineKey theft, and ransomware follow‑on. T the operational urgency around SharePoint deserialization flaws and underlined the need to treat vendor advisories and confidence signals as high‑priority triage triggers.
CVE‑2026‑26114 is part of Microsoft’s March 2026 security rollup for SharePoint Server. Microsoft’s cumulative update documentation for SharePoint Server 2016 (KB5002850) explicitly lists CVE‑2026‑26114 and confirms the update resolves a SharePoint Server RCE class issue; parallel updates for SharePoint Server 2019 and Subscription Edition were also published as part of the March 10, 2026 patch cycle. (support.microsoft.com)

What the technical record says (summary of verified details)​

  • Vulnerability class: Unsafe deserialization (CWE‑502). The public vendor summary and independent trackers describe the defect as deserialization of untrusted input that can lead to execution of attacker‑controlled code.
  • Attack complexity and impact (vendor/trackers): reported CVSSv3.1 base score around 8.8 (High); vector information assigned by trackers indicates network‑accessible exploitation with low complexity under the right privilege model. Independent CVE aggregators and security vendors list the base score as 8.8 and map the vector to AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H.
  • Affected products: on‑premises SharePoint Server SKUs addressed in the March 10, 2026 updates (2016, 2019, Subscription Edition) are explicitly included in Microsoft’s KB and update rollups; SharePoint Online (Microsoft 365 SaaS) is not affected by on‑premises bugs of this class unless explicitly stated. Administrators must apply the SKU‑dependent cumulative updates. (support.microsoft.com)
  • Public exploitation status: No authoritative public advisory from Microsoft or U.S. federal agencies (at the time of the March 10, 2026 update) states that CVE‑2026‑26114 was observed being exploited in the wild. That said, the security posture for SharePoint deserialization issues remains sensitive because previous, similar vulnerabilities were actively exploited, so defenders should assume high risk until a patch is applied and hosts are verified clean. (support.microsoft.com)
Note: where vendor advisories are intentionally brief (a common practice to avoid disclosing exploit details), the presence of the CVE identifier in the Security Update Guide and the published cumulative update packages are the authoritative signals administrators should act upon. Published KB pages list CVEs fixed by each update, and those KB packages are the canonical remediation artifacts. (support.microsoft.com)

Why deserialization in SharePoint matters (technical analysis)​

Deserialization bugs arise when an application accepts serialized objects or structured payloads from untrusted sources and reconstructs them into in‑memory objects without adequate validation. In .NET environments—SharePoint’s platform—unsafe deserialization has repeatedly been used to instantiate gadget chains that invoke dangerous methods or load attacker‑controlled payloads into application code paths.
  • In SharePoint’s case, deserialization vulnerabilities frequently touch web request handlers or APIs that accept serialized state, ViewState-like payloads, or object payloads used internally for picker/lookup APIs. When those endpoints are reachable from an attacker‑controlled network position and lack adequate privilege checks, an attacker can craft a serialized payload that, once deserialized, causes arbitrary methods to run.
  • The practical consequences: an attacker who accomplishes code execution in the IIS worker process (w3wp.exe) can:
  • write web shells (.aspx) to SharePoint folders,
  • extract machineKey or other cryptographic material used for __VIEWSTATE and forms authentication, and
  • pivot to other internal systems or stage persistent backdoors and ransomware payloads. The 2025 exploitation campaigns illustrated precisely these post‑exploit activities, making deserialization vulnerabilities an immediate operational threat when present in internet‑connected or insufficiently segmented intranet servers.

Vendor response and confidence signals​

Microsoft’s Security Update Guide and the March 10, 2026 SharePoint cumulative updates provide the official remediation. The vendor’s public advisory model often intentionally withholds exploit proofs and low‑level details; this is done to avoid feeding exploit development while patches roll out. For defenders, the important signals are:
  • The CVE’s presence in the vendor’s update catalog and the inclusion in shipped KB packages (i.e., the fix is published and available). (support.microsoft.com)
  • Vendor confidence/communication: Microsoft sometimes marks vulnerability entries with a confidence level or provides controlled technical briefings to partners; where the public advisory is terse, treat the vendor acknowledgement plus the published fix as a high‑priority operational trigger. Several security operations discussions in our archive highlight that Microsoft’s concise advisory wording is meant to conserve details while enabling administrators to act.
In short: vendor acknowledgement + published cumulative update = high confidence the vulnerability exists and is being fixed; the minimal public technical detail increases urgency rather than reducing it, because attackers benefit from any delay in patching.

Operational risk assessment (what defenders must assume)​

  • Risk level: High for internet‑exposed or insufficiently segmented SharePoint farms. Historical precedent shows deserialization RCEs are attractive for opportunistic and targeted actors.
  • Likelihood of exploitation: While there was no public assertion of active exploitation of CVE‑2026‑26114 on March 10, 2026, the vulnerability class and prior exploitation patterns justify assuming a non‑trivial probability of targeted exploitation until proven otherwise. Security trackers and vulnerability feeds assigned a high CVSS score and flagged the issue in March 2026 patch reporting.
  • Consequence of compromise: Severe. Successful exploitation can lead to full server compromise, credential and secret theft, web shell deployment, and enterprise lateral movement; in prior incidents, this culminated in data theft and ransomware deployment.

Practical, prioritized mitigation playbook (step‑by‑step)​

Below is a concise, actionable playbook for administrators and incident response teams. Apply these steps immediately to any on‑prem SharePoint fleet.
  • Patch (first priority)
  • Identify the exact SharePoint SKU and build for each farm node (2016, 2019, Subscription Edition). Use Microsoft Update Catalog/cumulative KB packages and apply Microsoft’s March 10, 2026 updates for your SKU. The official KB pages list CVE‑2026‑26114 in the SharePoint 2016 update notes. (support.microsoft.com)
  • If you manage updates via WSUS/ConfigMgr, approve the March 2026 rollups and schedule controlled reboots as required.
  • Isolate internet‑exposed instances
  • If you host any SharePoint front‑ends or web‑facing endpoints, temporarily restrict or remove external access until you confirm the patch is installed and validated. Historically, emergency isolation slowed active exploitation waves.
  • Hunt for post‑exploitation indicators (immediate triage)
  • Look for web shell artifacts (e.g., newly created spinstall0.aspx or unusual files under the Layouts directory).
  • Review IIS access logs for suspicious POST payloads to endpoints that accept serialized parameters and for requests that result in unexpected process activity.
  • Search for w3wp.exe spawning encoded PowerShell or writing out .aspx/.dll files; check for sudden reads of configuration files and machineKey extraction attempts. Microsoft’s prior guidance and incident writeups list these as reliable indicators.
  • Rotate secrets and credentials (if compromise suspected)
  • Replace any certificates, service account passwords, and keys that might be exposed to the compromised server.
  • Rotate ASP.NET machineKey values and any stored secrets used by SharePoint or integrated services. Attackers have historically harvested machineKey material to forge __VIEWSTATE and persistent tokens.
  • Forensic preservation and incident response
  • Preserve full disk and memory images for affected hosts before reimaging.
  • Collect IIS logs, Windows event logs, network captures, and file system timelines.
  • Engage IR resources if evidence of exploitation is present; in prior cases, nation‑state and criminal groups used chained exploitation to deploy web shells then move laterally.
  • Apply layered long‑term mitigations
  • Use network segmentation to limit SharePoint’s access to internal systems.
  • Enforce least privilege for local SharePoint service accounts.
  • Deploy endpoint detection with rules tuned to detect web shell behaviors and suspicious w3wp activity.
  • Consider WAF rules or request‑filtering for endpoints that historically accept serialized blobs while the environment is being hardened.

Detection tips: query examples and YARA‑style indicators​

  • Log queries to spot likely exploitation:
  • IIS logs: look for POSTs to pages that accept serialized data; unusual Content‑Type headers; long base64‑ish bodies; unexpected User‑Agents.
  • Process creation logs: w3wp.exe spawning PowerShell with encoded commands; creation of files in Layouts, _layouts, or the 14/15/16 template folders; writes to web.config or bin folders.
  • File artifacts to search for:
  • Newly created .aspx files with unusual names (spinstall0.aspx is a known indicator from prior incidents).
  • Unexpected DLLs or exe files dropped into SharePoint directories.
Note: specific signatures and yara rules evolve rapidly; use the combination of Microsoft guidance and threat intel from vendors to augment hunts.

Cross‑checking and verification (how we validated the facts)​

  • Microsoft’s published SharePoint March 10, 2026 update document (KB5002850) explicitly lists CVE‑2026‑26114 as addressed in the SharePoint Server 2016 security update; that KB is the authoritative remediation artifact and the primary verification point for administrators. (support.microsoft.com)
  • Multiple independent vulnerability aggregators and security vendors reported CVE‑2026‑26114 in March 2026 and assigned a CVSSv3.1 base score of about 8.8; Tenable’s March Patch Tuesday summary and other trackers corroborate the vendor listing and the high‑severity classification. These independent notices act as cross‑validation of the CVE metadata.
  • Historical context—recent SharePoint exploitation waves in 2025 and the “ToolShell” chain—were confirmed by Microsoft, CISA, and multiple vendors and are relevant context because they demonstrate the attack patterns that make deserialization bugs particularly dangerous in SharePoint. We used Microsoft’s blog and CISA advisories for that corroboration.
  • Files and community posts in the provided internal archive also document the practical consequences of SharePoint deserialization exploits and the challenges of partial remediation in prior incidents; those discussions helped shape the operational urgency in our guidance.

Strengths in Microsoft’s response — and where risk remains​

Strengths
  • Microsoft shipped SKU‑specific cumulative updates and made the fixes available via Microsoft Update and the Download Center on March 10, 2026, enabling administrators to remediate quickly using standard enterprise update mechanics. The 2016 KB explicitly lists CVE‑2026‑26114, demonstrating vendor commitment to patch delivery. (support.microsoft.com)
  • The vendor and government ecosystems (CISA, security vendors) have historically coordinated advisories and hunting guidance for SharePoint exploitation, meaning defenders can access both vendor patches and hunting playbooks in parallel.
Risks and gaps
  • Public advisories for modern Microsoft vulnerabilities are often deliberately terse about exploit mechanics; while this reduces detail available to attackers, it also forces defenders to act on signals (CVE presence + KB) without low‑level indicators of compromise—raising the operational burden on patching and hunting teams. Several community posts highlight the operational friction this creates.
  • On‑prem environments are heterogeneous: not every farm is on a fully supported or easily upgradable SKU (some organizations still run older 2016 farms or rely on custom solutions), and historically Microsoft’s incremental patches sometimes left gap windows for certain configurations. That history means defenders must not only patch but verify the patch actually removes vulnerable endpoints.
  • Rapid, widespread exploitation remains a plausible scenario for any deserialization RCE in SharePoint because public exploit scanners and tooling can quickly enumerate vulnerable hosts; timeline compression between disclosure and automated scanning can make the window of exposure dangerously small. Past abuse campaigns illustrate how fast attackers move once a reliable exploit is available.

Recommended priorities for CISOs and security leaders​

  • Immediate horizon (0–72 hours)
  • Confirm inventory: map all on‑prem SharePoint farms and their exposure (public internet vs internal).
  • Patch: apply the March 10, 2026 cumulative updates for all supported SKUs. Validate the installed build numbers against Microsoft’s KB manifests. (support.microsoft.com)
  • Isolate public endpoints temporarily if patching cannot be completed within hours.
  • Short term (3–14 days)
  • Conduct a focused threat hunt for web shells and related artifacts; rotate all secrets potentially accessible from SharePoint servers (machineKey, service account credentials).
  • Review application allowlists and tighten WAF rules for endpoints accepting serialized input.
  • Medium term (14–90 days)
  • Evaluate SharePoint hardening and segmentation: reduce lateral movement risk and instrument detection around w3wp behavior.
  • Plan upgrades where older, out‑of‑support SKUs persist; maintain a cadence to reduce the window of future surprise vulnerabilities.

Caveats and unverifiable claims​

  • As of the release of Microsoft’s March 10, 2026 updates and the publication of vendor KBs, we did not find a public, authoritative statement that CVE‑2026‑26114 was under active exploitation in the wild. If your telemetry or threat intelligence indicates otherwise for your environment, treat that information as overriding and escalate accordingly. Public trackers and feeds did mark the CVE as high severity and included it in March Patch reports. (support.microsoft.com)
  • Some community writeups and internal tracker notes reference broad SharePoint exploitation campaigns from 2025; those incidents are accurate and relevant but are separate CVE families (the “ToolShell” events and their related CVEs) and should be used as context for operational risk, not as direct evidence that this specific CVE was exploited prior to patching. Distinguish between the historical ToolShell chain and CVE‑2026‑26114 when communicating risk to non‑technical stakeholders.

Final assessment​

CVE‑2026‑26114 is a high‑impact SharePoint Server deserialization vulnerability that Microsoft fixed in the March 10, 2026 security updates. The combination of vendor acknowledgement, the presence of the CVE in Microsoft’s KB manifests, and corroboration by independent vulnerability trackers establishes a high degree of confidence in the vulnerability’s existence and the correctness of the published remediation. Administrators should treat the CVE as an urgent patch‑and‑hunt priority: apply the appropriate cumulative update for each SharePoint SKU, isolate externally reachable instances until patched, perform a targeted forensic hunt for web shells and suspicious process activity, and rotate any cryptographic secrets or credentials that might have been exposed. (support.microsoft.com)
In short: patch first, hunt second, rotate secrets now, and assume the worst until you can prove your SharePoint farms are clean. Historical precedent demonstrates that deserialization RCEs in SharePoint can move quickly from proof‑of‑concept to large‑scale abuse; the industry learned this in 2025 and should not repeat the same delay.
Conclusion
Microsoft’s March 10, 2026 updates close CVE‑2026‑26114—a serious deserialization‑based RCE affecting on‑premises SharePoint Server. The vendor fix and KB entries are the authoritative source for remediation; administrators must apply those updates immediately, hunt for indicators of compromise, rotate secrets if compromise is suspected, and harden their SharePoint deployment posture to reduce the chance of recurrence. The combination of vendor acknowledgement, independent tracking, and the operational history of SharePoint deserialization attacks justifies high urgency and immediate action. (support.microsoft.com)
Source: MSRC Security Update Guide - Microsoft Security Response Center
 
Click to expand...
You must log in or register to reply here.