1'370 SharePoint Servers Still Open a Week After the Patch
Shadowserver counts 1'370 SharePoint servers exposed and unpatched against CVE-2026-32201. Fewer than 200 got patched after release. Attacks continue.
Microsoft shipped the patch for CVE-2026-32201 on April 14. As of this morning, the Shadowserver Foundation sees 1’370 SharePoint servers on the public internet that have not applied it. Fewer than 200 were patched in the week since release. Attacks did not stop while admins waited for a maintenance window.
What the Bug Does
CVE-2026-32201 is a spoofing vulnerability in SharePoint Server caused by improper input validation (CWE-20). It affects SharePoint Enterprise Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition when you run them yourself. SharePoint Online, the Microsoft 365 version, is not affected.
The CVSS score is 6.5, marked Important rather than Critical. The attack vector is network, complexity is low, and no authentication or user interaction is required. An attacker sends a crafted HTTP request to a public facing SharePoint endpoint. The server parses the request with insufficient validation, and the response that goes back to a legitimate user contains content the attacker controls. The URL in the browser is your SharePoint URL. The TLS certificate is your TLS certificate. The body of the page is whatever the attacker put there.
Microsoft confirmed exploitation started before the patch shipped. CISA added the CVE to the Known Exploited Vulnerabilities catalog the same week and set a federal patch deadline of April 28, which is this coming Monday.
The Shape of the Ongoing Attacks
The attacks are not noisy. Reporting from the first wave describes stealthy, targeted activity rather than mass defacement. Attackers use automated probes to find vulnerable SharePoint instances, then send crafted requests that spoof high value resources inside the site: financial reports, internal employee directories, credential prompts that look like the real SharePoint login form. No public exploit code has surfaced. The goal looks like quietly getting people to trust content that is not yours.
What that looks like in practice:
An employee opens what they believe is the company’s monthly financial summary page on the intranet. The page is served by SharePoint, over HTTPS, with the right URL. The numbers on the page are slightly different from reality. A board member makes a budget decision based on them.
An accounts payable clerk opens a vendor invoice preview on SharePoint. The IBAN in the spoofed preview is different from the one in the original PDF. The payment goes to an attacker controlled account.
A finance employee clicks what looks like a SharePoint session timeout prompt. They retype their password. The password never reaches SharePoint. It reaches an endpoint on the attacker’s infrastructure. A few minutes later, someone logs into the real SharePoint with those credentials.
The 6.5 score measures the bug. It does not measure what the bug enables.
Why Almost Nobody Has Patched
Patching SharePoint on your own hardware is not a one click operation. The cumulative update has to be applied to every farm server, then the SharePoint Products Configuration Wizard has to run, and the farm has to be healthy at each step. For a single server farm it is an evening of work. For a multi server farm it is a weekend with a change advisory board meeting and a rollback plan.
Most of the 1’370 servers Shadowserver is tracking belong to organizations that treat their SharePoint farm like a database from 2014: stable, load bearing, and only touched when something is on fire. The patching cadence is measured in quarters. A one week gap between release and production deployment is already faster than the policy allows at many firms.
That cadence worked as long as attackers did not already know how to exploit each new Patch Tuesday CVE. This one was a zero day before it was a CVE. The exploitation tempo is not on the same clock as a quarterly patching cycle.
Who Is In the 1’370
Shadowserver’s scans give IP addresses, not owner names, but the shape of on premises SharePoint is well known. Organizations keep SharePoint on their own infrastructure for three reasons:
Compliance. Swiss Treuhänder running SharePoint for client files, Swiss law firms holding contract libraries, Swiss insurance companies storing policy documents, and Swiss hospitals with patient correspondence all prefer to keep those records on their own servers. Professional secrecy under the nDSG and FINMA expectations for financial institutions push them that way.
Latency. Engineering firms with large CAD libraries, architects with building plans, and manufacturers with BOMs often run SharePoint on premises because the files are too big to round trip through the cloud every time somebody opens one.
History. A SharePoint farm that was set up in 2017 and migrated through three version upgrades keeps running because nobody has the appetite to rebuild it in the cloud.
Those three categories correlate well with how sensitive the documents on the server are. The 1’370 is mostly firms whose SharePoint contains the things they would least want a stranger to forge.
How to Check Yours
Open SharePoint Central Administration, go to Operations > Servers in Farm, and read the build number. Or run Get-SPFarm | Select BuildVersion from the SharePoint Management Shell. Compare against the patched builds:
| Edition | Patched build | KB |
|---|---|---|
| SharePoint Server Subscription Edition | 16.0.19725.20210 | KB5002853 |
| SharePoint Server 2019 | 16.0.10417.20114 | KB5002854 |
| SharePoint Enterprise Server 2016 | 16.0.5548.1003 | KB5002861 |
If your build is older than the patched one for your edition, you are in the 1’370. Apply the cumulative update through Windows Update or install the KB directly, then run the configuration wizard on each farm server to complete the upgrade.
If patching tonight is not feasible, put SharePoint behind a VPN or a reverse proxy that drops unexpected request shapes before they reach the server. Anything that prevents a raw HTTP request from a stranger reaching the SharePoint process buys time. “Reachable from the entire internet” is the state the attackers need.
The Other Half of the Problem
The patch closes the hole. It does not tell you whether someone already walked through it. If a spoofed SharePoint login form harvested credentials during the week between zero day and patch, those credentials are in somebody’s list now. The attacker does not need the bug anymore. They need a working VPN password or a working SharePoint session cookie, and one of those is probably good enough.
Audit your authentication logs for the period between April 7 and the day you patch. Spoofed login prompts usually lead to credential reuse somewhere else. If accounts show successful VPN or webmail logins from unusual locations after a user touched a SharePoint page, assume the credential was harvested. Rotate credentials for users who accessed the farm during that window, and look for second stage activity in Entra ID sign in logs, VPN logs, and Active Directory.
Check IIS logs for requests with encoded characters in Referer, Host, or form parameters that do not match normal browser traffic. Look at recently modified pages and list items for content that does not match the author’s usual activity. These are cheap hunts. The attackers were stealthy enough that only the cheap hunts are likely to find evidence.
The Broader Pattern
On premises SharePoint has a long relationship with this pattern. The ToolShell campaign against CVE-2025-53770 in mid 2025 compromised thousands of servers and is still being cleaned up in some environments. Lace Tempest exploited CVE-2023-29357 and CVE-2023-24955 two years earlier. Every year or so, a new bug shows up, attackers use it for a few weeks, and eventually Microsoft patches it. The attackers know that SharePoint is where the interesting documents live, that self hosted deployments patch slowly, and that the servers are visible on the internet because they need to be.
The same pattern shows up everywhere a management or collaboration appliance sits on the public internet. FortiClient EMS got owned through its management API. Nginx-ui shipped an MCP endpoint with no authentication. Swiss NetScaler appliances sat unpatched through CitrixBleed 3. SharePoint is the version that holds the most confidential documents.
Sentinel scans your public IP range, identifies SharePoint servers that are reachable from the internet, and checks the version string against the patched build. If yours shows up, the report tells you which edition is running, which patch level it is on, and whether an outside scan can reach it. Free scan, no account required, results in 30 minutes. Running it this week is cheaper than discovering on Monday that your farm was one of the 1’370.
Endolum Hacked addresses the second half. Place tracked decoy documents inside your SharePoint libraries. They look like normal Word and Excel files and carry no macros. If someone opens one using harvested credentials, a stolen session cookie, or any other path they should not have, you get an alert with user agent, IP, and approximate location of the opener. The patch tells you the bug is closed. A document that says “the person who opened me was not supposed to” tells you if someone got in anyway.
The patch is a week old. The exploits are still working because the patches are still not deployed. This weekend is a good time.