Microsoft patched CVE-2026-50522 in its 14 July SharePoint Server security release, a deserialization-of-untrusted-data flaw carrying a CVSS score of 9.8 that allows a remote, unauthenticated attacker to execute code on the server. On 20 July, researcher Janggggg published a working proof of concept, and watchTowr says exploitation attempts landed across its honeypot network within hours. That is the pattern that keeps repeating with on-premises SharePoint this year: a patch ships, a PoC follows, and mass exploitation arrives before most organisations have finished rolling the update out.
The part that makes patching alone insufficient
The PoC works by delivering a malicious .NET BinaryFormatter payload inside a forged security token submitted to SharePoint’s /_trust/default.aspx sign-in endpoint, where a vulnerable deserialization path turns it into arbitrary code execution. What makes this particular flaw more dangerous than a typical unauthenticated RCE is what attackers are doing with the access once they have it: watchTowr observed attacks specifically targeting on-premises deployments to steal SharePoint machine keys. Machine keys let an attacker forge valid authentication tokens and impersonate legitimate users, which means an attacker who grabbed keys before you patched can keep walking back in afterward, using forged tokens rather than the vulnerability that let them in the first place. Applying the update closes the original door while leaving a second one, cut with the victim’s own keys, wide open.
Fourth SharePoint flaw exploited in a month
CVE-2026-50522 is the fourth SharePoint vulnerability to see active exploitation in the space of a single month, following the storm-2603 and warlock ransomware campaigns tied to CVE-2026-45659 that hit European organisations earlier in July. On-premises SharePoint remains deeply embedded in European government, healthcare and financial services environments precisely because it handles sensitive internal documents, which is exactly why attackers keep coming back to it, and exactly why a compromise here tends to be more consequential than the average RCE.
What to actually do about it
Applying the 14 July update is the first step, not the last one. Any organisation that had an internet-facing SharePoint server exposed between the patch’s release and now should treat machine key compromise as a live possibility, not a theoretical one, and rotate SharePoint machine keys and any other credentials the server had access to, alongside a review of authentication logs for tokens that do not match expected issuance patterns.
If you are not certain whether your SharePoint environment was exposed during this window, or you need help rotating machine keys and validating that no forged tokens are already in use, contact Excello Digital. We help European organisations respond to on-premises SharePoint compromises properly, not just patch the surface and hope the access is gone with it.