CVE-2026-56164: SharePoint Server Under Active Exploitation

CVE-2026-56164 is a missing-authentication-for-a-critical-function flaw in on-premise Microsoft SharePoint Server that lets an unauthenticated attacker escalate privileges over the network, with no user interaction. Mandiant and Google FLARE incident responders discovered it while analyzing real-world attacks, where it forms part of a chain that ends in remote code execution. With a patch available since the July 14, 2026 Patch Tuesday and a place in CISA's KEV catalog, exploitation is already confirmed and the window to act is short.

This Secra advisory covers what CVE-2026-56164 is, how it chains with two other vulnerabilities to achieve unauthorized access and code execution, which SharePoint versions are affected, why patching has a specific trap in SharePoint farms, how to detect compromise, and which measures to prioritize. It contains no exploit code: the goal is defensive.

Key takeaways

• Missing-authentication-for-a-critical-function flaw in SharePoint Server: allows privilege escalation with no authentication, over the network and with no user interaction.
• Discovered by Mandiant and Google FLARE during real-world attacks, not in a lab.
• Exploited chained with CVE-2026-32201 and CVE-2026-45659 to achieve RCE, deploy web shells, steal IIS machine keys and drop malware.
• Affects on-premise SharePoint Server (2016, 2019 and Subscription Edition). SharePoint Online is not affected.
• Microsoft shipped the patch on the July 14, 2026 Patch Tuesday and CISA added it to its KEV catalog with a short federal deadline.
• Patching is not enough: you must confirm the specific SharePoint update on every server and rotate stolen machine keys to cut off persistence.

What CVE-2026-56164 is

CVE-2026-56164 is a missing-authentication-for-a-critical-function flaw in Microsoft SharePoint Server. In plain terms, there is a sensitive product function that should require authentication and does not. A remote attacker, with no credentials and without tricking any user, can invoke that function and escalate privileges inside the system.

The attack vector is the network, the required privilege is none, and no user interaction is needed. That profile (unauthenticated, no interaction, remotely exploitable) is exactly what turns a vulnerability into a candidate for mass, automated exploitation, because it removes the barriers that normally slow an attacker down. For a refresher on how a flaw like this is cataloged and prioritized, see what is a CVE.

What sets this case apart is its origin: it did not come from a researcher reporting a theoretical finding, but from the incident response teams at Mandiant and Google FLARE, who identified it while analyzing real-world attacks. When a vulnerability is discovered this way, the operational conclusion is immediate: exploitation was already under way before the public advisory existed.

The exploitation chain

CVE-2026-56164 is not used on its own. Attackers chain it with CVE-2026-32201 and CVE-2026-45659 to build a complete, end-to-end attack. The logic of chaining vulnerabilities is the same we study in any offensive audit: an isolated flaw usually has a ceiling on its impact, but several combined escalate to full control of the server.

From missing authentication to unauthorized access

The entry point is the missing authentication. By not requiring credentials for a critical function, CVE-2026-56164 hands an anonymous attacker access that would normally be reserved for authenticated users. That privilege escalation is the lever that opens the door to the rest of the chain.

From unauthorized access to remote code execution

By combining that access with the other two vulnerabilities, attackers achieve remote code execution (RCE) on the SharePoint server. Code execution on the web server is the turning point of any compromise: from there, the attacker is no longer limited to what the application exposes and starts operating with the context of the server itself.

Persistence: web shells and machine key theft

Once inside, the observed activity follows a familiar and especially dangerous pattern:

• Web shell deployment: malicious .aspx files that give the attacker a persistent remote console on the server. It is the same outcome we analyze in insecure file upload: from web shell to RCE; a web shell installed this way behaves afterward like any backdoor.
• Theft of IIS machine keys: the ASP.NET machine keys (ValidationKey and DecryptionKey) that SharePoint uses to sign and encrypt ViewState. Stealing them is what makes this attack different from an ordinary compromise.
• Malware deployment to further cement access.

The machine key theft deserves its own explanation because it is the root of long-term persistence. With the ValidationKey and DecryptionKey in hand, an attacker can forge valid ViewState objects and sign them as if they came from the server itself. SharePoint deserializes them trusting them, and that deserialization becomes a code-execution channel that works even after the patch is applied. Put another way: patching the access flaw closes the entry door, but does not invalidate a key the attacker already copied.

This dynamic closely echoes the "ToolShell" wave that hit SharePoint in 2025, where cryptographic key theft was precisely the mechanism that let attackers stay inside compromised farms despite the patches. The lesson from that episode, that rotating keys is as mandatory as patching, applies here again.

