A public proof-of-concept exploit for CVE-2026-50522 dropped on July 20. Active exploitation started the same day. If you run on-premises SharePoint and applied the July 14 patch, you closed the door — but threat actors who already hit your server may have copied your machine keys and can still walk back in.
What CVE-2026-50522 Is
CVE-2026-50522 is a deserialization flaw in SharePoint’s SessionSecurityTokenHandler class, part of .NET’s Windows Identity Foundation token-processing framework. The CVSS score is 9.8. No authentication is required, no user interaction needed — an attacker posts a malicious BinaryFormatter payload to /_trust/default.aspx inside a forged WS-Federation sign-in response, and SharePoint deserializes it without adequate validation. The result is remote code execution on the server.
Affected versions are SharePoint Enterprise Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition — all on-premises only. SharePoint Online is not affected. A complicating factor: both the 2016 and 2019 versions reached end-of-support on July 14, 2026, the same day the patch dropped. Some organizations can apply the July update as their final-ever security fix; others have already fallen off the support cliff entirely.
Why the Patch Is Not the End of It
Most Patch Tuesday write-ups stop at “apply the update.” That is not enough here. SharePoint uses ASP.NET machine keys — the validationKey and decryptionKey — to sign and encrypt tokens, including ViewState data and authentication cookies. An attacker with RCE can read those keys out of the server configuration in seconds.
Once the keys are gone, the original exploit is irrelevant. With stolen machine keys, an attacker forges valid authentication tokens entirely offline. Those tokens are cryptographically indistinguishable from legitimate traffic. Patching closes the deserialization hole but does not invalidate keys already exfiltrated. As Help Net Security put it: the door is locked again, but the attacker printed a copy of the key before you changed the lock.
This is not theoretical. Active exploitation is specifically targeting machine key extraction, not just one-time code execution.
The Remediation Order Matters
You cannot patch and rotate keys in any order. Security researchers have documented “machine-key harvesters” — dormant scripts that attackers pre-position on compromised servers to steal new keys the moment they are rotated. Rotate before clearing the environment, and you hand attackers your new keys immediately.
The correct sequence:
- Apply the July 14, 2026 security update for your SharePoint version if not already done.
- Hunt for intrusion artifacts before touching keys. Check for unauthorized admin accounts, unexpected IIS processes, web shells in SharePoint directories, and POST requests to
/_trust/default.aspxin your IIS logs. - Confirm the environment is clean. Do not proceed to key rotation until malicious artifacts are removed.
- Rotate the ASP.NET machine keys in IIS Manager or via PowerShell for farm-wide rotation.
- Run
iisreset.exeto apply the new keys across the farm. - Enable AMSI integration for each SharePoint web application and set Request Body Scan Mode to Full.
The Broader Pattern
CVE-2026-50522 is the fourth on-premises SharePoint vulnerability actively exploited in the past month. The others: CVE-2026-56164 (CVSS 5.3), CVE-2026-58644 (CVSS 9.8), and CVE-2026-45659. CISA issued a hardening advisory on July 14 after the first three; a fourth CVE was exploited ten days later anyway.
Four CVEs in one month, all targeting on-premises SharePoint authentication, is not coincidental opportunism. SecurityWeek called it a “wave” — that framing is right. Someone is working through SharePoint’s authentication stack systematically, and patching individual CVEs as they surface is a reactive posture that cannot keep pace.
CISA added CVE-2026-50522 to the Known Exploited Vulnerabilities catalog on July 22, with a three-day remediation window for federal agencies. That federal deadline was July 25. Private-sector organizations face no mandatory deadline, but the operational risk is the same.
What to Check Right Now
- Confirm the July 2026 cumulative update is installed on every server in your SharePoint farm.
- Pull IIS logs and look for POST activity to
/_trust/default.aspxdating back to July 20. - Scan for web shells and unexpected scheduled tasks or processes on SharePoint servers.
- Follow the remediation sequence above — patch first, clean second, rotate third.
- If you are still on SharePoint 2016 or 2019, this CVE wave and the simultaneous end-of-support date make the migration case for you. That conversation cannot be deferred.
Applying the patch is table stakes. Rotating the machine keys after a confirmed-clean environment is the actual remediation work.
