Patching SharePoint Did Not Revoke the Keys Attackers Had Already Stolen.
Microsoft has patched a critical deserialization flaw in on-premises SharePoint, and exploitation has already been observed. The difficult part is what comes after the update: attackers who obtained ASP.NET machine keys may retain a way to create trusted payloads on a server whose vulnerable code has been fixed.
A critical route to code execution
CVE-2026-50522 affects on-premises editions of Microsoft SharePoint Server 2016, SharePoint Server 2019 and SharePoint Server Subscription Edition. Microsoft 365 is not affected by an on-premises SharePoint server vulnerability.
The flaw involves unsafe deserialization and can lead to remote code execution. CERT-EU assigns it a critical CVSS score of 9.8 and reports active exploitation following the release of public proof-of-concept material in July. CISA added the issue to its Known Exploited Vulnerabilities catalogue on 22 July and set an accelerated remediation deadline for US federal civilian agencies.
The public record included differing descriptions of the access needed for exploitation. Microsoft initially described some authentication requirements, while independent reporting indicated that practical attack paths might not always require a valid account. Defenders should follow the conservative interpretation for any internet-facing server: patch and investigate rather than rely on the presence of a login page.
The machine keys change the recovery problem
SharePoint and the underlying ASP.NET platform use machine keys to protect and validate application data. If an attacker extracts those keys after gaining code execution, they may be able to generate payloads that the application accepts as trusted.
That creates a persistence problem. Installing the security update can close the original deserialization path, but it does not automatically invalidate cryptographic material already copied by an attacker. A patched server can therefore remain at risk if recovery leaves the old keys and other stolen credentials in place.
This is the difference between vulnerability remediation and incident recovery. The first changes the code. The second restores trust in the system and everything it can authenticate.
Internet-facing SharePoint needs incident-level urgency
SharePoint servers often hold sensitive documents, workflow data and integration credentials. They may also have privileged connections to Active Directory, databases, mail systems and file shares.
An attacker with server-side code execution could steal data, deploy web shells, harvest keys and use the server’s identity to reach other systems. The exact consequences depend on the site’s privileges and segmentation, but the platform’s collaborative role usually gives it a broad view of the organisation.
Active exploitation means exposed servers should not be closed as complete merely because the patch installer finished successfully.
Patch, rotate and establish a new trusted state
Defenders should:
- Apply Microsoft’s current security updates to every supported on-premises SharePoint server.
- Remove unnecessary internet exposure and restrict administrative interfaces to trusted networks.
- Rotate ASP.NET machine keys across the farm using Microsoft’s supported procedures.
- Rotate service-account, database, API and administrative credentials available to the affected servers.
- Hunt for web shells, unexpected assemblies, scheduled tasks, new accounts and unusual child processes.
- Review IIS, SharePoint, endpoint and identity logs for exploitation attempts and post-compromise activity.
- Validate farm configuration and deployed solutions against a known-good baseline.
- Rebuild compromised servers where integrity cannot be demonstrated.
Key rotation must be coordinated across a SharePoint farm. An incomplete or inconsistent change can interrupt legitimate sessions and application functions. That operational risk is real, but it does not justify retaining potentially stolen trust material.
Patching closes a door, not every route back in
Security reporting often treats the availability of a vendor update as the end of a vulnerability story. In an actively exploited server-side flaw, it is only one milestone.
If attackers arrived before the update, they may have created accounts, installed code, copied secrets or changed downstream systems. Machine keys are especially important because they can allow malicious data to carry the appearance of authenticity.
The right question after patching is not only whether the vulnerable code path is gone. It is whether the organisation can still trust the server, its keys and the identities that flowed through it.