Affected versions

CVE-2026-56164 affects SharePoint Server in its on-premise form:

The distinction matters for scoping the risk in your organization: SharePoint workloads that live in Microsoft 365 (SharePoint Online) are out of scope. The risk concentrates on the SharePoint farms an organization runs on its own infrastructure, which tend to be high-value internal systems (corporate documentation, intranets, business workflows) and often carry slower patch cycles than cloud services.

Severity and exploitation status

On severity, precision matters. Microsoft and CISA treat this vulnerability as critical and actively exploited. Rather than fixating on an exact numeric score, what matters for prioritization is the set of verified facts: it was discovered by analyzing real-world attacks, it is chained to achieve unauthenticated RCE, and CISA added it to its KEV catalog (Known Exploited Vulnerabilities), which is reserved for vulnerabilities with confirmed exploitation.

Inclusion in the KEV is not a bureaucratic detail. It carries a short federal remediation deadline for US agencies and works, for any organization, as an unambiguous signal of top priority: if something is in the KEV, it has confirmed real-world exploitation. It is the difference between theoretical severity and real exploitability that should drive the prioritization of any serious patch program.

Patching has a trap: how to remediate a SharePoint farm

Here is where many organizations get it wrong and stay exposed while believing they are safe. Microsoft shipped the fix in the July 14, 2026 Patch Tuesday, but applying the patch to a SharePoint farm does not work like an ordinary Windows update.

Deploying the Windows update does not remediate SharePoint

SharePoint has its own servicing process. Deploying only the Windows cumulative update through the usual patching mechanisms does not remediate a SharePoint farm. The specific SharePoint update must be installed and then the servicing process that applies the changes to the farm configuration must be completed. If you stop at the Windows step, the binary may look updated while the vulnerability stays alive.

Confirm and validate on every server

That is why you must confirm and validate the specific SharePoint update on every server in the farm, not assume that a centralized rollout applied it. In a farm with several frontend and application servers, a single unpatched machine is enough to keep the surface open. Server-by-server verification is tedious, but it is exactly what separates a genuinely patched farm from one that only looks patched.

Rotate the IIS and ASP.NET machine keys

And there is a step you cannot skip even if the patch is correctly applied: rotate the IIS and ASP.NET machine keys after patching. As explained above, stolen keys allow ViewState forgery and persistence even on an already-patched server. Rotating the keys invalidates any the attacker may have copied and closes that persistence channel. If your farm was exposed and unpatched during the exploitation window, key rotation is not optional: it is part of remediation.

How to detect exposure and compromise

Detection has two planes: knowing whether you are vulnerable and knowing whether you have already been compromised.

Identify exposure:

• Inventory every on-premise SharePoint farm and server in the organization, including departmental or legacy instances that no team claims. Continuous discovery with an attack surface management (ASM and EASM) program is what keeps a forgotten farm from staying unpatched.
• Confirm, server by server, that the specific SharePoint update from July 14, 2026 is installed and that the servicing process completed.
• Check whether any farm was exposed to the internet without the patch during the exploitation window.

Hunt for indicators of compromise (threat hunting):

• Web shells: suspicious .aspx files, especially in SharePoint's LAYOUTS directories. Any .aspx that is not part of the official distribution or that shows recent modification dates warrants immediate investigation.
• Machine key theft: anomalous access to or reads of the configuration where the ASP.NET keys live, and any sign that the keys may have been exfiltrated.
• Anomalous requests to the affected critical function and unusual access patterns in the IIS and SharePoint logs.
• New and unexpected accounts, scheduled tasks or services, and anomalous outbound connections from the farm servers.

A critical point: patching does not evict an attacker who already got in. If a farm was exposed and unpatched during the exploitation window, you must assume compromise and investigate accordingly, rather than simply updating. With the machine keys potentially stolen, that assumption of compromise is especially prudent.

Priority mitigations

Action one: install the specific SharePoint update

Apply the SharePoint update from the July 14, 2026 Patch Tuesday and complete the servicing process. Remember that deploying only the Windows cumulative update does not remediate the farm. It is the top priority and does not admit delay given that exploitation is confirmed.

Action two: confirm server by server

Validate on every server of every farm that the SharePoint update was installed and applied. Do not assume a centralized rollout did it for you; a single unpatched machine reopens the entire surface.

Action three: rotate the machine keys

After patching, rotate the IIS and ASP.NET machine keys. It is the only thing that invalidates potentially stolen keys and cuts off persistence via forged ViewState. This step is mandatory if there was exposure, not an optional precaution.

