SharePoint CVE-2026-20963 RCE: Patch It Now
On-prem SharePoint faces another exploited RCE. CVE-2026-20963 is in CISA's KEV catalog. Here is who is at risk and how to harden your server.

If you run SharePoint on your own servers, you are in recurring, high-stakes territory: on-prem SharePoint is one of the most relentlessly attacked enterprise platforms, and 2026 added another actively exploited remote-code-execution flaw to the pile. CVE-2026-20963 is already in CISA's Known Exploited Vulnerabilities catalog, which means this is not theoretical and the clock is running.
Quick answer
CVE-2026-20963 is a SharePoint remote-code-execution flaw patched in Microsoft's January 2026 update and later added to CISA's KEV catalog, signaling confirmed exploitation. Only self-hosted SharePoint Server is affected; Microsoft 365 SharePoint Online is not. Patch with the January 2026 security update immediately, enable AMSI integration, and rotate ASP.NET machine keys if you had any ToolShell-class exposure, because stolen keys let attackers forge tokens even after patching. Then hunt for web shells, because a clean patch does not prove you were not already breached.
Key takeaways
- CVE-2026-20963 is a SharePoint RCE patched in Microsoft's January 2026 Patch Tuesday and later added to CISA's KEV catalog.
- It arrives in the shadow of ToolShell (CVE-2025-49704, 49706, 53770, 53771), a 2025 RCE chain that enabled credential-free code execution on on-prem servers.
- Only self-hosted SharePoint is at risk. Microsoft 365 SharePoint Online is unaffected.
- Government, education, healthcare, and large enterprises run the most exposed on-prem deployments and are prime targets.
- Patch promptly, rotate machine keys after ToolShell-class incidents, and assume internet-facing SharePoint is being scanned constantly.
Why SharePoint keeps getting hit
SharePoint sits at the center of document collaboration for huge organizations, often holding sensitive files, and it frequently integrates with identity systems and other internal services. On-prem deployments are commonly internet-facing for remote access, patched on slow cycles, and rich with credentials. That combination makes them an ideal target: high value, broad exposure, and a defender who often cannot move fast.
The 2025 ToolShell campaign demonstrated how bad it can get. Attackers chained vulnerabilities to achieve unauthenticated remote code execution, bypassing identity controls including MFA and SSO to gain privileged access. Exploitation intensified rapidly once proof-of-concept code went public, and the campaign reportedly hit hundreds of organizations worldwide, including government agencies.

