March 2026 Patch Fixes SharePoint Spoofing XSS CVE-2026-26105

Microsoft released an important security update on March 10, 2026, to address CVE-2026-26105 — a high‑severity spoofing (cross‑site scripting, CWE‑79) vulnerability affecting on‑premises Microsoft SharePoint Server. The flaw allows an unauthenticated remote actor to deliver specially crafted content that can be rendered by SharePoint pages and spoof trusted site content for users, enabling phishing, credential capture, session hijacking, or targeted content manipulation. Microsoft assigned a CVSS v3.1 base score of 8.1 (High) and published fixes for affected SharePoint Server builds; administrators of on‑prem SharePoint must treat this as a priority patch and apply vendor updates immediately.

Background / Overview​

SharePoint Server remains a high‑value target for attackers because it hosts documents, credentials, workflows, and identity tokens that map directly to enterprise identity and data stores. Over the past two years security teams have repeatedly observed attackers weaponizing presentation‑layer issues in SharePoint — not only to phish and steal credentials but to create reliable footholds that chain into remote code execution and web shell persistence.
CVE‑2026‑26105 is part of March 2026’s cumulative SharePoint security updates. Unlike the deserialization and RCE bugs that formerly drew headlines for enabling full remote code execution, this vulnerability is an improper neutralization of input during web page generation (classic XSS), which Microsoft characterizes as a spoofing risk. The vulnerability’s technical classification (CWE‑79) signals that malicious input can survive server‑side processing and be returned to users in a context where script execution (or presentation manipulation) is possible.
Microsoft’s public advisory and the accompanying SharePoint update packages for supported on‑premises SKUs were released concurrently with Patch Tuesday on March 10, 2026. The vendor’s metadata places CVE‑2026‑26105 within the “Important” severity band but with a high confidentiality/integrity impact profile due to the potential for credential‑theft and session hijack scenarios.

---

Why this matters: risk model and attack surface​

SharePoint’s combination of common‑use web parts, custom pages, and rich content renderers creates multiple attack surfaces:

• Many enterprises publish SharePoint to internal networks and selectively to partners; even internally‑exposed SharePoint farms are reachable from devices that might be compromised or phished.
• SharePoint pages frequently display user‑generated content (lists, comments, uploaded HTML fragments, metadata) where improper output encoding or sanitization can introduce injection points.
• A successful XSS/spoofing attack in SharePoint can be weaponized into secondary outcomes:
• Credential harvesting via cloned login prompts or injected forms.
• Session token theft when scripts exfiltrate cookies/local storage.
• Social engineering: convincing high‑value users to perform actions under false page content.
• Chaining: using the spoofing foothold as a stepping stone for phishing that leads to RCE exploits or lateral movement.

The CVSS vector string published for this CVE — AV:N/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:N — tells a focused story: the attack can be launched over the network, requires no privileges, has low complexity, and depends on user interaction (a user viewing or clicking a malicious page). The resulting confidentiality and integrity impacts are rated high because credential or content theft would expose sensitive data and permit unauthorized actions.

---

Technical breakdown: how spoofing / XSS in SharePoint typically works​

What CWE‑79 means in practice for SharePoint​

• Improper neutralization of input during web page generation indicates that server‑side code or templating constructs return user‑controlled input into a browser context without adequate escaping or contextual output encoding.
• In SharePoint this can happen in many places: web part properties, list item fields that accept HTML, allowed script regions, or legacy customizations that assume trusted input.

Typical exploitation path​

• Attacker crafts a specially formed URL or payload that places JavaScript or HTML into a field or parameter that SharePoint will render.
• A user (authenticated or unauthenticated, depending on the site configuration) views the affected page, causing the injected content to execute in the user’s browser.
• The malicious script exfiltrates authentication tokens, renders fake UI prompts, or performs actions using the user’s session context.
• Attacker receives collected tokens/credentials and uses them to escalate privileges, traverse to other resources, or initiate follow‑on attacks.

Why "spoofing" is the label Microsoft uses​

• Microsoft distinguishes presentation‑layer issues that allow an attacker to masquerade as trusted content (spoofing) from those that directly execute arbitrary server code (RCE).
• Spoofing/XSS can appear less severe in server impact but carry outsized operational harm because users — tricked by believable UI — take actions that break security assumptions (entering credentials, releasing documents).

---

Affected products and the patch state​

Microsoft’s March 10, 2026 update cycle included security packages that list CVE‑2026‑26105 as a fixed entry for supported SharePoint Server SKUs. Administrators should verify and install the March 2026 SharePoint security update matching their product:

• SharePoint Server Subscription Edition — apply the March 10, 2026 security update build for your release branch.
• SharePoint Server 2019 — apply the March 10, 2026 cumulative security update for the 2019 SKU.
• SharePoint Server 2016 — apply the March 10, 2026 cumulative security update for 2016.

Do not assume automatic patching — many on‑prem deployments are conservative about in‑place updates. Validate your environment’s patch catalog, test the March updates in a staging site, and apply in production according to your change control policies as soon as practical.

