CVE-2026-50522: patch, hunt, then rotate the machine keys
Unauthenticated RCE in on-prem SharePoint via a forged security token. Patching is step one; if the box was exposed, the ASP.NET machine keys need rotating too, in the right order.
01 The Big PictureFor leadership · no jargon
Okay, so this one is the SharePoint bug that went from Patch Tuesday to active exploitation in under a week. This guide walks through what it actually is, how to check your farm, and the bit most people miss: patching alone does not close it.
On-premises SharePoint has a special front door where it accepts "this person is who they say they are" tokens from trusted login systems, which is how single sign-on works. Think of it as a receptionist who accepts visitor badges printed by partner companies: convenient, as long as the receptionist checks the badge properly. CVE-2026-50522 means they don't. An anonymous stranger can hand over a forged badge with a booby-trapped note tucked inside, and the receptionist doesn't just read the note, they act on it. One web request, no login, no user interaction, and the attacker is running their own code on your SharePoint server. Yikes.
It gets worse, and this is the part that matters for your weekend. Within hours of public exploit code appearing (July 20th, six days after the patch), attackers were using it to steal the server's ASP.NET machine keys: the master stamp SharePoint uses to sign its own tokens and pages. With those keys, an attacker can mint valid-looking requests even after you patch. So the fix has three acts, in this order: patch, hunt for footprints, then rotate the keys. Rotate first and you may simply be handing a still-resident intruder a fresh stamp.
The work itself is a security update, the SharePoint configuration wizard, a log review and a key rotation. Hours per farm, with a reboot or two. The honest trade-offs live in the update's known issues (some farms see repeated sign-in prompts and broken workflow status links afterwards), and they're covered below, because the alternative is leaving a CVSS 9.8, actively exploited, CISA-flagged hole facing the internet.
02 Technical BreakdownFor engineers
Right, let's get into the nitty-gritty. The root cause sits in SharePoint's SessionSecurityTokenHandler class (CWE-502, deserialization of untrusted data), per ZDI-26-412. SharePoint's WS-Federation trust endpoint, /_trust/default.aspx, accepts a RequestSecurityTokenResponse in the wresult parameter. The public exploit chain forges one of these containing a SecurityContextToken whose cookie element carries a deflated, Base64-encoded .NET BinaryFormatter payload. SharePoint helpfully deserialises it inside the IIS worker process (w3wp.exe), and that's code execution as the application pool identity. Neat trick, horrible outcome.
On authentication, a small public disagreement worth knowing about: Microsoft's own FAQ text says the attacker needs to be "at least a Site Owner", but Microsoft's CVSS vector says PR:N, ZDI says authentication is not required, and observed attacks carry no authentication material at all. Treat it as unauthenticated; the FAQ reads like copy-paste drift to me, but either way, assume the worst case is true, cos the honeypots are watching it happen.
The timeline is the spicy part. Reported to Microsoft on May 21st by splitline of DEVCORE Research Team; patched July 14th (Patch Tuesday); ZDI advisory July 15th; public PoCs July 20th (a Python mass-scan one by 4minx on GitHub and a PowerShell one by Janggggg, which is why things escalated fast; a fair warning that the 4minx one in particular is unverified, and at least one aggregator flags it as a possible fake, so handle with care); active exploitation observed by watchTowr and Defused Cyber the same day; CISA KEV on July 22nd with a July 25th federal deadline. Censys mapping put roughly 1,500 internet-facing vulnerable instances out there, mostly SharePoint 2019, per reporting at the time.
And the persistence trick: post-exploitation, a single request lifts the ASP.NET machine keys (validationKey / decryptionKey). Those keys sign and encrypt ViewState and auth cookies, so an attacker holding them can forge requests that look legitimate to a fully patched server. This is why every serious writeup on this CVE converges on the same sequence: patch, hunt, evict, then rotate the keys. Rotating while an intruder still has a foothold just gives them a fresh key to steal, so the order is load-bearing.
03 Affected
On-premises SharePoint only: Subscription Edition, Server 2019 and Enterprise Server 2016, x64. SharePoint Online is not affected. Exploitation needs nothing more than network reachability to the trust endpoint: no credentials, no user interaction.
Anything internet-facing is the priority, but don't skip internal farms either; one phished laptop plus an unpatched internal SharePoint is the same bug with extra steps. The July 14th, 2026 security update closes it:
| Product | Fixed build | KB | |---|---|---| | SharePoint Server Subscription Edition | 16.0.19725.20434 | KB5002882 | | SharePoint Server 2019 | 16.0.10417.20175 | KB5002883 | | SharePoint Enterprise Server 2016 | 16.0.5561.1001 | KB5002891 |
04 Detection
Before we change anything, let's see what we're dealing with. First, the build number:
Get-SPFarm | Select-Object Name, BuildVersionRun in the SharePoint Management Shell. Compare against the table above: anything below the fixed build for your SKU is live exposure.
Select-String -Path 'C:\inetpub\logs\LogFiles\W3SVC*\*.log' -Pattern '_trust/default\.aspx' | Select-Object -Last 20 Line Requests to the trust endpoint from sources you don't recognise are the fingerprint; the malicious payload rides in the POST body (wresult), which IIS doesn't log, so treat unexpected hits themselves as the signal and check source IPs and timing.
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4688} -MaxEvents 5000 | Where-Object { $_.Message -match 'w3wp\.exe' -and $_.Message -match 'powershell|cmd\.exe|certutil' } | Select-Object -First 10 TimeCreated, Message The IIS worker process spawning shells or download cradles is the classic post-exploitation move; the public PoC calls out to powershell.exe Invoke-WebRequest for its callback.
Get-ChildItem 'C:\Program Files\Common Files\microsoft shared\Web Server Extensions\16\TEMPLATE\LAYOUTS' -Filter *.aspx | Sort-Object LastWriteTime -Descending | Select-Object -First 10 Name, LastWriteTimeRecently written .aspx files in LAYOUTS that you did not deploy are web shells until proven otherwise. Investigate before you clean.
Get-WinEvent -FilterHashtable @{LogName='Security'; Id=4663} -MaxEvents 2000 -ErrorAction SilentlyContinue | Where-Object { $_.Message -match 'machineKey|web\.config' } | Select-Object -First 10 TimeCreated, MessageUnexplained reads of machine key material or web.config by accounts that shouldn't be near them point at the key-theft stage. This one needs object access auditing enabled beforehand, so no results may just mean no auditing.
If any of these light up on a server that was unpatched and reachable, stop here and treat it as an incident, not a patching exercise. The hunt comes before the key rotation for a reason.
05 Remediation
01 Install the July 2026 security update
Apply the KB for your SKU from the table above, through your normal rings or manually from the Microsoft Update Catalog. Reboot "maybe" required, says Microsoft, so plan for one and be pleasantly surprised otherwise.
Get-HotFix | Sort-Object InstalledOn -Descending | Select-Object -First 5 HotFixID, InstalledOnConfirm the KB actually landed before you touch the wizard.
Then, the step everyone forgets: run the SharePoint Products Configuration Wizard on every server in the farm. Installing the binary alone does not finish the update; the wizard upgrades the databases and features, and skipping it leaves you half-patched with a false sense of security.
PSConfig.exe -cmd upgrade -inplace b2b -waitOr walk through the GUI wizard if you prefer. One farm server at a time, starting with the one hosting Central Administration.
Known issues in the July 2026 update, straight from the KB pages, so they don't surprise you on Monday: multi-WFE farms using Trusted Provider or Forms auth can get repeated sign-in prompts (fix with sticky sessions on the load balancer; Microsoft explicitly warns against disabling SessionCookieTransformProtectionEnabled as a workaround, as it reopens security holes), workflow status links can break (WrkStat.aspx throwing "The WorkflowInstanceID parameter is invalid"), and farms with SharePoint Workflow Manager must install KB5002799 before this update.
02 Rotate the ASP.NET machine keys
Only after the hunt above comes back clean (or after eviction, if it didn't). Rotating keys with an intruder still on the box just hands them the fresh set, so the ordering is the whole point.
Update-SPMachineKey Run in the SharePoint Management Shell, then follow with iisreset on each server; the rotation doesn't take effect until the worker processes restart.
This will invalidate existing sessions and ViewState, so users get logged out once. A small price, as prices for evicting APTs go.
03 Harden the edges
Two compensating controls worth doing while you're in there. Enable AMSI integration for each SharePoint web application (Central Administration, Manage web applications, security settings); the PoC's own output shows AMSI_BLOCKED as an observed outcome, which tells you it's doing real work. And if the farm must be reachable from the internet, put it behind an authenticating reverse proxy or VPN so anonymous traffic never reaches /_trust/default.aspx, then firewall SharePoint so it only accepts traffic from that proxy. A proxy in front of a server that's still directly reachable is a decoration, not a control.
06 Verification
Patched, hunted and rotated? Let's prove it rather than assume it.
Get-SPFarm | Select-Object BuildVersionExpect the fixed build from the table above, or higher.
Get-HotFix -Id KB5002883Substitute the KB you actually deployed: KB5002882 for Subscription Edition, KB5002891 for 2016.
Select-String -Path 'C:\inetpub\logs\LogFiles\W3SVC*\*.log' -Pattern '_trust/default\.aspx' | Where-Object { $_.Line -match ' 4\d\d | 5\d\d ' } | Select-Object -Last 10 LineAfter patching, requests to the trust endpoint should be failing, not succeeding. Spot-check that recent hits show error status codes, and keep an eye on it for a few days; the scanners will keep knocking, but the door should stay shut.
Get-Date; iisreset /statusConfirm the IIS restart after key rotation actually happened on every farm server; a rotation without a restart is a no-op wearing a hi-vis.
07 Rollback
The realistic rollback scenario here isn't the patch, it's the key rotation invalidating sessions (expected, brief, survivable) or the update's known issues biting. For the sign-in prompt problem, fix forward with sticky sessions rather than uninstalling; for workflow status links, Microsoft has a separate workaround article linked from the KB.
Uninstalling the security update itself is almost never justified: it reopens a KEV-listed, actively exploited, unauthenticated RCE. If you're truly cornered:
wusa /uninstall /kb:5002883 /norestartExample: uninstall the July 2026 update on SharePoint 2019; substitute the KB you deployed. Re-patch through your rings as soon as the blocking issue is resolved, and treat the window in between as exposure, cos it is.
08 References
- NVD: CVE-2026-50522
- Microsoft Security Update Guide: CVE-2026-50522
- ZDI-26-412
- CISA Known Exploited Vulnerabilities catalog
- KB5002883 (SharePoint Server 2019, July 2026)
- ThreatLocker: how to hunt and contain the latest SharePoint exploits
- Help Net Security: SharePoint CVE-2026-50522 exploited, patch and rotate keys
- 4minx/CVE-2026-50522: the public Python mass-scan PoC (third-party, not the finder's work, and unverified; treat accordingly)
If I've got anything wrong here, or you've hit an edge case I haven't covered, do say, corrections and questions are always welcome :)
Ship the fix. Prove it’s closed.
If this runbook doesn’t fit your stack, send the CVE — an operator writes a verified path, usually within a business day. Or contribute your own and get co-authored credit.