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 build of every exposed Swiss SharePoint server. Not one is confirmably patched.
On 20 July a working proof of concept for CVE-2026-50522 appeared in public, and honeypots picked up attackers using it within hours. The bug is a deserialization flaw in on-premises SharePoint, rated 9.8, 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 running without the fix, and not a single one could be confirmed as up to date.
We wrote about CVE-2026-56164 last week, and in April about 1’370 servers 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 constructed and a gadget chain turns that into code execution.
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 sign and validate __VIEWSTATE blobs. 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 ToolShell cleanup so miserable. 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 |
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 fingerprinted with Shodan’s http.component:"Microsoft SharePoint" facet. This time we searched the raw header string instead, and that turned out to matter: the component facet returns 18 Swiss hosts, the header string returns 68. The facet only fires when Shodan’s HTTP module ran and matched, so it quietly drops SharePoint on odd ports and misses older generations entirely. Every SharePoint 2010 box 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. Zero carry a honeypot tag and zero look like honeypots on inspection. 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 build provably older than the 14 July patch. 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 the pandemic ended.
That is 24 of 32 running without the fix. The remaining 8 sit at the current build octet where the header does not expose the exact revision, so we say nothing about them in either direction. The number confirmed on a patched build is zero.
Because every build octet 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, which is the build SharePoint 2019 shipped with in October 2018, meaning no cumulative update has ever been applied. One reports 16.0.0.4327, the build SharePoint 2016 carried at release in 2016. One is on the April 2018 update. Only one of the seven is inside a year of current.
The part that actually bothered us
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. 12 of those 13 report a byte identical build header. The single server that changed moved from one end of life SharePoint 2013 build to another end of life SharePoint 2013 build, which is not a fix by any reading. Servers that moved onto a patched build: zero.
So a full week passed with the update sitting on Microsoft’s download servers. A working exploit went public in the middle of that week. Nothing happened. Whatever the theoretical patch window for a 9.8 with public exploit code is supposed to be, this population is not inside it.
Detection you can use today
The passive check is the header comparison above. If you want it automated, our Nuclei template for this is in the research pack and it passed three rounds of validation: schema, a mock server serving 13 known builds including the exact patched ones, and a live run against every host in this census. Watch the header case, because Go canonicalizes it and a case sensitive matcher 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.
If you want to check your own infrastructure, Sentinel scans your public IP range and reads the SharePoint build for you. Free, no account required.
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.