---

Immediate mitigation and hardening steps (triage checklist)​

If you run on‑prem SharePoint, follow a prioritized triage and remediation path:

• Inventory and identify
• Enumerate all on‑prem SharePoint farms and versions, including multi‑tenanted or development instances.
• Record public or partner‑exposed endpoints (reverse proxies, web application proxies, edge devices).
• Apply vendor patches (first and foremost)
• Test and deploy the March 10, 2026 SharePoint security update for each affected SKU.
• Use your existing update pipeline (WSUS, SCCM, manual patching) and record KB/build numbers in change logs.
• Short‑term compensating controls (if immediate patching is delayed)
• Restrict external access: remove or limit direct internet exposure for on‑prem SharePoint sites; use VPN or secure reverse proxies.
• Deploy or tune a Web Application Firewall (WAF) to block anomalous input patterns and obvious script injection payloads.
• Implement Content Security Policy (CSP) and X‑Content‑Type‑Options where possible to reduce script execution likelihood.
• Enforce least privilege for SharePoint service accounts and limit write access to content areas that accept rich HTML.
• Hunting and detection
• Search IIS logs for suspicious query strings containing "<script", "onerror", "onload", "javascript:", encoded angle brackets, or long base64 blobs in parameters.
• Look for anomalous POSTs to list item endpoints or admin pages outside business hours.
• Monitor telemetry for unusual authentication patterns, sudden download spikes, or user sessions initiating unexpected POSTs after content views.
• Post‑patch validation
• After updating, re‑scan the farm for the presence of known vulnerable endpoints and attempt reproduction under controlled test accounts.
• Validate that custom web parts and third‑party extensions are compatible and continue to sanitize output properly.
• If you maintain a WAF, remove temporary rules only after confirming patch effectiveness.

---

Detection playbook: practical queries and IOC examples​

Below are sample checks defenders can use immediately. Adapt fields and indices to your SIEM or logging system.

• IIS log quick grep (Unix-like tools)
• grep -iE "(%3Cscript|<script|javascript:|onerror=|onload=)" u_ex*.log
• Generic regex to search HTTP logs or WAF logs for encoded script tags
• (?i)(%3C|<)\sscript\b|javascript:|onerror\s=|onload\s*=
• Example SIEM / KQL pattern (conceptual)
• Filter webserver logs for POSTs to list item update endpoints OR GETs to view pages containing query strings longer than expected.
• Look for repeated hits from the same source that include suspicious encoding patterns.
• Cross‑reference successful page views with subsequent authentication anomalies (multiple IPs using same session token).

Flag as suspicious:

• Requests that include encoded HTML or large JSON fields where only simple text is expected.
• Authenticated user sessions that immediately access admin or file‑download pages after a page view containing scriptlike payloads.
• Unusual creation or modification of pages/web parts containing script tags.

---

Why you should treat a SharePoint XSS as a high operational risk​

• User trust is the attack surface. Even if server code is intact, deception works — users will click what looks like a genuine SharePoint prompt.
• Credential and token theft is immediate and silent. Browser‑based exfiltration can hand attackers long‑lived session cookies or one‑time credentials that are redeemable.
• Chaining to RCE or lateral movement is common. Attackers frequently combine presentation‑layer footholds with other vulnerabilities or social engineering to achieve persistence.
• Enterprise impact is asymmetric. A single successfully spoofed high‑privilege user can expose large swathes of data and internal tooling.

---

Microsoft’s “confidence” / report‑confidence signal and how to use it in triage​

Microsoft’s Security Response Center (MSRC) publication flow includes metadata beyond CVSS: a report confidence (RC) or vendor confidence metric that communicates Microsoft’s certainty about the existence and technical accuracy of the public advisory and whether exploitation details are fully validated.

• A high confidence designation means Microsoft has strong corroboration (internal tests, exploit traces, or researcher confirmation) and the vendor’s technical narrative is reliable.
• A lower confidence status signals that the advisory may be preliminary, that the public technical details are incomplete, or that Microsoft is still validating exploitability or affected SKUs.

For defenders, the confidence signal should shape the immediate triage priority:

• High confidence + High CVSS = immediate, high‑priority patching and aggressive hunting.
• High CVSS but Low confidence = treat as urgent but verify internally (try to reproduce, monitor telemetry closely).
• Lower CVSS but high confidence = prioritized patching for critical systems and increased monitoring.

For CVE‑2026‑26105, Microsoft published the advisory and corresponding SharePoint update packages on March 10, 2026, which indicates the vendor validated the issue sufficiently to release fixes for supported SKUs. Treat that as a vendor‑backed high‑confidence event and proceed with updates and hunts accordingly.

---

Practical patching playbook (step‑by‑step)​

