SharePoint Has Another 9.8 Under Active Attack — and the Attackers Are Stealing Your Machine Keys, Which Means the Patch Alone Doesn't Get Them Out.
- Patrick Duggan
- 4 minutes ago
- 4 min read
Microsoft shipped a fix for CVE-2026-50522 on July 14. Within days it was under active exploitation, and the attackers are doing the one thing that turns a patch-and-move-on into a much longer night: they're stealing the server's machine keys. If you patch this and stop there, you may have locked a door on someone who already copied the key.
The bug
CVE-2026-50522 is a critical deserialization-of-untrusted-data flaw in on-premises Microsoft SharePoint — Enterprise Server 2016, Server 2019, and Subscription Edition. It rates 9.8, and it is pre-authentication: an attacker sends a specially crafted serialized object to a vulnerable endpoint, with no login and no user interaction, and the server executes their code in its own context. Full server takeover, web shells, theft of application secrets, and a foothold for lateral movement across the network. It was found by a DEVCORE researcher, and it moved from theoretical to in-the-wild fast once a public proof-of-concept dropped — watchTowr has reported the active exploitation.
If you run on-prem SharePoint exposed to the internet and you haven't applied the July 14 update, treat that as a tonight problem. This is pre-auth, it's 9.8, and the exploit is public.
The part that matters more than the patch: machine keys
Here's the detail that separates the people who recover cleanly from the people who get hit again next month. The observed attacks aren't just running code — they're stealing the SharePoint server's ASP.NET machine keys (the validationKey and decryptionKey).
Those keys are the secret SharePoint uses to sign and encrypt things it trusts — authentication tokens, __VIEWSTATE, the plumbing that lets the server believe a request is legitimate. An attacker who has your machine keys doesn't need the vulnerability anymore. They can forge valid, signed payloads — craft their own trusted __VIEWSTATE, mint authentication material — and walk back in through the front door as a request the server has no reason to distrust. Persistence that survives a reboot, survives a web-shell cleanup, and survives the patch, because the patch closes the deserialization hole while the stolen keys are a completely separate door.
This is the exact lesson from the SharePoint "ToolShell" wave earlier this cycle, and it's the one defenders keep skipping because it isn't in the advisory's headline. Patching [CVE-2026-50522](https://analytics.dugganusa.com/api/v1/dredd/kev-gap?cve=CVE-2026-50522) is necessary and not sufficient. If an attacker reached your server before you patched, assume they took the keys, and the only thing that evicts them is to rotate the machine keys — after you've confirmed the server is clean, so you're not just handing fresh keys to someone still resident.
What to actually do, in order
Patch to the July 14 update on every on-prem SharePoint instance — 2016, 2019, Subscription Edition. If you can't patch in the next hours and the instance is internet-facing, get it off the public internet behind a VPN or allowlist until you can, because the entire attack depends on reaching it.
Then assume compromise if that server was exposed and unpatched at any point since mid-July, and hunt accordingly: web shells in the SharePoint layout and _vti_bin directories, unexpected w3wp.exe child processes, new or modified files under the SharePoint hive, and outbound connections from the web tier you can't explain. Pull IIS and SharePoint ULS logs back to July 14 and look for the crafted requests to the vulnerable endpoint.
And the step people miss: rotate the ASP.NET machine keys once you've established the box is clean. New validationKey and decryptionKey, pushed across the farm. Until you do, a patched server can still be re-entered with keys stolen before the fix — and you will read the re-entry as a mysterious new breach when it's actually the same one you thought you closed.
One note on our own coverage, for honesty: CVE-2026-50522 is not yet in the CISA KEV catalog as of this writing (its sibling from the same July batch, CVE-2026-58644, already is). When 50522 lands there, our feed picks it up automatically — but a KEV listing is a formality trailing behind exploitation that's already happening. Don't wait for the catalog to tell you what watchTowr already has.
We hold this at 95 percent, as always — the vulnerability, the exploitation reporting, and the machine-key-theft behavior are Microsoft's advisory and the work of DEVCORE and watchTowr, corroborated by the trade press, not our own capture. There's no single IP to block here; the indicator that matters is your own patch state and, if you were exposed, whether you rotated the keys. The bug is the door. The stolen keys are the copy of your key the burglar made on the way out — and changing the lock is the part nobody remembers until they're standing in the same ransacked room a second time.
Sources: CVE-2026-50522 via The Hacker News, Censys, and watchTowr's active-exploitation reporting; Microsoft advisory published July 14, 2026; discovered by DEVCORE. Machine-key theft as an observed persistence mechanism per that reporting. CVE-2026-58644 (same July batch) is in our CISA KEV mirror; CVE-2026-50522 is not yet listed as of publication.
Every indicator in this post is in the feed. Free.
1.58M+ IOCs, STIX 2.1 / TAXII, 88% novel vs ThreatFox, exploited-CVE leads ahead of CISA. No credit card — a free API key in 30 seconds, and you can audit every claim above against the live endpoints.
Comments