Are you actually at risk?
The single most important question is whether you run SharePoint on your own infrastructure. SharePoint Online (part of Microsoft 365) is managed by Microsoft and is not affected by these flaws.
| Your deployment | At risk from CVE-2026-20963? | Action |
|---|---|---|
| SharePoint Server on-prem, internet-facing | Critical | Patch now, rotate keys, hunt for web shells |
| SharePoint Server on-prem, internal only | High | Patch now; internal does not mean safe |
| Microsoft 365 SharePoint Online | Not affected | No action; Microsoft manages it |
| Hybrid (both) | On-prem portion at risk | Treat the on-prem servers as critical |
Note
SharePoint Online (part of Microsoft 365) is not affected by these on-prem flaws. The risk is entirely on self-hosted SharePoint Server installations.
What CVE-2026-20963 means for you
CVE-2026-20963 is a fresh on-prem SharePoint RCE that Microsoft patched in January 2026. CISA's decision to add it to the KEV catalog signals confirmed exploitation and a directive for federal agencies to remediate by a set deadline. For everyone else, KEV inclusion is a strong signal to prioritize the patch ahead of routine maintenance. Critically, it is a separate flaw from the 2025 ToolShell chain, so applying last year's fixes does not cover you here.
How to secure your SharePoint server
-
Apply the relevant security updates. Install the January 2026 patch that addresses CVE-2026-20963, and confirm your server also has the 2025 ToolShell fixes if you missed them.
-
Enable AMSI integration. Turn on the Antimalware Scan Interface integration for SharePoint, a Microsoft-recommended mitigation that helps block exploitation attempts even against unknown variants.
-
Rotate machine keys after any ToolShell-class exposure. Stolen ASP.NET machine keys let attackers forge tokens even after patching, so rotate them with
Update-SPMachineKey(or the official procedure) and restart IIS. -
Reduce internet exposure. Where possible, put SharePoint behind a VPN or restrict access to known networks rather than exposing it broadly to the public internet.
-
Hunt for web shells and persistence. Inspect the SharePoint LAYOUTS directories for unexpected files (the ToolShell campaign dropped files like spinstall0.aspx), review IIS logs for anomalous requests, and watch for unfamiliar accounts or scheduled tasks.
What to do right now
If you own an internet-facing on-prem SharePoint server, work this list today, not next change window:
- Confirm the January 2026 update is installed on every SharePoint Server in your estate.
- Enable AMSI integration for SharePoint if it is not already on.
- Rotate ASP.NET machine keys and restart IIS, then verify the rotation took.
- Search the LAYOUTS folders for unexpected .aspx files and review IIS logs for odd POST requests.
- Check for new local accounts and scheduled tasks you did not create.
- Restrict access behind a VPN or IP allowlist where the business allows it.
- Assume breach if you patched late and escalate to incident response if you find anything.
What ToolShell taught us, and why it still applies
The 2025 ToolShell campaign is worth understanding in detail, because CVE-2026-20963 follows the same playbook of consequences even though it is a distinct flaw. ToolShell chained an authentication-bypass weakness with a deserialization flaw to reach unauthenticated remote code execution. Once attackers were in, they did not just run a single payload; they stole the server's ASP.NET machine keys. Those keys are the secret used to sign and validate authentication tokens, so with them in hand an attacker can forge a valid token for any user at will, including after the underlying vulnerability is patched.
That is the single most important lesson for CVE-2026-20963: patching closes the door an attacker came through, but it does not lock the windows they may have opened. If your server was internet-facing and exploited before you patched, the attacker may hold forged-token access that the update alone will never revoke. This is why machine-key rotation is not optional cleanup; it is the step that actually evicts a ToolShell-style intruder. Pair it with a genuine compromise hunt rather than assuming the patch made you whole.
The on-prem patching discipline
The recurring SharePoint story underlines a hard truth about self-hosted enterprise software: you own the patch timeline, and attackers move faster than most change windows. Internet-facing on-prem servers need a compressed patch cycle for anything rated critical, plus active monitoring, because pre-disclosure and rapid post-disclosure exploitation are now the norm rather than the exception.
This is the same pressure seen across the industry's recent edge and server flaws, from SAP NetWeaver's critical patches to VMware vCenter and ESXi exploitation. If you find evidence of a web shell or forged-token activity, jump straight into the containment steps in our ransomware first-hour incident response guide.
Frequently asked questions
Is Microsoft 365 SharePoint affected?
No. SharePoint Online in Microsoft 365 is managed by Microsoft and is not affected by these on-prem RCE flaws. The risk applies only to self-hosted SharePoint Server.
We patched for ToolShell in 2025. Are we covered for CVE-2026-20963?
Not necessarily. CVE-2026-20963 is a separate flaw patched in January 2026. Confirm you have applied the specific January update, not just the 2025 ToolShell fixes.
Why does rotating machine keys matter?
In ToolShell-class attacks, stolen ASP.NET machine keys let attackers forge authentication tokens that survive patching. Rotating the keys and restarting IIS invalidates anything an attacker may have stolen. Patching alone does not undo prior key theft.
How do I know if my server was compromised?
Look for unexpected files in the SharePoint LAYOUTS directory, suspicious IIS log entries (especially unexpected POST requests), new local accounts, and outbound connections to unknown hosts. Given the history of credential-free exploitation, a clean patch does not guarantee you were not already hit.
How fast should I patch?
For an internet-facing on-prem server with a KEV-listed RCE, treat it as same-day. The window between disclosure and mass exploitation for these flaws is now measured in hours to days.
Sources & further reading
- cisa.gov/news-events/alerts/2025/07/20/update-microsoft-releases-guidance-exploitation-sharepoint-vulnerabilities
- unit42.paloaltonetworks.com/microsoft-sharepoint-cve-2025-49704-cve-2025-49706-cve-2025-53770/
- security.com/threat-intelligence/toolshell-zero-day-sharepoint-cve-2025-53770
- varonis.com/blog/toolshell-sharepoint-rce
- cisa.gov/known-exploited-vulnerabilities-catalog