• Inventory (Day 0)
• Map all SharePoint web front ends, application servers, and databases; record builds and KBs.
• Test (Day 0–1)
• Apply the March 10, 2026 update in an isolated staging farm that mirrors production customizations.
• Validate critical functions: search, document libraries, authentication providers, custom web parts.
• Schedule (Day 1–3)
• Schedule maintenance windows for production farms on the earliest feasible date.
• Communicate to stakeholders and downstream teams (backup, monitoring).
• Deploy (Day 3)
• Apply patches to WFE nodes, app servers; follow Microsoft guidance on sequence and IIS reset.
• Restart IIS and validate service health.
• Post‑deploy checks (Day 3–7)
• Re‑run automated tests and smoke tests for user journeys.
• Monitor logs and SIEM for anomalous patterns.
• Keep compensating WAF rules active for 7–14 days depending on organizational risk tolerance.
• Retrospective (Day 7–14)
• Conduct a quick post‑mortem: what was affected, what was missed, and update runbooks.

---

Defensive coding and long‑term hardening​

Preventing XSS classes of vulnerabilities is a mix of secure development and runtime controls:

• Enforce output encoding for all contexts (HTML, attribute, JavaScript, CSS) rather than relying on input filtering alone.
• Avoid directly rendering user‑generated HTML; prefer safe markup languages or sanitized whitelists.
• Use modern SharePoint frameworks and avoid deprecated customization patterns that circumvent SharePoint’s rendering pipeline.
• Introduce CSP headers and implement SRI (Subresource Integrity) where external assets are used.
• Regularly review third‑party web parts and frameworks for security posture and update them promptly.

---

Critical analysis: strengths, gaps, and residual risks​

Strengths:

• Microsoft released a coordinated Patch Tuesday fix and associated KBs for supported SharePoint Server SKUs on March 10, 2026. A timely vendor fix reduces the window of exposure for patched environments.
• The public CVSS metadata provides a clear technical severity signal, making it straightforward for risk‑based prioritization.
• The inclusion of a vendor confidence/report confidence signal in MSRC metadata helps defenders calibrate urgency when public technical detail is sparse.

Gaps and risks:

• Many SharePoint Server deployments lag behind vendor updates because administrators fear functional regressions in heavily customized farms. That operational friction increases the pool of unpatched, internet‑accessible instances.
• XSS/spoofing vulnerabilities are particularly effective when attacker tradecraft combines social engineering and precise reconnaissance; a single successful targeted phishing campaign can negate many technical controls.
• While vendor patches are critical, they do not retroactively cleanse compromised environments. If an attacker previously used presentation‑layer techniques to harvest credentials, remediation requires credential rotation, session invalidation, and forensic hunts.
• The MSRC confidence metric helps triage, but sometimes the public advisories intentionally omit exploit mechanics to avoid fueling weaponization — this partial disclosure can force defenders to operate in the dark for a short window.

Caveats and unverifiable areas:

• As of the March 10, 2026 public release, there were no broad public reports confirming active exploitation of CVE‑2026‑26105 in the wild. That may change rapidly; defenders must assume attackers will attempt to weaponize any unpatched endpoint.
• Whether specific organizations or sectors were targeted by this specific CVE is not published; historical incidents of SharePoint exploitation show nation‑state and criminal groups both leverage such flaws opportunistically.

---

Operational recommendations for security teams and sysadmins​

• Patch quickly but safely: prioritize production farms with internet exposure, then internal farms used by privileged staff.
• Rotate high‑value credentials and tokens that could be affected by client‑side exfiltration (reset federated sign‑in sessions, rotate API tokens if any automation interacts with SharePoint).
• Hunt proactively: look for suspicious page edits, new web parts, or unexpected file drops; check web server access logs for encoded payloads.
• Educate users: brief high‑value collaborators and content owners that spoofed SharePoint pages are possible and instruct them on verifying URLs, tenant indicators, and MFA prompts.
• Enforce multi‑factor authentication for all high‑privilege SharePoint accounts and for any account that can publish or edit pages.
• Maintain a tested incident response runbook specifically for web‑app presentation attacks and credential compromise.

---

Conclusion​

CVE‑2026‑26105 underscores a recurring truth for enterprise defenders: presentation‑layer vulnerabilities are deceptively powerful, because they exploit human trust and browser behavior rather than server execution contexts alone. Microsoft’s March 10, 2026 patch resolves a high‑impact SharePoint spoofing/XSS issue and should be applied to all affected on‑prem SharePoint Server instances without delay.
Immediate action items for every SharePoint owner:

• Identify affected on‑prem servers and schedule the March 10, 2026 cumulative security update.
• Apply temporary mitigations (WAF, restricted access) if immediate patching is not possible.
• Hunt for IOCs, rotate credentials where risk exists, and validate that customizations sanitize output properly.

Finally, treat the MSRC confidence signal as an operational triage aid: when a vendor publishes a patch alongside an advisory, assume high confidence and prioritize remediation. The technical details of CVE‑2026‑26105 map to a familiar, practical attack model — user‑facing spoofing — and that model has proven devastating in real incidents when defenders delay. Patch, hunt, and harden: the three steps that remain the most effective defense against this class of SharePoint risk.

---

Source: MSRC Security Update Guide - Microsoft Security Response Center