Of the nearly 30,000 public facing SharePoint portals we identified, we found that approximately 3,300 of them are self-hosted. (Censys.io, Shodan.io) – and that could be a problem.

What’s the big deal?

CVE-2026-50522 is the fourth SharePoint vulnerability exploited in the wild in a month. Microsoft rates it 9.8, a deserialization flaw that lets an attacker execute code on the server remotely. The advisory lists it as requiring Site Owner authentication. But bad actors (and good pentesters) don’t often let advisories stop them. (It’s why we tend to touch a lot of wet paint). In keeping with that spirit, researchers at Defused captured live attack requests carrying no authentication material at all. So either the severity rating undersells the exposure, or someone found a path around the Site Owner requirement before anyone published it.

A public proof-of-concept dropped in mid-July. WatchTowr’s honeypot network logged real attacks within hours of it, and CISA added the CVE to its Known Exploited Vulnerabilities catalog four days later, giving federal agencies a July 25^thdeadline to patch. 

Here’s what we did

We started from one distinctive fingerprint: the MicrosoftSharePointTeamServices response header, which every on-premises SharePoint front-end hands back to an anonymous visitor, no login required and no proxy magic needed to see it. Querying Shodan and Censys for that string gave us our starting universe: just under 30,000 internet-facing hosts answering as SharePoint.

Most of that number is dominated by SharePoint Online, Microsoft’s own multi-tenant cloud service, addressed under Microsoft’s domains and running on Microsoft’s infrastructure rather than a customer’s. These were never exposed to the vulnerability in the first place because it isn’t on-prem software anyone patches themselves. Isolating the hosts that run as independent, customer-managed servers rather than tenants living inside that cloud brought the population down to roughly 3,300 self-hosted SharePoint installs. That’s the group actually capable of being vulnerable to CVE-2026-50522.

That same header doubles as a version disclosure. Each response carries a build number in the form 16.0.0.<build>, and where that number falls identifies which edition is running underneath: 2016, 2019, or Subscription Edition. Microsoft’s July 14 patches fixed the flaw at build 16.0.5561.1001 for 2016, 16.0.10417.20175 for 2019, and 16.0.19725.20434 for Subscription Edition. Any host reporting a build below its edition’s fixed number is confirmed unpatched from the outside, no login attempted and no exploit fired.

CVE-2026-50522 was patched as one entry in a run of SharePoint deserialization bugs Microsoft has been closing out over the past few months. Microsoft ships these fixes as cumulative updates, meaning each new patch includes every fix that came before it. The same July 14 build that closes CVE-2026-50522 also happens to be the exact build that fixes CVE-2026-56164, and it supersedes three earlier fixes on top of that. A host that clears our threshold isn’t just clean on the one CVE in this headline. A host that falls short is behind on that whole run, CVE-2026-50522 included.

Now for the exciting plot twist you’ve been expecting: Many of these servers sit behind reverse proxies or WAFs that rewrite or strip the header before it ever reaches a scanner, obfuscating the real picture. Censys’s own research into this fingerprinting method goes further, noting that for 2019 and Subscription Edition, some patches only bump an internal revision without changing the version string a remote scan can see (5). 

Where we couldn’t resolve a host’s build to a specific patch state with confidence, we called it undetermined. That’s why this piece reports a population and a lower bound on exposure rather than a precise national tally. That’s the most honest way we could think of to approach a fuzzy data set, and we prefer that over a cleaner, more massaged, output.

Patching is just the beginning

An attacker who compromised a server before it was patched can still maintain persistence after the patch is applied.

The RCE gives an attacker enough access to pull the server’s IIS machine keys in a single request. Those keys let them forge valid authentication tokens and impersonate any user on the system, admins included, without ever touching a password. Microsoft’s July update closes the deserialization exploitation path that got the attacker in, but the patch does not change the IIS server keys. This is by design for stability reasons. But attackers still have access to the systems because valid compromised keys are already in the wind. 

What else you need to do

Obviously, patch to the July 2026 update if you haven’t already done so. Rotate your IIS machine keys next. Don’t wait on this. Further, no server gets a pass just because it got patched. Put on your threat hunting hat (something Elmer Fudd-ish, maybe) to scour your logs and file system for web shells and IOCs going back to whenever the server first went internet-facing. Remember, this vulnerability has been there all along so any server that was exposed before this patch should be treated as compromised until proven otherwise.

Raxis Attacks. Raxis Protects.

We assess SharePoint and your network perimeter the way an attacker actually targets it, not the way a compliance checklist assumes upstream due diligence. Our compromise assessment also lends post-mortem piece of mind that your remediation efforts have closed the door permanently.