SharePoint's Fourth Zero-Day in a Month — Inside CVE-2026-50522 and the Machine Key Theft Problem

Microsoft patched CVE-2026-50522 on July 14. Six days later, a proof-of-concept exploit hit GitHub, and within hours attackers were using it to break into on-premises SharePoint servers around the world. That’s not a slow week for SharePoint security — it’s the fourth vulnerability in the product exploited in the wild in the past month alone. If you’re running on-prem SharePoint and you think last week’s patch cycle closed the book on this, you need to keep reading, because the interesting part of this story isn’t the RCE. It’s what attackers do with it after you patch.

What CVE-2026-50522 Actually Is

#

Microsoft describes CVE-2026-50522 (CVSS 9.8) as a deserialization-of-untrusted-data vulnerability: “in a network-based attack, an attacker authenticated as at least a Site Owner, could write arbitrary code to inject and execute code remotely on the SharePoint Server.” That’s the official framing. The public PoC exploit, published by security researcher Janggggg, tells a more alarming version of the story: it delivers a malicious .NET BinaryFormatter payload as the cookie of a forged SecurityContextToken, posted to SharePoint’s /_trust/default.aspx WS-Federation sign-in endpoint. If that token gets processed by the vulnerable deserialization path, you get arbitrary code execution — no prior authentication actually required in the attacks observed in the field, despite Microsoft’s advisory language.

This is a familiar shape. BinaryFormatter-based deserialization bugs have plagued .NET applications for years precisely because the type can be coerced into instantiating almost anything an attacker hands it. SharePoint’s WS-Federation trust endpoint just happens to be a particularly juicy place to land one, because it sits directly on the authentication path — reachable before you’ve proven who you are.

The Timeline: PoC to Mass Exploitation in Hours

#

The exploitation timeline here is the real headline, and it should worry every defender still measuring patch windows in weeks:

• July 14 — Microsoft ships the fix as part of its July Patch Tuesday. The advisory doesn’t flag active exploitation and lists exploit maturity as “unknown” — despite CVE-2026-50522 reportedly having been demonstrated live at Pwn2Own Berlin, meaning a working exploit chain had already been handed to Microsoft before the patch shipped.
• July 17 — Threat intelligence firm Defused spots an “undocumented SharePoint deserialization vector” hitting its honeypots. At this point nobody can attribute it to a specific CVE.
• July 20 — Researcher Janggggg publishes a working PowerShell PoC on GitHub. Within hours, watchTowr’s honeypot network, Attacker Eye, captures exploitation attempts using that exact PoC successfully compromising target systems. Defused independently confirms the July 17 activity was almost certainly CVE-2026-50522 all along.

Three days from patch to public PoC. Hours from PoC to mass exploitation. That window keeps shrinking, and it’s the same pattern we’ve watched play out in the multi-wave npm supply chain worms this summer — attackers are now organized enough to weaponize disclosure almost as fast as researchers can publish it.

Why Patching Isn’t the End of the Incident

#

Here’s the part that should change how you respond. watchTowr’s researchers report that attackers exploiting CVE-2026-50522 aren’t just planting webshells — they’re pulling SharePoint machine keys in a single request. Machine keys (the validationKey and decryptionKey values SharePoint and ASP.NET use to sign and encrypt view state, forms-auth tickets, and security tokens) are the cryptographic root of trust for the whole authentication layer. Steal them, and an attacker can forge valid authentication tokens and impersonate any user — including administrators — on that farm indefinitely.

That’s the sentence that matters: patching the deserialization bug does not invalidate keys an attacker already stole. As watchTowr put it bluntly: “Patching is not enough, defenders should rotate credentials on any assets that may have been exposed.” If you apply the July update and call it done, you may be leaving a forged skeleton key in an attacker’s pocket that works long after the vulnerability is closed.

A Fourth Bug in a Month, Not an Isolated Incident

#

CVE-2026-50522 doesn’t stand alone. It’s the fourth SharePoint vulnerability confirmed under active exploitation in roughly a month, joining CVE-2026-58644, CVE-2026-56164, and CVE-2026-45659 — the latter added to CISA’s Known Exploited Vulnerabilities catalog back in early July. CISA’s KEV list now carries 13 SharePoint entries total, five of them added this year alone. CVE-2026-50522 hasn’t been added yet, but given the confirmed in-the-wild activity, expect that to change.

That cadence tells you something structural is going on, not just bad luck. SharePoint’s on-premises deployment model means every unpatched instance is internet-facing, high-value (it’s usually sitting on internal documents, credentials, and workflow data), and running a deserialization-prone technology stack that keeps producing near-identical bug classes. It’s the same lesson enterprises learned the hard way from MOVEit’s zero-day nightmare two years ago: any widely deployed, internet-exposed enterprise file/collaboration platform becomes a standing target, and one clean exploit chain gets reused against thousands of instances before most organizations even see the advisory.

What to Do Right Now

#

If you run on-premises SharePoint Server, treat this as an active incident response task, not a patch-and-forget ticket:

1. Apply the July 2026 security update immediately if you haven’t already — this closes the deserialization path.
2. Rotate your SharePoint machine keys (validationKey and decryptionKey) on every farm that was internet-facing during the exposure window, even if you see no direct evidence of compromise. Assume theft, not just possibility.
3. Rotate any credentials machine keys could forge access to — service accounts, admin sessions, and forms-auth tickets tied to that farm.
4. Hunt your IIS logs for POSTs to /_trust/default.aspx with unusually large or malformed cookie values, and for any authentication activity that doesn’t match your actual Site Owner population.
5. Check for webshells and scheduled tasks planted before you patched — the deserialization bug gives full code execution, so assume persistence mechanisms beyond the stolen keys may exist too.
6. If your SharePoint farm doesn’t need to be directly internet-facing, put it behind a VPN or reverse proxy with strict access controls now. On-prem SharePoint’s exposure surface is the recurring theme across all four of this month’s vulnerabilities.

The Bigger Pattern

#

What’s striking about 2026 so far is how consistently “patch fast” has stopped being sufficient advice on its own. The xz Utils anniversary retrospective made the case that most organizations still don’t have real visibility into what they’re running or how quickly they can react to a disclosure. CVE-2026-50522 sharpens that further: even organizations that did patch within the Patch Tuesday cycle may still be compromised if attackers grabbed machine keys during the exploitation window between disclosure and patch deployment. Frameworks like SLSA and SBOM adoption help you know what’s running where, but they don’t substitute for the operational discipline of rotating secrets after every high-severity incident touching an authentication boundary.

My Take

#

The uncomfortable truth here is that “we patched it” and “we’re secure” have become two different claims, and most incident response playbooks still conflate them. CVE-2026-50522 is a textbook case: a critical deserialization bug in an authentication endpoint, a Pwn2Own-demonstrated exploit chain Microsoft had in hand before it even shipped a fix, a three-day window to public PoC, and a payload specifically engineered to steal the cryptographic material that survives your patch. If your SharePoint incident response checklist doesn’t include machine key rotation as a mandatory step — not a nice-to-have — rewrite it this week. The pattern of four actively exploited SharePoint bugs in a single month isn’t going to slow down just because you’re tired of patching the same product again.