SharePoint CVE-2026-50522: rotate your machine keys

There's a class of vulnerability where applying the patch and calling it done is worse than useless, because it tells you the job is finished when it isn't. SharePoint CVE-2026-50522 is that class. It's a CVSS 9.8 unauthenticated remote code execution flaw in on-prem SharePoint, it's being exploited in the wild, and what attackers are taking is your machine keys — the cryptographic material that lets them keep minting valid sessions long after the update installs.

What actually happened

Microsoft shipped the fix for CVE-2026-50522 in its July 14 security updates. It's a deserialization-of-untrusted-data flaw affecting SharePoint Server 2016, 2019, and Subscription Edition. Microsoft's advisory framed it as requiring at least Site Owner access; Defused reported that the requests it captured in the wild carried no authentication material at all. Believe the packet capture.

The timeline is tight. Defused saw undocumented SharePoint deserialization attacks starting July 17. On July 20, watchTowr identified public proof-of-concept code, and per BleepingComputer, its honeypot network was capturing successful exploitation within hours. The payload goes to SharePoint's /_trust/default.aspx sign-in endpoint as a forged security token.

The goal isn't a webshell. It's the ASP.NET machine keys. With those, an attacker forges their own authentication tokens and impersonates any user with access to your sites and documents — no exploit needed, because they're not exploiting anything anymore. They're just signing in. This is the third SharePoint flaw exploited in the wild in 2026.

Why patch-and-forget fails your business

The mental model most small teams carry is that a CVE is a hole and a patch is a plug. That works for memory-corruption bugs. It does not work when the payload is credential theft, because the patch closes the door the thief used and leaves the copied keys in their pocket.

So the remediation is three steps, not one. Apply the July updates. Rotate the machine keys. Restart IIS so the new keys take effect. Skip step two and you have a patched server that a prior visitor can still authenticate to.

Then ask the harder question: why is a SharePoint server answering unauthenticated requests from the internet at all? For most companies under 200 people, on-prem SharePoint is inherited infrastructure — stood up by a consultant, still holding contracts and HR files, on nobody's patch calendar. If that describes yours, the CVE is a symptom. The exposure is the real finding.

Sources: BleepingComputer, The Hacker News, Microsoft Security Update Guide.