SURIQ
Three times in July, defenders running Microsoft SharePoint on their own hardware got the same instruction: apply the update, this one is being exploited. The July Patch Tuesday batch carried three remote code execution flaws in on-premises SharePoint Server, and by the third one the pattern was clear enough to name. These are not three unrelated bugs. They are three doors into the same room, and the thing attackers carry out of that room every time is the server's machine key.
The newest is CVE-2026-50522, a critical deserialization of untrusted data rated CVSS 9.8. Microsoft credited DEVCORE researcher "splitline" with the discovery, which was demonstrated at Pwn2Own Berlin earlier this year and fixed in the July release. A public proof-of-concept landed on July 20, and watchTowr reported active exploitation within hours. It affects the supported on-prem editions: Subscription Edition, 2019, and 2016.
One primitive behind three flaws
Look at what the attacker actually does, not at the CVE number. In watchTowr's words, they are pulling SharePoint machine keys with a single request. The exploit posts a .NET deserialization payload at a SharePoint sign-in endpoint and walks away with the cryptographic keys the server uses to sign and encrypt its own state. CVE-2026-50522 does this. So did CVE-2026-58644, the 9.8 flaw we covered when it hit CISA's KEV list, and the lower-severity CVE-2026-56164 that opened the batch. The vulnerabilities are the way in. The machine key is the prize, and it is the same prize each time.
That reframes the whole month. A team that dutifully patched 56164 and 58644 and treats 50522 as one more line item is still measuring the wrong thing. Each patch closes the deserialization door it was written for. None of them changes the lock. If an attacker reached your server through any of the three before you patched, or through 50522 in the hours before your window opened, the key they took still works on a fully updated box.
Why a patched server can still be owned
The ASP.NET machineKey is the validation and decryption secret behind ViewState and other signed tokens. An attacker holding it can forge a ViewState blob that the server accepts as genuine, which on SharePoint is a path straight back to code execution. Patching the deserialization bug does not invalidate a key that has already left the building. This is why watchTowr's guidance was blunt: patching is not enough, and defenders should rotate credentials on any asset that may have been exposed. Rotating the machine key is the step that actually evicts the intruder, and it is the step most patch-and-move-on workflows skip.
There is a second trap in the paperwork. The advisory frames exploitation as requiring Site Owner privileges or higher, which invites a lower internal priority. The field says otherwise. Defused Cyber reported capturing exploitation requests that carried no authentication material at all, matching an unauthenticated profile. Whether that is a variant path or a gap between the rated and the real, the operational read is the same: assume any SharePoint server reachable from the internet is remotely exploitable, and do not let a privilege label buy you a slower response.
Time to exploit is now a property of the surface
The compression here is worth sitting with. A researcher-grade flaw, disclosed responsibly and demonstrated at a controlled contest, was under real-world attack within hours of a PoC becoming public. That speed is not luck. When the technique is a known, reusable machine-key pull against a well-understood endpoint, weaponizing a fresh entry point is close to mechanical. For this surface, patch cadence measured in days is already too slow. The interval that matters is the hours between public code and your update, and against a saturated target like on-prem SharePoint that interval keeps shrinking.
What to do about CVE-2026-50522 today
Apply the July 2026 SharePoint update on Subscription Edition, 2019, and 2016 first, ahead of anything non-exploited in the batch. Then rotate the machine key on every SharePoint server, because patching a stolen key does nothing. If you cannot patch immediately, Microsoft's standing interim step for SharePoint is to enable the Antimalware Scan Interface and set request-body scanning to full, which gives your tooling visibility into request content; treat it as a stopgap, not a fix.
Detection cannot lean on patch state, because a forged ViewState request built from a stolen key sails past a fully updated server. Higher-signal indicators live elsewhere: POST requests to sign-in and _layouts endpoints that trigger deserialization or return key material, new .aspx files appearing under the LAYOUTS or TEMPLATE directories, and the SharePoint worker process w3wp.exe spawning cmd.exe or PowerShell. If your servers run managed detection, those are the behaviors worth alerting on, and the machine-key rotation is worth verifying as a closed ticket rather than an assumed one. The larger question the July batch raises is architectural: three internet-facing RCEs in one month against the same product is a strong argument for asking why the SharePoint server answers the public internet at all.