On January 13, 2026, Microsoft shipped a cumulative update for SharePoint Server that stomps out a dangerous remote code execution flaw tagged CVE-2026-20947. The vulnerability, rated critical by Microsoft, could allow an unauthenticated attacker to run arbitrary code on an affected server simply by sending a specially crafted HTTP request. With SharePoint farms often housing sensitive corporate data and facing the internet, the fix demands immediate attention — but patching alone isn’t enough. This is also a hard reminder to rotate one of the most overlooked secrets in any SharePoint deployment: the ASP.NET machineKey.

What the January 2026 Updates Actually Fix

Microsoft’s Security Update Guide confirms that CVE-2026-20947 was addressed as part of the SharePoint cumulative updates released on January 13. For SharePoint Server Subscription Edition, the primary patch package is KB5002822. Administrators running SharePoint Server 2019 or 2016 must apply the corresponding language-specific updates — the exact KB numbers vary by product and installed language packs. After installation, the SharePoint build number increments to a fixed level; for Subscription Edition, the expected build is 16.0.17928.20262. It is critical to verify this on every server in the farm.

The advisory itself is light on exploit details — a deliberate choice by Microsoft to avoid handing attackers a ready-made recipe. Publicly, we know it’s a server-side remote code execution (RCE) vulnerability in SharePoint, meaning an attacker can gain the same privileges as the IIS worker process (w3wp.exe) on the target machine. What we don’t know from Microsoft’s published notes is whether the flaw involves unsafe deserialization, a layout endpoint abuse, or some other vector. That ambiguity changes how defenders must think about posture: you can’t assume a simple patch invalidates every foothold an attacker might already have.

What This Means for Your Organization

For IT administrators, the math is straightforward: any on-premises SharePoint farm that isn’t patched by now is a sitting duck. If that farm is accessible from the internet — even through a reverse proxy — apply the update immediately and keep reading. The risk isn’t theoretical; SharePoint RCEs have been used in real-world campaigns to drop web shells, steal credentials, and move laterally.

For security teams, this CVE should trigger an immediate hunt even if you patch within hours. Historical patterns show that attackers often compromise a server, plant a backdoor, and then lie dormant before striking. Patches close the door they came through but don’t evict them. You need to look for signs of prior compromise — new .aspx files in TEMPLATE\LAYOUTS, suspicious w3wp.exe child processes, or unexpected outbound connections.

For business decision-makers, the language is risk: a successful exploit can lead to data exfiltration, ransomware deployment, or prolonged undetected access. Sharepoint Server often anchors document management, intranet portals, and custom business applications, so downtime or a breach cascades into compliance nightmares and revenue hits.

How We Got Here: SharePoint’s RCE Legacy

The company’s collaboration platform has been a prized target for years because it runs with high privileges on Windows and exposes a broad attack surface. Recent history offers a reliable threat model. In the 2024-2025 “ToolShell” campaigns, attackers chained deserialization flaws and layout-endpoint write primitives to achieve full code execution. They would send malicious POSTs to endpoints like _layouts/ToolPane.aspx, upload ASPX web shells — often with innocuous names like spinstall0.aspx — into the LAYOUTS folder, and then use those shells to harvest the machineKey from web.config.

That machineKey theft is the pivot point. With the validationKey and decryptionKey in hand, an attacker can forge valid authentication tokens and ViewState payloads. Even after you patch the initial entry point, a stolen machineKey allows them to re-enter the environment with elevated privileges. This is why the CVE-2026-20947 advisory, sparse as it is, should prompt immediate machineKey rotation.

Microsoft has consistently improved patch delivery — bundling fixes into cumulative updates simplifies deployment — but it cannot enforce the ops hygiene that prevents persistence. The vendor’s communication paints the vulnerability with the highest confidence: it exists, it’s patched, and the update packages are authoritative. Yet the omission of a public step-by-step exploit recipe means defenders must assume the worst of these familiar patterns.

What to Do Right Now

Here is a priority-ordered action plan that reflects the urgency and the lessons of past incidents.

1. Patch every SharePoint server with the exact KBs. For Subscription Edition, deploy KB5002822. For SharePoint Server 2019 or 2016, go to the Microsoft Update Catalog and match the KB to your language pack. Do not rely on a generic Windows Update sweep; verify build numbers afterward.

2. Rotate your ASP.NET machineKeys farm-wide. After patching, regenerate the validationKey and decryptionKey on each server. You can do this through SharePoint Central Administration (Security > General Security > Manage farm-level configuration) or via PowerShell with the Set-SPMachineKey cmdlet. Once the keys are changed, restart IIS on all nodes. This step invalidates any stolen keys and blocks forged token attacks.

3. Enable AMSI and verify endpoint protection. Antimalware Scan Interface (AMSI) integration inspects HTTP request bodies in memory and can catch web shells or malicious deserialization payloads. Ensure Microsoft Defender for Endpoint or your chosen EDR is running on all SharePoint front-end servers and is monitoring the w3wp.exe process.

4. Hunt for indicators of compromise. Search IIS and ULS logs for anomalous POST requests to _layouts/ pages and ToolPane.aspx — especially those returning 200 OK with unusual content. On disk, check C:\Program Files\Common Files\microsoft shared\Web Server Extensions\<version>\TEMPLATE\LAYOUTS for newly created or modified .aspx files. In your EDR, query for any process spawned by w3wp.exe, such as cmd.exe or PowerShell, that appears outside of normal activity windows.

5. Restrict internet exposure. If possible, place publicly reachable SharePoint farms behind authenticated gateways, a hardened web application firewall, or a VPN. If AMSI can’t be enabled and the farm is internet-facing, consider temporarily removing it from public access until mitigation is complete and verified.

6. Validate the fix and repeat the hunt. After applying updates and rotating keys, run the same checks again. Confirm build numbers, re-scan for web shells, and ensure the new machineKey values are in place. Keep logs and disk images if you find any sign of compromise — you may need them for an incident response.

What to Watch Next

The operational threat from this CVE hasn’t peaked. Historically, once a SharePoint RCE is disclosed — even with minimal details — capable attackers begin reverse-engineering the patches. If a public proof-of-concept surfaces, exploit attempts often spike within hours. Monitor the MSRC advisory page and trusted news sources for any sign of active exploitation. If a PoC drops, move your patch timeline from days to hours and elevate your monitoring thresholds.

In the meantime, treat CVE-2026-20947 as the high-urgency item it is: patch now, rotate your machineKeys, and hunt for signs that someone already walked through the door you just locked. SharePoint resilience depends on it.