SharePoint RCE CVE-2026-50522: Public PoC Triggers Active Exploitation and Machine Key Theft on On-Prem Servers
TL;DR
  • 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

  1. 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.
  2. 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 run iisreset. Rotating before you patch is pointless because a still-vulnerable server leaks the new keys too.
  3. Reset and rotate related credentials for service accounts and any secrets that touched the affected servers, since forged tokens may have granted broader access.
  4. Hunt for the exploitation signature. Inspect IIS logs for POST requests to /_trust/default.aspx carrying WS-Federation sign-in responses, especially from unexpected external sources, dating back to July 17.
  5. Watch for BinaryFormatter deserialization artifacts and unexpected w3wp.exe child processes on SharePoint hosts. Deserialization RCE commonly spawns command interpreters or scripting hosts from the IIS worker process.
  6. 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.
  7. 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.aspx since July 17.
  • Rotate service-account credentials that touched affected hosts.
  • Run EDR hunt for anomalous w3wp.exe child 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


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?
CISOPlatform is a free community of senior security leaders covering breach postmortems, playbooks, and peer discussions. Join free: https://www.cisoplatform.com/main/authorization/signUp. Browse the CISO fireside chat archive for practitioner conversations on attack surface, deserialization, and incident response.

Sources

Votes: 0
E-mail me when people leave their comments –

Priyanka Aash is Co-Founder of CISO Platform, the world's first online community for information security executives, and Co-Founder of FireCompass. She has been nominated for the Cybersecurity Excellence Award for leadership and AI innovation in cybersecurity, honored with the NetApp Excellerate HER award, and featured in SC Media's Women in IT Security series. She is the author of The AI Divide. Security technologist Bruce Schneier advises FireCompass.

You need to be a member of CISO Platform to add comments!

Join CISO Platform

Join The Community Discussion