CVE-2026-50522: SharePoint Deserialization RCE Now Actively Exploited (CISA KEV) — Detect Exposure and Evict Persistence

The unauthenticated SharePoint remote code execution flaw first demonstrated at Pwn2Own Berlin 2026 is now being exploited in the wild. On July 22, 2026, CISA added CVE-2026-50522 to its Known Exploited Vulnerabilities catalog with a three-day remediation deadline, days after a public proof-of-concept appeared and honeypot networks recorded successful compromise attempts. It is a CVSS 9.8 Critical deserialization bug (CWE-502) in on-premises SharePoint Server, and the operationally important detail is this: because attackers are stealing SharePoint machine keys during exploitation, installing the July patch closes the door but does not evict an intruder who already walked through it. This is the one to treat as an incident, not just a patch.

The Vulnerability

CVE-2026-50522 is a deserialization-of-untrusted-data vulnerability (CWE-502) in Microsoft SharePoint Server's federated-authentication path. An unauthenticated attacker sends a crafted request that causes SharePoint to deserialize attacker-controlled .NET data, executing arbitrary code as the SharePoint service account. Microsoft's vector marks it PR:N (no privileges) and UI:N (no user interaction) — a pre-authentication, low-complexity network RCE. It was patched on July 14, 2026, as part of the same Patch Tuesday batch as its near-twin CVE-2026-58644; what separates 50522 is that it has now crossed from proof-of-concept to confirmed in-the-wild exploitation.

From Pwn2Own Demo to In-the-Wild Exploitation

A precise timeline matters here, because it determines how you should think about risk — and it argues against calling this a zero-day. Microsoft shipped the fix on July 14. Independent telemetry from Defused reported matching unauthenticated request patterns beginning July 17. A public proof-of-concept surfaced around July 20, and watchTowr reported that its honeypot network recorded successful exploitation attempts within hours of the PoC's release. CISA added the CVE to KEV on July 22. Because the earliest observed exploitation postdates the patch, current evidence points to rapid n-day weaponization — attackers reverse-engineering the fix and racing unpatched servers — not confirmed pre-patch, zero-day use.

The practical takeaway is the compressed window. The gap between "patch available" and "mass exploitation of a public PoC" was roughly six days. Any internet-reachable SharePoint Server that was not patched in that window should be considered a candidate for compromise, not merely a candidate for patching. No threat actor, nation-state, or ransomware operation has been credibly attributed to this activity — and the Linen Typhoon / Violet Typhoon actors named in the separate 2025 ToolShell campaign should not be assumed here.

The Mechanism: A Forged Token at the Trust Endpoint

Microsoft's advisory withholds exploitation detail, so the following mechanism is drawn from public analysis of the released proof-of-concept and the ZDI advisories — treat the specifics as researcher-reported rather than vendor-confirmed. The vulnerable surface is SharePoint's WS-Federation sign-in handling. An attacker POSTs a crafted federated sign-in response to the /_trust/default.aspx endpoint, carrying a forged SecurityContextToken whose cookie contains attacker-controlled serialized .NET data. SharePoint's SessionSecurityTokenHandler deserializes that data without adequately validating it — and the token path does not properly verify the cryptographic signature that is supposed to make forgery impossible. A BinaryFormatter gadget chain in the payload then executes as the SharePoint application-pool account.

One detail worth noting for anyone cross-referencing advisories: ZDI maps two distinct research reports to this single CVE — ZDI-26-412 (unsafe deserialization in SessionSecurityTokenHandler) and ZDI-26-413 (improper signature verification). The two are complementary: the signature-verification weakness is what lets the attacker present a forged token in the first place, and the deserialization weakness is what turns that forged token into code execution.

Why Patching Isn't Enough: Machine-Key Theft

This is the part that makes CVE-2026-50522 an incident-response problem rather than a routine patch, and it is the single most important operational point in this post. Security researchers observed that, after gaining execution, attackers pull the SharePoint server's machine keys — the ASP.NET validation and decryption keys used to sign and encrypt __VIEWSTATE and authentication tokens — often in a single request. To be precise about the boundary: the machine-key theft is post-exploitation activity, not the vulnerability itself. But its consequence is what defenders must internalize:

Once an attacker holds your machine keys, they can craft cryptographically valid payloads that SharePoint trusts, indefinitely — no re-exploitation of the original bug required. The July update closes the deserialization entry point, but it does not rotate the keys an intruder may already have exfiltrated. Any server that was internet-reachable and unpatched during the exploitation window must therefore be treated as potentially compromised: patch, then rotate machine keys, then hunt. This is the same lesson the 2025 SharePoint campaign taught — organizations that patched but never rotated keys were re-entered afterward.

Not ToolShell — But the Same Endgame

It is tempting to file this under "ToolShell," and the comparison is instructive as long as you do not conflate them. ToolShell is a 2025 exploit chain — CVE-2025-53770 and CVE-2025-53771 — that targeted a different endpoint (/_layouts/15/ToolPane.aspx with a spoofed Referer). CVE-2026-50522 is a distinct 2026 vulnerability in a different code path. What the two share is the endgame: unauthenticated RCE on on-prem SharePoint followed by machine-key theft for durable persistence. The recurring structural problem is that on-premises SharePoint holds long-lived cryptographic secrets on the same box that keeps exposing pre-auth code-execution surfaces — so any successful server-level RCE against it should be treated as a potential machine-key compromise, not just code execution. Do not label 50522 as ToolShell or reuse the 2025 CVE numbers; do borrow the 2025 remediation muscle memory.

