CISA is warning administrators that CVE-2026-32201, CVE-2026-45659, and CVE-2026-56164 are being actively exploited against on-premises Microsoft SharePoint Server deployments. The July 14 alert covers every supported on-premises branch—SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Server 2016—and calls for immediate patching, compromise hunting, and tighter network exposure controls.
Detailed in CISA’s latest SharePoint security alert with technical input from Microsoft, the attacks can provide unauthorized access and remote code execution before progressing into persistence and malware deployment. CISA says observed post-exploitation behavior includes stealing Internet Information Services machine keys and abusing deserialization, meaning installing an update alone may not remove an attacker who has already entered the farm.
The agency added CVE-2026-32201 to its Known Exploited Vulnerabilities Catalog on April 14, CVE-2026-45659 on July 1, and CVE-2026-56164 on July 14. That staggered chronology suggests defenders are dealing with an evolving exploitation campaign rather than a single vulnerability disclosed and contained during one patch cycle.
CISA’s first instruction is straightforward: install Microsoft’s latest SharePoint security updates and verify that installation completes successfully. Administrators should not treat the presence of an update package in Windows Update history or a software-deployment console as proof that every SharePoint component was correctly serviced.
SharePoint updates have operational dependencies that make validation particularly important. Farms can contain multiple application and web-front-end servers, while the SharePoint Products Configuration Wizard or its PowerShell equivalent may still need to complete configuration changes after binaries are installed. A server left on an inconsistent patch level can remain vulnerable or create availability problems across the farm.
Organizations should therefore confirm the installed build on every farm member, complete the required post-update configuration process, and test Central Administration and production web applications. CISA also advises shortening patch cycles where possible, reflecting the narrowing interval between vulnerability disclosure and real-world exploitation.
But defenders must assume that exposed systems may already have been breached. Stolen IIS machine keys can enable attackers to generate or manipulate data that an ASP.NET application will accept as trusted, potentially preserving a route back into SharePoint after the original exploit is patched. CISA specifically says organizations should hunt for intrusion artifacts and machine-key harvesting tools before rotating keys; otherwise, an attacker still present on the server may simply steal the replacements.
That order matters: investigate, contain, eradicate, and then rotate compromised secrets. Administrators who reverse those steps risk creating the appearance of remediation without removing the mechanism that caused the compromise.
Microsoft’s SharePoint AMSI integration passes eligible web requests to an AMSI-compatible antimalware engine before SharePoint processes them. It is not a replacement for security updates, but it can block or surface exploitation attempts that reach a patched incorrectly, newly exposed, or otherwise vulnerable server.
CISA identified three relevant AMSI detections and one Microsoft Defender Antivirus detection that security teams should incorporate into monitoring:
Defender and AMSI telemetry should also be centralized rather than reviewed exclusively on individual SharePoint servers. An attacker who gains administrative or system-level execution may tamper with local logs, disable protections, or remove files after use. Forwarding events to a protected security information and event management platform gives responders a better chance of retaining the attack trail.
Investigators should pay close attention to unusual child processes spawned by SharePoint’s IIS worker processes, unexpected script execution, newly written files in web-accessible directories, and outbound connections that do not fit the server’s established baseline. Unexpected reads of ASP.NET configuration or machine-key material are especially significant in light of the persistence techniques described by CISA.
The absence of a visible web shell should not be interpreted as a clean bill of health. Attackers may execute payloads in memory, use short-lived files, alter existing components, or rely on stolen cryptographic material rather than maintaining an obvious command page. Hunting must cover process, file, network, authentication, and configuration telemetry across the full period during which the server could have been exposed.
SharePoint administrators and security operations teams will need to work together here. Farm topology, service accounts, timer jobs, search components, and legitimate administrative scripts can all produce activity that appears suspicious without SharePoint-specific context. Conversely, a technically valid SharePoint request may still be malicious when it occurs from an unusual source or targets an administrative component.
A conventional firewall allowing TCP 443 does not provide that protection. Application-aware controls can reject malformed requests, enforce pre-authentication, constrain access paths, and generate richer telemetry before traffic reaches IIS. Those controls may also provide time for defenders when a new SharePoint exploit emerges before patches can be deployed throughout a large farm.
The agency separately calls for blocking external access to SharePoint Central Administration. Farm and database communications should be restricted to explicitly required systems and ports, limiting the paths available to an attacker who compromises a web-facing node.
This is a useful dividing line for administrators reviewing inherited deployments. A SharePoint server reachable from arbitrary internet addresses, with Central Administration exposed and unrestricted access to backend systems, represents a substantially different risk from a farm behind authenticated publishing infrastructure and tightly segmented database connectivity.
Microsoft’s role-specific SharePoint hardening guidance should be applied to services, ports, and
CISA may revise its alert as Microsoft or other parties publish additional guidance. For now, the operational milestone is clear: administrators need to verify the current SharePoint build, enable and validate AMSI scanning, hunt for IIS key theft and other persistence artifacts, and remove unnecessary internet exposure. With CVE-2026-56164 entering the KEV Catalog on July 14, waiting for the next routine maintenance window is no longer a defensible response.
Detailed in CISA’s latest SharePoint security alert with technical input from Microsoft, the attacks can provide unauthorized access and remote code execution before progressing into persistence and malware deployment. CISA says observed post-exploitation behavior includes stealing Internet Information Services machine keys and abusing deserialization, meaning installing an update alone may not remove an attacker who has already entered the farm.
The agency added CVE-2026-32201 to its Known Exploited Vulnerabilities Catalog on April 14, CVE-2026-45659 on July 1, and CVE-2026-56164 on July 14. That staggered chronology suggests defenders are dealing with an evolving exploitation campaign rather than a single vulnerability disclosed and contained during one patch cycle.
Patching Is the Start of the Response, Not the End
CISA’s first instruction is straightforward: install Microsoft’s latest SharePoint security updates and verify that installation completes successfully. Administrators should not treat the presence of an update package in Windows Update history or a software-deployment console as proof that every SharePoint component was correctly serviced.SharePoint updates have operational dependencies that make validation particularly important. Farms can contain multiple application and web-front-end servers, while the SharePoint Products Configuration Wizard or its PowerShell equivalent may still need to complete configuration changes after binaries are installed. A server left on an inconsistent patch level can remain vulnerable or create availability problems across the farm.
Organizations should therefore confirm the installed build on every farm member, complete the required post-update configuration process, and test Central Administration and production web applications. CISA also advises shortening patch cycles where possible, reflecting the narrowing interval between vulnerability disclosure and real-world exploitation.
But defenders must assume that exposed systems may already have been breached. Stolen IIS machine keys can enable attackers to generate or manipulate data that an ASP.NET application will accept as trusted, potentially preserving a route back into SharePoint after the original exploit is patched. CISA specifically says organizations should hunt for intrusion artifacts and machine-key harvesting tools before rotating keys; otherwise, an attacker still present on the server may simply steal the replacements.
That order matters: investigate, contain, eradicate, and then rotate compromised secrets. Administrators who reverse those steps risk creating the appearance of remediation without removing the mechanism that caused the compromise.
AMSI Moves Into the Front Line
CISA is directing administrators to verify that Antimalware Scan Interface integration is enabled for each SharePoint web application. Where the environment supports it, the agency recommends selecting Full Mode for Request Body Scan Mode so that request content receives deeper inspection.Microsoft’s SharePoint AMSI integration passes eligible web requests to an AMSI-compatible antimalware engine before SharePoint processes them. It is not a replacement for security updates, but it can block or surface exploitation attempts that reach a patched incorrectly, newly exposed, or otherwise vulnerable server.
CISA identified three relevant AMSI detections and one Microsoft Defender Antivirus detection that security teams should incorporate into monitoring:
Exploit:Script/SuspSignoutReqBody.Adetects relevant request-body activity on SharePoint Server Subscription Edition, with Microsoft reporting that observed attempts have been blocked.Exploit:Script/ToolPaneAuthBypass.Acovers suspicious request-header activity across SharePoint Server 2016, 2019, and Subscription Edition.Exploit:Script/ToolPaneAuthBypass.Cprovides remote-code-execution coverage across all three supported on-premises versions.Backdoor:MSIL/LeakFang.A!dhaflags post-exploitation activity involving IIS-protected secrets.
Defender and AMSI telemetry should also be centralized rather than reviewed exclusively on individual SharePoint servers. An attacker who gains administrative or system-level execution may tamper with local logs, disable protections, or remove files after use. Forwarding events to a protected security information and event management platform gives responders a better chance of retaining the attack trail.
The Worker Process Tells the Story
CISA wants organizations to establish logging tailored to SharePoint exploitation, including monitoring for anomalous HTTP requests, suspicious worker-process behavior, web shells, and access to machine-key material. Generic server-health monitoring will not provide enough context to distinguish a busy collaboration portal from a compromised one.Investigators should pay close attention to unusual child processes spawned by SharePoint’s IIS worker processes, unexpected script execution, newly written files in web-accessible directories, and outbound connections that do not fit the server’s established baseline. Unexpected reads of ASP.NET configuration or machine-key material are especially significant in light of the persistence techniques described by CISA.
The absence of a visible web shell should not be interpreted as a clean bill of health. Attackers may execute payloads in memory, use short-lived files, alter existing components, or rely on stolen cryptographic material rather than maintaining an obvious command page. Hunting must cover process, file, network, authentication, and configuration telemetry across the full period during which the server could have been exposed.
SharePoint administrators and security operations teams will need to work together here. Farm topology, service accounts, timer jobs, search components, and legitimate administrative scripts can all produce activity that appears suspicious without SharePoint-specific context. Conversely, a technically valid SharePoint request may still be malicious when it occurs from an unusual source or targets an administrative component.
Internet Exposure Becomes the Architectural Weak Point
CISA recommends that organizations avoid exposing on-premises SharePoint directly to the internet unless there is a documented business requirement. If external access is unavoidable, the server should sit behind a Layer 7 reverse proxy or equivalent application-layer control that requires authentication and can inspect and filter incoming requests.A conventional firewall allowing TCP 443 does not provide that protection. Application-aware controls can reject malformed requests, enforce pre-authentication, constrain access paths, and generate richer telemetry before traffic reaches IIS. Those controls may also provide time for defenders when a new SharePoint exploit emerges before patches can be deployed throughout a large farm.
The agency separately calls for blocking external access to SharePoint Central Administration. Farm and database communications should be restricted to explicitly required systems and ports, limiting the paths available to an attacker who compromises a web-facing node.
This is a useful dividing line for administrators reviewing inherited deployments. A SharePoint server reachable from arbitrary internet addresses, with Central Administration exposed and unrestricted access to backend systems, represents a substantially different risk from a farm behind authenticated publishing infrastructure and tightly segmented database connectivity.
Microsoft’s role-specific SharePoint hardening guidance should be applied to services, ports, and
Web.config settings rather than treated as a generic checklist. Search servers, application servers, web front ends, Office Online integrations, and SQL Server hosts do not all require the same network access. Rules that reflect those roles can reduce lateral movement without breaking legitimate farm operations.CISA may revise its alert as Microsoft or other parties publish additional guidance. For now, the operational milestone is clear: administrators need to verify the current SharePoint build, enable and validate AMSI scanning, hunt for IIS key theft and other persistence artifacts, and remove unnecessary internet exposure. With CVE-2026-56164 entering the KEV Catalog on July 14, waiting for the next routine maintenance window is no longer a defensible response.
References
- Primary source: CISA
Published: 2026-07-14T12:00:00+00:00
