Last week Microsoft shipped a fix for CVE-2026-50522, a CVSS 9.8 SharePoint RCE flaw that requires no authentication. Within hours of a public proof-of-concept appearing on July 20, attackers were already inside on-premise servers, stealing the machine keys that authenticate every user token those servers issue. If your SharePoint farm was reachable before you patched, someone may already hold a master key to your collaboration stack.
Patching this vulnerability is necessary but not sufficient. The real danger is post-patch persistence through stolen machine keys.
Microsoft describes CVE-2026-50522 as a deserialization-of-untrusted-data flaw that allows a remote attacker to execute code over a network without credentials. The patch landed in July's security updates, and BleepingComputer's reporting noted that Microsoft's advisory flagged an increased likelihood of exploitation even though the company did not mark it as actively exploited at release time. That assessment aged badly within days.
What is CVE-2026-50522 and how does the exploit chain work?
The vulnerability lives in how SharePoint processes incoming WS-Federation sign-in responses. An attacker sends a crafted POST request to SharePoint's /_trust/default.aspx endpoint. Inside that request, they embed a forged SecurityContextToken with a malicious .NET BinaryFormatter payload stuffed into a cookie. When a vulnerable SharePoint server deserializes that token, the payload executes arbitrary code on the server under the SharePoint application pool identity.
No credentials needed. No user interaction required. The attack travels over the network to any internet-facing SharePoint endpoint that trusts WS-Federation tokens, which is the default configuration for many on-premise deployments.
Security researcher Janggggg published a PowerShell proof-of-concept on GitHub on July 20. BleepingComputer reviewed the code and found it structurally and technically legitimate, though they did not test it against a live target. The PoC demonstrates the full chain: forge the token, deliver the BinaryFormatter payload, trigger deserialization, and pop a shell on the SharePoint server.
The exploit is straightforward. A competent operator can adapt it in an afternoon. Once code execution lands on a SharePoint server, the attacker targets key theft. Defacement and data exfiltration are secondary concerns when you can walk out with the cryptographic material that signs every authentication token the server issues.
How fast did attackers weaponize the patch?
The timeline is ugly. watchTowr, an offensive security company, runs a global honeypot network called Attacker Eye. On July 20, the same day the PoC went public, watchTowr's sensors captured exploitation attempts that successfully compromised target systems within hours of the exploit code appearing online.
But the story starts earlier. Defused, an early warning threat intelligence firm, detected what it called an undocumented SharePoint deserialization vector on July 17, three days after Microsoft shipped the patch. Defused could not immediately link the activity to CVE-2026-50522, but on July 21 the company confirmed that the attacks were likely driven by this specific vulnerability. Someone was exploiting the flaw before the public PoC existed.
The chart above shows the compressed window between patch availability and active exploitation. Microsoft shipped the fix on July 14, Patch Tuesday. Defused detected attacks three days later. The PoC went public on July 20, and mass exploitation followed the same day. If your team took a week to test and deploy the SharePoint update, attackers had a head start.
This pattern mirrors what we have tracked across recent critical CVEs. The SharePoint CVE-2026-45659 patch clock was already a three-day scramble. CVE-2026-50522 compresses that window further because the PoC arrived immediately and the attack chain targets persistence, not just entry.
What does SharePoint machine key theft mean for your environment?
Machine keys in SharePoint are the cryptographic material that signs and validates authentication tokens. When an attacker steals them, they can forge tokens that look identical to legitimate ones. Your patched server will accept those tokens because the signature is valid. The server has no way to distinguish a token signed by an attacker holding the machine key from one signed by the server itself.
This is why patching alone does not close the hole. You removed the deserialization vulnerability, but the attacker who got in before you patched now holds a key that works regardless of the patch status. They can impersonate any user, access any SharePoint site, and pull documents with the privileges of whichever identity they forge.
The attacker does not need to keep sending malicious payloads. They do not need a webshell. They do not need a backdoor that your EDR might catch. They need one forged token, and your server validates it because the machine key matches. This is silent, durable access that survives reboots, patching, and routine security sweeps.
For on-premise SharePoint farms, the exposure surface is significant. Internet-facing SharePoint deployments, partner portals, and extranet sites that accept WS-Federation tokens are all potential targets. SharePoint Online is not affected by this specific vulnerability, but hybrid configurations that bridge on-premise and cloud may still have exposed endpoints that an attacker can reach.
The practical question for your environment: was your SharePoint server reachable between July 14 and the day you applied the update? If yes, assume the keys are compromised and treat the server as breached.
What should you do beyond applying the patch?
Three steps, in order, and the order matters:
- Rotate SharePoint machine keys immediately. This is the single most important action. Microsoft's documentation covers the process for regenerating validation and decryption keys. Rotating keys invalidates any forged tokens an attacker created with the stolen material. Every token signed with the old key becomes worthless the moment the new key takes effect.
- Hunt for persistence before you rotate. If you rotate keys first, you tip off the attacker that you know. They may pivot to other persistence mechanisms before you find them. Check SharePoint timer service jobs, custom web parts, feature receivers, and any recently modified assemblies in the global assembly cache. Look for scheduled tasks or services running under the SharePoint application pool identity that you did not create.
- Review authentication logs for forged token activity. Look for tokens issued outside normal patterns: access from unexpected IP ranges, tokens with elevated privileges that were never assigned through standard processes, or authentication events that bypassed your identity provider entirely. If you see forged token usage, the breach is already active and you need incident response, not just patching.
For teams running hybrid SharePoint environments, audit your federation trust configuration. If your on-premise farms trust tokens from external identity providers, verify that the trust relationship has not been abused. Check the token signing certificates on both sides of the bridge.
Patch every SharePoint server, including development and staging environments that may share machine keys with production. Attackers who compromise a dev box can steal the same keys and use them against production if the keys match. This is a common configuration mistake in farms that were cloned from a template.
If your incident response team is involved, prioritize key rotation and log review over forensic timeline reconstruction. The attacker may still be actively using forged tokens. Every hour you spend on timeline work without rotating keys is an hour the attacker keeps access.
The patch was never the finish line
The default response to a critical CVE is "patch and move on." CVE-2026-50522 breaks that script because the exploit targets the one thing patching cannot fix: cryptographic material that an attacker already stole. Your patched server stops new intrusions. An attacker who already has the keys to the front door can still walk in.
The operators who sleep well after this one are the ones who rotated their machine keys, hunted for persistence, and verified their authentication logs. Everyone else applied a patch and left the door unlocked.
Sources
- bleepingcomputer.com - Critical SharePoint RCE flaw exploited to steal machine keys