Action four: reduce exposure and filter at the edge

While you complete remediation, limit internet exposure of on-premise SharePoint farms that do not need it and use edge filtering to reduce the accessible surface. A well-configured WAF helps temporarily mitigate certain vectors, though it never replaces patching and rotating keys.

Action five: investigate if there was exposure

If any farm was accessible while unpatched, activate the response procedure: retrospective threat hunting for web shells and key access, integrity review of the servers, credential rotation and containment of any artifacts found. A patch alone does not remove an already-installed web shell.

Fit with vulnerability management

CVE-2026-56164 is a textbook case for why a vulnerability management program with patching SLAs and real verification matters. The vulnerability illustrates several principles we summarize each month in our Patch Tuesday critical vulnerabilities roundup:

• Exploitation before the advisory: discovered by analyzing real-world attacks, the exposure window began before the patch existed. That forces you to treat every exposed SharePoint farm as potentially compromised.
• Patching is not a single step: the SharePoint servicing trap shows that "we apply patches" is not the same as "we are patched". Server-by-server verification is the control that closes that gap.
• Persistence outlives the patch: machine key theft, like in the wp2shell chain and other RCE waves we analyze in wp2shell (CVE-2026-63030), shows that remediation includes eradicating persistence, not just closing the flaw.
• Inventory and KEV: inclusion in CISA's KEV catalog makes this top priority. A complete surface inventory is what lets you act within the deadline.

Frequently asked questions

Am I affected if I use SharePoint Online in Microsoft 365?

No. CVE-2026-56164 affects on-premise SharePoint Server (2016, 2019 and Subscription Edition). SharePoint Online is not affected. The risk concentrates on the farms your organization runs on its own infrastructure.

Is deploying the Windows Patch Tuesday enough to be protected?

No. SharePoint has its own servicing process, and deploying only the Windows cumulative update does not remediate a SharePoint farm. You must install the specific SharePoint update, complete servicing, and confirm it on every server.

Why must I rotate the machine keys if I have already patched?

Because stolen machine keys allow forging ViewState objects and maintaining persistence through deserialization even after the patch is applied. Patching closes the entry path, but does not invalidate a key the attacker already copied. Rotating them cuts off that persistence.

How do I know if my SharePoint farm has already been compromised?

Look for web shells (suspicious .aspx files, especially in the LAYOUTS directories), signs of ASP.NET machine key theft, anomalous requests to the affected function, and unexpected accounts or services. If the farm was exposed while unpatched during the exploitation window, assume compromise and investigate.

What does it mean that CISA added it to the KEV catalog?

The KEV catalog lists vulnerabilities with confirmed real-world exploitation. Inclusion carries a short federal remediation deadline for US agencies and, for any organization, is a signal of top priority: if it is in the KEV, it has confirmed real-world exploitation.

Is it related to the 2025 "ToolShell" wave?

CVE-2026-56164 echoes the "ToolShell" wave that hit SharePoint in 2025, above all through the theft of cryptographic material (the machine keys) to maintain persistence despite the patches. The pattern of chaining access, RCE and key theft is the same, and so is the lesson: rotating the keys is as mandatory as patching.

Related resources

• What is a CVE: how a vulnerability like CVE-2026-56164 is referenced and prioritized.
• wp2shell: unauthenticated RCE in WordPress: another recent RCE chain where chaining and persistence drive the impact.
• Insecure file upload: from web shell to RCE: the typical outcome of code execution on a web server.
• What is a backdoor: types and detection: how persistent web shells deployed in the chain behave.
• What is a WAF: edge filtering as a temporary mitigation while patching.
• Attack surface management (ASM and EASM): discovering exposed SharePoint farms before the attacker does.
• Patch Tuesday: critical vulnerabilities roundup: how to prioritize patching month by month.

CVE-2026-56164 exposure assessment with Secra

Secra is an offensive cybersecurity company with an internal vulnerability research program and its own advisories published on NVD and INCIBE-CERT (CVE-2025-40652 in CoverManager and CVE-2023-3512 in Setelsa ConacWin CB, among others). That discovery discipline applied to your exposed surface is what separates detecting a CVE-2026-56164 exposure before or after the incident.

We help organizations assess their real exposure: inventory and continuous discovery of on-premise SharePoint farms, server-by-server verification of patching and servicing, review of machine key rotation, retrospective threat hunting for web shells and key theft, and, when appropriate, incident response engagement. Get in touch through contact.