CVE-2026-50522: 24 of 32 Swiss SharePoint Servers Unpatched
A working exploit for CVE-2026-50522 went public on 20 July. We read the version of every exposed Swiss SharePoint server. 24 of 32 are measurably behind.
On 20 July a working proof of concept for CVE-2026-50522 appeared in public, and attack sensors run by security researchers recorded it in use within hours. The bug is a deserialization flaw in on-premises SharePoint, rated 9.8 out of 10, fixed by Microsoft on 14 July. We read the build number off every exposed SharePoint server on Swiss networks this morning, two days after the exploit landed. Of the 32 servers we found, 24 are measurably behind the fix, and the other 8 cannot be told apart from the outside, so the real figure is somewhere between 24 and all 32.
We wrote about CVE-2026-56164 last week, and in April about 1’370 servers worldwide still unpatched a week after a SharePoint fix. Same product, third story, and this time we could go back and check whether anything actually moved.
What the bug does
CWE-502, deserialization of untrusted data. SharePoint accepts a serialized .NET object off the network and rebuilds it without checking what type it is supposed to be, so the attacker controls what gets built, and that is enough to make the server run whatever they send.
The public exploit posts a malicious BinaryFormatter payload as the cookie of a forged SecurityContextToken, wrapped in a WS-Federation sign in response, to /_trust/default.aspx. That is the shape of the request to hunt for in your logs.
What the attackers want is not a shell. The exploitation reports have them pulling the SharePoint machine keys in a single request. Those keys are what SharePoint uses to prove that a request genuinely came from a logged in user. Copy them once and you can forge a valid signed payload from anywhere, whenever you like, and keep running code on the farm long after the patch is installed. This is exactly what made the 2025 SharePoint mass exploitation so miserable to clean up. Patching closes the hole. It does not change the locks.
Two things on Microsoft’s advisory are worth knowing before you read it. The CVSS vector says PR:N, no privileges required, while the FAQ on the same page says an attacker needs Site Owner rights. Independent reporting sides with the vector, because the captured exploitation requests carried no authentication material at all. Separately, Microsoft still marks the exploit code as unproven and the CVE as not exploited, which stopped being true on 20 July. The advisory has not caught up.
Affected products are on-premises only. SharePoint Online is not affected. The builds that carry the fix:
| Edition | Patched build |
|---|---|
| SharePoint Server Subscription Edition | 16.0.19725.20434 |
| SharePoint Server 2019 | 16.0.10417.20175 |
| SharePoint Enterprise Server 2016 | 16.0.5561.1001 |
On 22 July, while we were counting, CISA added CVE-2026-50522 to its Known Exploited Vulnerabilities catalogue and gave US federal agencies until 25 July to fix it. A three day deadline is unusually short even for that list.
Reading the version without touching the box
On-premises SharePoint volunteers its version to anyone who asks:
MicrosoftSharePointTeamServices: 16.0.0.10417The format is major.0.0.<build>, where the last number is the third octet of the real farm build. Major 15 is SharePoint 2013, major 14 is SharePoint 2010, and major 16 covers 2016, 2019 and Subscription Edition. Compare that octet to the patched build for the edition and you know whether a server is behind, without sending anything near the vulnerable endpoint. One GET, one header, one comparison.
Last week we searched an internet exposure index by product label. This time we searched for the raw header string instead, and that turned out to matter: the product label returns 18 Swiss hosts, the header string returns 68. A product label only gets attached when the index’s own scanner recognised the page, so it quietly drops SharePoint on unusual ports and misses older generations entirely. Every SharePoint 2010 server in this census is invisible to it. The bigger number is a better fingerprint rather than a growing estate, and it is why we are not publishing a week over week increase in exposure.
Those 68 banner matches resolve to 49 unique addresses. None of the 49 is flagged as a decoy system in the index and none looks like one on inspection, so no research sensor is inflating the count. 15 sit on Microsoft-owned ranges, which are SharePoint Online front ends that geolocate to Switzerland, and their build octets of 27410 and above are a useful confirmation that the exclusion is correct. Two more geolocate to Switzerland but are registered in Turkey and Singapore, which we checked in RDAP, because we attribute by who owns the network and not by where an address lands on a map. That leaves 32 servers genuinely on Swiss networks, and we read the build of all 32.
What the builds say
Seven run a supported edition on a version number lower than the 14 July fix. Those are the ones we can tie to CVE-2026-50522 directly, because Microsoft only assesses the three supported editions.
Another 17 are worse off. 12 run SharePoint 2013, out of support since 11 April 2023, and 5 run SharePoint 2010, out of support since 13 April 2021. There is no patch for them and there never will be. For 5 of these servers the vendor stopped shipping security updates before Windows 11 shipped.
That is 24 of 32 measurably behind the fix. The remaining 8 sit at the version number the fix ships as, and the header does not expose the revision underneath it, so from the outside they look identical whether or not the update is installed. We say nothing about them in either direction. That also means this method can never confirm a 2019 or Subscription Edition server as patched, which is worth stating plainly before anyone reads the zero as worse than it is.
Because every version number maps to a dated Microsoft cumulative update, we can say how far behind the seven supported servers actually are. Two report 16.0.0.10337, the version SharePoint 2019 shipped with in October 2018. Microsoft’s own update history begins at 16.0.10338, so no cumulative update has ever advanced those two, and they sit behind all 72 published since. One reports 16.0.0.4327, a build number that predates SharePoint 2016’s first cumulative update in April 2016, so nothing has advanced it in over ten years and it sits behind all 119 updates for that edition. A fourth is on the April 2018 update. Only one of the seven is within six months of current.
What changed in a week, and what could not
We measured 15 Swiss SharePoint servers on 15 July for the previous story. We looked at the same addresses again this morning.
13 of them are still in the index and 12 of those report an identical version number. Before anyone reads that as 12 servers refusing to patch, it is worth being precise about what those 13 could have done. Eight of them run SharePoint 2013, for which no fix exists at all, so there was nothing for them to install. Four more sit at the version number the July update ships as, which means a fix would not have changed the number we can see. Exactly one of the 13 could have shown a visible move to a fixed version, and it did not.
So the honest week over week finding is not that nobody patched. It is that the exposed population barely changed: 13 of 15 servers are still sitting there a week later, most of them running software that cannot be fixed without a migration project.
That is the more useful number for anyone budgeting remediation. A patch window only exists where a patch does, and for the majority of what is exposed here the work is a migration, not an update.
Detection you can use today
The passive check is the header comparison above. If you want it automated, the detection rule behind this post is written down with its validation record: it passed schema validation, then a mock server serving 13 known builds including the exact patched ones, then a live run against all 34 hosts we pulled. It flagged 23 of the 24, missing one server that answers an unauthenticated request with an error and only revealed its version in the recorded scan banner. Watch the header capitalisation, because a case sensitive match will find nothing at all.
For the already compromised question, hunt your IIS logs for unauthenticated POSTs to /_trust/default.aspx carrying wresult= or wa=wsignin1.0, then look for ViewState deserialization errors in the ULS logs. Those two together are the tell.
The check is one request against your own server: read the MicrosoftSharePointTeamServices header and compare its last number to the middle number of the patched build for your edition. If you would rather have your whole external estate read on a schedule instead of by hand, that is what Sentinel is for.
What to actually do
Install the 14 July cumulative update for your edition. Then rotate the ASP.NET machine keys and restart IIS, because if the keys walked before you patched, the update leaves the attacker holding valid forged tokens and you will not notice. This is the step almost everyone skips.
If you are on SharePoint 2013 or 2010, there is no patch to install. Take it off the internet today, then plan the migration. An unsupported farm reachable from the public internet stopped being a patching problem some years ago and became a decision.