CISA has confirmed active exploitation of three Microsoft SharePoint Server vulnerabilities — CVE-2026-32201, CVE-2026-45659, and CVE-2026-56164 — and added the most recent of the three to its Known Exploited Vulnerabilities catalog on 14 July. Attackers are reportedly chaining the flaws to bypass authentication and achieve remote code execution, then stealing the server's IIS machine keys, the cryptographic secrets SharePoint uses to sign and encrypt its own web sessions. A stolen key lets an attacker keep coming back even after the server is patched, because the patch fixes the hole they climbed through, not the key they already took.
Only self-hosted SharePoint Server is affected — the Subscription Edition, 2019, and 2016 releases that organisations run on their own infrastructure. Microsoft's cloud-hosted SharePoint Online is untouched. Researchers scanning the open internet count roughly 10,000 SharePoint servers publicly reachable worldwide, with several hundred still unpatched against even the earliest of the three flaws, which CISA flagged back in April. US federal agencies have been given until 17 July to secure or disconnect affected systems under a binding directive — a deadline aimed at government networks, but the same software sits behind the same kind of intranet and extranet portals at ordinary companies everywhere.
What this means for your business
- Confirm which SharePoint you actually run. Only self-hosted (on-premises) SharePoint Server is affected. If your organisation uses Microsoft 365 / SharePoint Online, this specific alert doesn't apply to you.
- Patch, then rotate the keys. Installing Microsoft's update closes the door attackers used, but if a server was already compromised, the stolen IIS machine keys still work. CISA's guidance is to rotate those keys after patching, not just apply the patch and move on.
- Get it off the open internet if it doesn't need to be there. A SharePoint server reachable directly from outside is a bigger target than one sitting behind a VPN or a properly configured reverse proxy. Restrict direct exposure unless there's a clear business reason for it.
- Watch for anything unfamiliar afterwards. New admin accounts, unexpected scheduled tasks, or outbound connections from the server are all worth investigating even once the patch is in — persistence is the whole point of stealing a key.
None of this requires exotic defences. It's the same discipline every serious on-premises vulnerability rewards: know exactly what you're running, patch it on a real schedule rather than a convenient one, and treat "we'll get to it next month" as the window an attacker is counting on.