Most Exposed Swiss SharePoint Runs Without This Week's Patch
CVE-2026-56164 is an actively exploited SharePoint flaw. We read the build of every exposed Swiss server. 10 of 15 are running without the fix.
Microsoft shipped the July Patch Tuesday yesterday, and one of the fixes is CVE-2026-56164, a missing authentication flaw in on-premises SharePoint that Microsoft already flagged as exploited in attacks. CISA added it to the Known Exploited Vulnerabilities catalog the same day and put out a hardening alert. We scanned Switzerland this morning, read the version off every exposed SharePoint server we could see, and checked each one against the patched build. Of the 15 on-prem SharePoint servers exposed on Swiss networks, 10 are confirmed to be running without this week’s fix. Not one could be confirmed as up to date.
This is the second SharePoint story we have written this year, and that is the point. In April it was CVE-2026-32201 with 1’370 servers still unpatched a week after the fix. This is a different bug, a different chain, and the same slow population of on-prem farms getting caught by it again.
What CVE-2026-56164 actually is
The bug is CWE-306, missing authentication for a critical function. A function inside SharePoint that should demand a login does not. An unauthenticated attacker reaches it over the network with no credentials and no user interaction. That is the AV:N, AC:L, PR:N, UI:N part of the vector, and it is why NIST scored this a 9.8.
Microsoft scored the same CVE a 5.3 and marked it Important rather than Critical. Both numbers are defensible once you understand that CVE-2026-56164 is not exploited on its own. CISA’s July 14 alert names it alongside CVE-2026-32201 and CVE-2026-45659 as a chain. The missing authentication primitive is the unauthenticated front door. The other two flaws are what turn standing in the doorway into remote code execution. Microsoft is scoring the doorway. NIST is scoring where the doorway leads.
Once an attacker has code execution, CISA describes the goal as stealing the IIS machine keys and running deserialization for persistence. That detail matters more than the score. The machine keys are what SharePoint uses to sign and validate __VIEWSTATE blobs. An attacker who copies them can forge a valid signed payload from anywhere, at any time, and keep executing code even after you install the patch. This is the same tradecraft that made the 2025 ToolShell campaign so hard to clean up. Patching closes the hole. It does not change the locks.
The affected products are on-premises only. SharePoint Online, the Microsoft 365 version, is not affected. If you run SharePoint yourself, here are 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 |
SharePoint 2013 is not on that list, and that turns out to be the whole story in Switzerland.
Reading the version without touching the box
On-prem SharePoint tells you its version without being asked. Every response carries this header:
MicrosoftSharePointTeamServices: 16.0.0.10417The format is major.0.0.<build>, where the last number is the third octet of the real farm build. A major of 15 means SharePoint 2013. A major of 16 means 2016, 2019, or Subscription Edition, and the last number tells you which generation and roughly how current it is. Read it, compare it to the patched build for that edition, and you know whether a server is behind, without sending anything near the vulnerable function. SharePoint Online never emits this header, so the check cleanly ignores Microsoft 365.
We fingerprinted on-prem SharePoint across Swiss IP space with Shodan’s http.component:"Microsoft SharePoint" facet and read the header off each host this morning, 15 July, one day after disclosure. Twenty-five unique IPs came back. That is not the number we publish, because a raw count never is. Zero carried a honeypot tag. Eight sit on Microsoft-owned network ranges (AS8075), which are Microsoft cloud endpoints that geolocate to Switzerland rather than SharePoint that a Swiss organization runs itself. Two more geolocate to Switzerland but belong to foreign networks, one registered in Turkey and one on a Singapore ISP, which we confirmed by looking up the registered owner of each address. We attribute by who owns the network, not where an IP lands on a map, so those ten are out. That leaves 15 on-prem SharePoint servers on genuinely Swiss networks, and we read the build of all 15.
What the builds say
Nine of the 15 are running SharePoint 2013.
SharePoint 2013 reached end of support on 11 April 2023. It has received no security update in over two years, and it will not receive one for CVE-2026-56164 either, because Microsoft does not patch it anymore. These nine servers are not simply behind on this week’s fix. They are behind on every SharePoint fix since 2023, sitting on the public internet, running software their vendor abandoned. On its own that is the finding.
One more is running a supported edition, SharePoint 2016, on a build whose version number is provably older than this week’s patched build. That one we can call confirmed: the version is lower than the fix, full stop.
That is 10 of 15 confirmed to be running without the CVE-2026-56164 fix. The remaining 5 run a supported edition at the current build generation, where the header does not expose the exact revision, so we make no claim about them in either direction. What we can say is that zero of the 15 could be confirmed as up to date. The best case for this sample is that 5 of them quietly patched today.
The exposed servers read like a cross section of the Swiss economy. Swisscom carries the largest share, as an ISP and a hoster. The rest sit behind Datasource AG, Init7, and smaller Swiss networks, and the names that resolve include a building materials manufacturer, a technical college, and a quality certification body. On-prem SharePoint is where document libraries live, and document libraries are where the interesting files live. Geographically it is what you would expect, with Zürich and Genève well ahead of everywhere else.
It gets worse underneath
The SharePoint version is only half of what the scan shows. Shodan also reports the IIS version, and IIS version maps directly to Windows Server version. Seven of the 15 run IIS 7.5 or 8.5, which are Windows Server 2008 R2 and 2012 R2. Both are past end of support and receive no security patches for the operating system either.
So on those seven boxes, the July SharePoint cumulative update is not just undeployed, it is close to undeployable. You cannot cleanly patch a SharePoint farm on an operating system that no longer receives updates and may not meet the prerequisites for the current update. The remediation there is not “apply the patch.” It is “migrate the platform first, then apply the patch,” which is a project measured in weeks. While that project is scoped, budgeted, and scheduled, the front door is open and the bug is being exploited.
Detecting and hunting
If you want to check your own estate at scale, the header read above is the whole method. From the outside, on hosts you own or are authorized to test, it is two lines with curl:
curl -sI https://sharepoint.example.ch/ | grep -i MicrosoftSharePointTeamServices
# MicrosoftSharePointTeamServices: 16.0.0.10417A major of 15 means SharePoint 2013 and end of the conversation. A major of 16 with the last number below the patched build’s third octet (2016 below 5561, 2019 below 10417, Subscription Edition below 19725) means the host is behind.
We wrote a non-invasive Nuclei template that does exactly this at fleet scale. It sends one GET, reads the header, and flags SharePoint 2013 or any 2016, 2019, or Subscription Edition build below the patched build. It carries no exploit primitive. We validated it two ways before publishing: the schema check passes, and a run against a mock server returning seven known builds flags the three vulnerable ones and leaves the patched, ambiguous, and non-SharePoint hosts alone. The template is going upstream to the ProjectDiscovery template set so the community can run it too.
If you want to know whether anyone has already walked through the door, the cheap hunt is your IIS logs. Look at the window from 14 July onward for requests that reach privileged SharePoint endpoints without a preceding authenticated session. A starter Sigma rule to adapt to your log shipper:
title: SharePoint Unauthenticated Access to Privileged Endpoint (CVE-2026-56164)
id: 7c1f0e2a-56b1-4a90-9f3d-2026561640aa
status: experimental
description: >
Flags requests to sensitive on-prem SharePoint endpoints that arrive without
an authenticated session, consistent with the CVE-2026-56164 missing
authentication primitive.
logsource:
product: iis
service: sharepoint
detection:
selection:
cs_uri_stem|contains:
- '/_layouts/'
- '/_api/'
- '/_vti_bin/'
auth_absent:
cs_username: '-'
condition: selection and auth_absent
falsepositives:
- Anonymous access explicitly enabled on public SharePoint sites
- Health probes and load balancer checks against layout paths
level: highBecause the post-exploitation goal is machine key theft, also watch for anything that reads or exports the farm’s machine keys, and treat unexpected __VIEWSTATE deserialization errors in the SharePoint ULS logs as worth a closer look. Those are the traces the ToolShell crews left behind, and this chain reuses the technique.
What to do this week
For a Swiss IT team, an MSP managing a client farm, or a Treuhänder holding client files on SharePoint, here is the order of operations.
First, read the build on every SharePoint farm you run, from Central Administration or with Get-SPFarm | Select BuildVersion, and compare it to the table above. If you are below the patched build, you are in scope.
Second, apply the July cumulative update to every server in the farm, then run the SharePoint Products Configuration Wizard on each one so the schema upgrade completes. A half applied update leaves the farm worse than before.
Third, rotate the IIS machine keys after patching. This is the step the April advice did not need and this one does. If an attacker copied your machine keys during the exposure window, the patch does not lock them out. Rotating the keys does. Do it even without evidence of compromise, because absence of evidence here mostly means nobody looked.
Fourth, if you cannot patch tonight, put SharePoint behind a VPN or a reverse proxy that drops unexpected request shapes before they reach the SharePoint process. Reachable from the entire internet is the state the attackers need.
And if you are on SharePoint 2013, the honest answer is that patching is downstream of a migration. Get off the unsupported version. Until you do, get it off the public internet entirely, because an unsupported server running an actively exploited service with a stealable persistence key is the worst combination on this list.
The pattern, again
On-prem SharePoint has a long relationship with this story. ToolShell against CVE-2025-53770 in 2025. Lace Tempest against CVE-2023-29357 two years before that. Our own April write-up on CVE-2026-32201. Every year or so a new bug surfaces, attackers use it for a few weeks while farms patch on a quarterly cadence, and the servers stay reachable because SharePoint needs to be. The same shape shows up wherever a management or collaboration appliance sits on the public internet, from FortiClient EMS to nginx-ui shipping an unauthenticated endpoint to Swiss NetScaler boxes sitting through CitrixBleed 3. SharePoint is the one that holds the documents people would least like a stranger to read.
The boring, load bearing half of responding to any of these is knowing which servers in your estate are actually affected. Sentinel scans your public IP range, identifies SharePoint servers reachable from the internet, reads the build from the header, and tells you which edition and patch level each one is on. The free scan finishes in 30 to 60 minutes and comes back as a written report a manager without a security background can read. Running it this week is cheaper than finding out in August that one of your farms was already keyed.
The patch is one day old. The exploitation started before it shipped. Most of the Swiss SharePoint we can see is not running it. This is a good week to look.