On July 14, 2026, the U.S. Cybersecurity and Infrastructure Security Agency (CISA) issued an urgent alert: three vulnerabilities in on-premises Microsoft SharePoint Server are being actively exploited by attackers to gain unauthorized access, achieve remote code execution, and steal critical IIS machine keys. The campaign affects every supported version of SharePoint Server—Subscription Edition, 2019, and 2016—and CISA is directing administrators to patch immediately, hunt for signs of compromise, and tighten network defenses.

Three Exploited Flaws, One Ongoing Campaign

The vulnerabilities in play are CVE-2026-32201, CVE-2026-45659, and CVE-2026-56164. CISA added the first to its Known Exploited Vulnerabilities (KEV) Catalog on April 14, 2026, the second on July 1, and the latest on July 14. That staggered timeline suggests a deliberate, evolving campaign rather than a single point-in-time disclosure. According to the alert, which includes technical input from Microsoft, threat actors are chaining these flaws to establish remote code execution (RCE), then pivoting into post-exploitation activities like stealing Internet Information Services (IIS) machine keys and leveraging deserialization techniques for persistence and malware deployment.

All three bugs affect on-premises SharePoint Server deployments. The Subscription Edition, 2019, and 2016 are all vulnerable; Microsoft has released security updates for each version. CISA’s alert makes clear that simply installing those patches is not enough. Administrators must verify the installation completed successfully on every server in the farm, hunt for existing intrusions, and reconfigure defensive layers—especially for internet-facing systems.

What This Means for Your SharePoint Farm

If your organization runs an on-premises SharePoint Server farm, the immediate risk depends on two factors: how quickly you apply and validate patches, and whether the server was accessible from the internet before patching. Even fully patched farms may still harbor attackers who entered earlier and stole cryptographic material. The alert warns that stolen IIS machine keys let adversaries generate or manipulate data that an ASP.NET application treats as trusted, effectively bypassing authentication and maintaining a backdoor after the original exploit is patched.

For administrators, the practical impact is a compressed timeline. CISA recommends shortening patch cycles. The window between vulnerability disclosure and real-world exploitation has narrowed sharply—CVE-2026-56164 was added to the KEV on the same day the alert was published. Home users and casual SharePoint site owners are not in the direct line of fire; this is an on-premises server threat. But any organization that relies on SharePoint for collaboration, document management, or line-of-business applications should treat this as a critical incident.

The alert also underscores a point often missed during patch panic: validating the update. SharePoint farms can span multiple application and web-front-end servers. Installing a package through Windows Update or a software deployment tool does not guarantee every component is correctly serviced. The SharePoint Products Configuration Wizard—or its PowerShell equivalent—must be run on each server to complete the process. A single inconsistently patched server leaves the entire farm exposed.

How We Got Here

On-premises SharePoint has long been a high-value target for attackers. Its deep integration with Active Directory, IIS, and SQL Server makes it a rich source of credentials and pivot points. Over the past several years, CISA and Microsoft have consistently flagged SharePoint vulnerabilities in active campaigns, from the CVE-2019-0604 debacle to more recent deserialization bugs. The pattern is familiar: a patch lands on Patch Tuesday, exploit code surfaces days or weeks later, and organizations slow to test and deploy find themselves compromised.

These three CVEs fit that mold, but with a twist. CISA’s staggered KEV entries imply that attackers likely had working exploits well before public disclosure, and they may have refined their techniques across multiple patch cycles. Microsoft contributed to the alert, indicating coordinated investigation and defense. The mention of stolen IIS machine keys and deserialization points to a sophisticated, multi-stage attack chain: first, gain RCE via one vulnerability; next, steal keys to forge authentication; then establish persistence and drop malware.

CISA also flagged additional, not-yet-exploited CVEs that Microsoft considers risky. Those aren’t in the active campaign, but they underscore the continuous pressure on SharePoint administrators to maintain rigorous patch hygiene and layered defenses.

What to Do Now: Patching, Hunting, Hardening