Investigation Workflow: Find Exposed SharePoint

Because this is an unauthenticated, network-reachable RCE under active exploitation, any SharePoint Server you can reach, an attacker can too. The first job is inventory and patch-state verification across every farm you run — including the shadow deployments that never made it into the asset database. Passive discovery (Shodan, certificate-transparency logs, passive DNS) surfaces candidates without touching them; active checks (connecting to a port, requesting a page) are direct interactions and should be run only against systems you own or are authorized to assess.

1. Port Scan: Find SharePoint Instances

SharePoint Server runs on IIS and exposes web services on standard and service-specific ports:

• • 443 — HTTPS, the primary web-application port
• • 80 — HTTP, often redirecting to 443
• • 32843 / 32844 — SharePoint service-application endpoints
• • Central Administration runs on an operator-chosen port (often a high random port), so there is no single fixed port to scan for it

2. HTTP Headers & Endpoints: Fingerprint SharePoint and Read the Build

SharePoint returns distinctive response headers, and one of them tells you patch state directly — no authentication required:

• • MicrosoftSharePointTeamServices — the exact build number (e.g. 16.0.19725.20434). Compare it against the patched builds below to determine vulnerability
• • X-SharePointHealthScore — a numeric value unique to SharePoint
• • SPRequestGuid — a GUID present in SharePoint responses
• • Response bodies referencing _layouts/15/ or _api/web, and a reachable /_trust/default.aspx sign-in endpoint

Patched builds: 16.0.19725.20434 (Subscription Edition), 16.0.10417.20175 (2019), 16.0.5561.1001 (2016). Any build below these is unpatched against CVE-2026-50522 — the same builds that determine status for the rest of the July SharePoint cluster.

3. TLS Inspect: Identify SharePoint Certificates

Pull the certificate on port 443 and look for a subject CN or SAN containing sharepoint, sp, intranet, or portal, an issuer from an internal Active Directory Certificate Services CA, or wildcard certificates covering internal domains. Certificate-transparency logs are a passive source for the same signal and often reveal deployments inventory tools miss.

4. DNS: Discover SharePoint Infrastructure

Query DNS for the naming patterns operators use for collaboration platforms: sharepoint.*, sp.*, intranet.*, portal.*, teams.*, collab.*, mysites.*. SharePoint farms often span multiple web applications with separate DNS entries.

5. CVE Lookup: Track the Cluster and Its KEV Status

Track CVE-2026-50522 alongside the other July 2026 Patch Tuesday SharePoint CVEs — CVE-2026-58644 and CVE-2026-56164, plus the security-feature-bypass CVE-2026-55040 — all fixed by the same July 14 cumulative updates, so a single patch pass closes the batch. CVE-2026-45659 is a related but distinct earlier SharePoint deserialization flaw (authenticated, KEV-listed July 1, patched before the July batch) worth tracking separately.

Cross-Reference with External Data

Remediation

1. Patch now. Install the July 14 security updates: KB5002882 (Subscription Edition), KB5002883 (SharePoint 2019), KB5002891 (SharePoint 2016). Confirm the resulting MicrosoftSharePointTeamServices build meets or exceeds 16.0.19725.20434 (SE), 16.0.10417.20175 (2019), or 16.0.5561.1001 (2016). With a July 25 KEV deadline, this is not a next-maintenance-window task.
2. Rotate machine keys after patching. This is the step most defenders miss. Patching does not invalidate keys an attacker may have already stolen. Regenerate the farm's ASP.NET validation/decryption keys — via the Set-SPMachineKey and Update-SPMachineKey cmdlets or the Central Administration Machine Key Rotation timer job — then run iisreset across all servers. Rotate after patching so the entry point is closed first.
3. Assume compromise for any exposed, unpatched server and hunt. If a SharePoint server was internet-reachable and unpatched after July 17, investigate it. Look for unexpected files under the SharePoint web roots and _layouts directories (webshells), anomalous w3wp.exe child processes, POST requests to /_trust/default.aspx in IIS logs, and unusual outbound connections. When in doubt, engage incident response rather than assuming the patch was sufficient.
4. Enable AMSI and restrict exposure. Turn on SharePoint's Antimalware Scan Interface integration (Full request-body scan mode on Subscription Edition) for defense-in-depth against deserialization payloads, and place any farm that does not need public access behind a VPN or authenticating reverse proxy.
5. Plan migration for SharePoint 2016 and 2019. July 2026 is the final security update for both. Future vulnerabilities in these versions will go unpatched — plan a move to Subscription Edition or SharePoint Online.

Sources

• → Microsoft Security Update Guide: CVE-2026-50522
• → NVD: CVE-2026-50522
• → CISA Known Exploited Vulnerabilities Catalog (added July 22, 2026)
• → ZDI-26-412 (deserialization) and ZDI-26-413 (signature verification)
• → BleepingComputer: SharePoint RCE exploited to steal machine keys
• → KB5002882 / KB5002883 / KB5002891 — July 14, 2026 SharePoint updates