- CVE-2026-50522 is a CVSS 9.8 deserialization flaw in on-premises Microsoft SharePoint Server. A public PoC landed July 20, 2026 and active exploitation began within hours.
- Machine key theft is the payoff. Attackers pull SharePoint IIS machine keys in a single request, then forge authentication tokens that survive patching.
- CISA added it to the KEV catalog on July 22, 2026, with a federal remediation deadline of July 25. This is the third SharePoint flaw exploited in the July wave.
- If you do one thing today: patch, then rotate machine keys. A patch alone does not evict an attacker who already has your keys.
A third SharePoint Server vulnerability from Microsoft's July 2026 Patch Tuesday is now under active exploitation. CVE-2026-50522 was not flagged as exploited when the fix shipped, but that changed fast once a working proof-of-concept became public. Offensive security firm watchTowr reported compromises within hours of the PoC appearing, and CISA added the CVE to its Known Exploited Vulnerabilities catalog on July 22.
The attack does more than pop a shell. It steals the cryptographic material SharePoint uses to sign and validate tokens, which lets attackers keep access even after you apply the update. That detail is what makes this one worth a same-day response rather than a routine patch cycle entry.
What happened
Microsoft patched CVE-2026-50522 in its July 2026 security updates and tagged it "Exploitation More Likely," with a CVSS score of 9.8. The flaw is a deserialization of untrusted data in Microsoft Office SharePoint. Microsoft credited DEVCORE researcher "splitline" with the report.
On July 20, watchTowr identified public PoC exploit code. According to the firm, its Attacker Eye honeypot network captured exploitation attempts using that PoC within hours, and those attempts successfully compromised target systems. Separately, early-warning intelligence firm Defused reported detecting an undocumented SharePoint deserialization vector in attacks as early as July 17, activity it later assessed was likely CVE-2026-50522.
CISA added CVE-2026-50522 to the KEV catalog on July 22, 2026, requiring Federal Civilian Executive Branch agencies to remediate by July 25. This is the third SharePoint Server flaw to see active exploitation in the past month, following CVE-2026-56164 (CVSS 5.3) and CVE-2026-58644 (CVSS 9.8), both weaponized as zero-days before the July fixes.
Technical root cause and attack chain
The vulnerability sits in an unsafe .NET deserialization path reached through SharePoint's authentication surface. A publicly available PowerShell PoC from researcher Janggggg triggers RCE by delivering a malicious .NET BinaryFormatter payload as the cookie of a forged SecurityContextToken, wrapped in a WS-Federation sign-in response and posted to SharePoint's /_trust/default.aspx endpoint. When the vulnerable deserialization path processes that token, the payload executes as arbitrary code on the server.
One note on the authentication precondition
The sources are not fully aligned here, so treat this as a point to verify in your own environment. Microsoft's advisory language quoted by The Hacker News describes an attacker "authenticated as at least a Site Owner" writing arbitrary code. Defused, however, reported that the captured requests "carry no authentication material," matching an unauthenticated profile, and BleepingComputer characterized the flaw as allowing remote code execution without authentication. Whether or not a low-privilege foothold is required, the observed real-world traffic did not appear to carry credentials, which raises the practical severity. Do not assume authentication is a meaningful barrier here.
Why patching alone is not enough
The exploitation goal is persistence, not just code execution. watchTowr reported that attackers are "pulling SharePoint machine keys via a single request." SharePoint uses ASP.NET machine keys (the validationKey and decryptionKey) to sign and encrypt tokens including ViewState and the SecurityContextToken. An attacker who exfiltrates those keys can forge valid authentication tokens offline, impersonate any user, and re-enter the environment with legitimate-looking credentials. Applying the July update closes the deserialization hole, but it does not invalidate keys an attacker already copied.
What it means for security teams
If you run on-premises SharePoint Server (Subscription Edition, 2019, or 2016), assume this is in scope. CISA's earlier guidance on the related SharePoint flaws named RCE plus post-exploitation activity such as stealing IIS machine keys and deserialization for persistence, so the TTPs here fit a pattern already in the wild. SharePoint Online is not affected; the exposure is your self-managed, internet-reachable deployments.
The compressed timeline matters. PoC to mass exploitation happened in hours, not days. If your servers were exposed to the internet between roughly July 17 and the moment you patched, you should be running compromise assessment, not just confirming the update installed.
Remediation and detection
- Apply the July 2026 SharePoint security updates to all on-prem Subscription Edition, 2019, and 2016 servers immediately. Confirm the build number reflects the July cumulative update on every server in the farm, not just the primary.
- Rotate ASP.NET machine keys after patching. In SharePoint, use
Update-SPMachineKey(or the Set-SPMachineKey / rotate workflow appropriate to your version) across the farm, then runiisreset. Rotating before you patch is pointless because a still-vulnerable server leaks the new keys too. - Reset and rotate related credentials for service accounts and any secrets that touched the affected servers, since forged tokens may have granted broader access.
- Hunt for the exploitation signature. Inspect IIS logs for POST requests to
/_trust/default.aspxcarrying WS-Federation sign-in responses, especially from unexpected external sources, dating back to July 17. - Watch for BinaryFormatter deserialization artifacts and unexpected
w3wp.exechild processes on SharePoint hosts. Deserialization RCE commonly spawns command interpreters or scripting hosts from the IIS worker process. - Restrict external access to SharePoint authentication endpoints where business need does not require them, and put the farm behind a reverse proxy or WAF that can inspect the
/_trust/path. - Enable and centralize ULS and IIS logging if not already, and retain enough history to answer "were we exploited before we patched."
If you do one thing today: patch every on-prem SharePoint server, then rotate machine keys farm-wide. The patch fixes the door; the key rotation changes the locks the attacker may already hold.
Immediate action checklist
- Inventory all internet-reachable on-prem SharePoint servers (Subscription Edition, 2019, 2016).
- Apply July 2026 updates and verify build numbers farm-wide.
- Rotate ASP.NET machine keys after patching, then
iisreset. - Grep IIS logs for POST to
/_trust/default.aspxsince July 17. - Rotate service-account credentials that touched affected hosts.
- Run EDR hunt for anomalous
w3wp.exechild processes. - Confirm CVE-2026-50522 remediation against KEV before the July 25 federal deadline if applicable.
Community Note
Internet-exposed SharePoint that you did not know was reachable is the recurring theme across the July wave. Most teams patched the primary farm but missed a secondary or forgotten server. If you want to validate what your SharePoint and broader web-facing footprint actually looks like from the outside, FireCompass Free Explorer runs a free self-serve AI pen test with no asset list and no credit card, which the community can use to spot exposed services before an attacker does.
Related on CISOPlatform
- Microsoft July 2026 Patch Tuesday: 570 Fixes, Exploited AD FS and SharePoint Zero Days Land in CISA KEV
- Breach Watch: Chick-fil-A Credential Stuffing, Stadler Ransom, Korea Diplomat Hack (July 22, 2026)
- CISO FireSide Chat: A CISO's Guide On How To Manage A Dynamic Attack Surface With Rick Doten
Join the Discussion
Questions for the practitioners in the room:
- Have you rotated SharePoint machine keys as standard post-incident practice, or only when a CVE forces it? What broke when you did?
- How are you detecting forged SecurityContextToken use after the fact, given the tokens validate cleanly against stolen keys?
- For anyone who caught pre-patch exploitation between July 17 and 20, what log source gave you the earliest signal?
Sources
- CISA: Adds Two Known Exploited Vulnerabilities to Catalog (July 22, 2026)
- The Hacker News: Critical SharePoint RCE CVE-2026-50522 Under Active Exploitation After Public PoC
- BleepingComputer: Critical SharePoint RCE flaw exploited to steal machine keys
- Help Net Security: Another SharePoint RCE exploited, patch then rotate your machine keys
- SOCRadar: CVE-2026-50522 PoC Fuels SharePoint Attacks

Comments