CISA’s alert lays out a clear, four-part response. The order matters—investigate and contain before you rotate secrets.

1. Patch and Verify—Really Verify

Start by deploying the latest cumulative updates for your SharePoint version. Microsoft’s security guidance maps each CVE to specific updates; check that you’re applying the correct package for Subscription Edition, 2019, or 2016. After installation, do not trust the software deployment console alone. Log onto each farm server and confirm the build number matches the expected patched level. Run the SharePoint Products Configuration Wizard (or the psconfig command) on every server, then test Central Administration and all production web applications. A server that missed the configuration step remains vulnerable, even with patched binaries.

2. Hunt for Compromise Before Rotating Keys

This is the alert’s most critical—and easily misordered—instruction. If an attacker stole your IIS machine keys, rotating them while the intruder still has access means the new keys can be stolen, too. First, hunt for intrusion artifacts. CISA calls out the following detection signatures that security teams should actively monitor:

  • Exploit:Script/SuspSignoutReqBody.A – request body scanning, SharePoint Server Subscription Edition only; Microsoft says observed attempts have been blocked.
  • Exploit:Script/ToolPaneAuthBypass.A – request header scanning, all three supported versions.
  • Exploit:Script/ToolPaneAuthBypass.C – RCE coverage, all three supported versions.
  • Backdoor:MSIL/LeakFang.A!dha – post-exploitation activity involving IIS-protected secrets.

Any detection should trigger your incident-response process, not just a quick antivirus scan. Look for unusual child processes spawned by SharePoint’s IIS worker processes, unexpected script execution, newly written files in web-accessible directories, and outbound connections that deviate from baseline. Pay special attention to reads of machineKey material in web.config or other ASP.NET configuration files. Because IIS machine keys can be harvested silently, the absence of a visible web shell does not mean the server is clean.

Only after confirming no active intruder is present should you rotate machine keys. Microsoft’s guidance on improved ASP.NET view state security and key management provides a path. Plan for a coordinated key rotation across the farm to avoid availability issues.

3. Turn On and Tune AMSI

The Antimalware Scan Interface (AMSI) integration in SharePoint is a potent defensive layer, but it’s often left at default settings. CISA wants administrators to verify that AMSI is enabled for each web application and, where feasible, set the Request Body Scan Mode to “Full Mode.” This forces deeper inspection of request content, which can catch exploitation attempts that bypass surface-level filters.

Use the detections listed above as a starting point for tuning. Forward AMSI and Microsoft Defender Antivirus events to a centralized SIEM so that an attacker who disables local logging doesn’t erase the trail. Note that the SuspSignoutReqBody.A detection applies only to the Subscription Edition, so farms on 2016 or 2019 won’t see it—lean on the ToolPaneAuthBypass signatures instead.

4. Shrink Your Internet Footprint

CISA’s strongest architectural advice: avoid exposing SharePoint directly to the internet. If business requirements demand external access—say, for partners or remote employees—place the server behind a Layer 7 reverse proxy that requires authentication and can inspect and filter requests. A simple firewall allowing TCP 443 is not enough; application-layer controls can reject malformed requests, enforce pre-authentication, and buy time when new zero-days surface.

Block all external access to SharePoint Central Administration. Restrict farm and database communications to explicitly required systems and ports. Review Microsoft’s role-specific hardening guidance—search servers, application servers, web front ends, and SQL Server hosts do not all need the same network access. Segment accordingly. This reduces lateral movement opportunities and limits damage if a web-facing node is compromised.

Outlook: SharePoint Security in 2026

CISA notes it may update the alert as Microsoft or other parties release additional guidance. The staggered exploitation timeline suggests this campaign could continue to evolve, with new variants or additional vulnerabilities folded in. Organizations running on-premises SharePoint need to match that tempo, moving from a reactive patch cycle to a continuous hardening posture. The message from July 14 is unambiguous: patching is the start of the response, not the end—and in 2026, a neglected SharePoint farm is an invitation the attackers have grown very comfortable accepting.