Microsoft patched CVE-2026-58644 on 14 July 2026 as part of Patch Tuesday, and CISA added it to the Known Exploited Vulnerabilities catalogue two days later on 16 July, setting a mandatory patching deadline of 19 July 2026 for federal civilian executive branch agencies. CVE-2026-58644 is a deserialization of untrusted data vulnerability in Microsoft SharePoint Server that allows an authenticated attacker with Site Owner privileges to write and execute arbitrary code remotely on the server. The CVSS score of 9.8 is near the maximum possible severity. Microsoft's advisory, updated after initial publication, confirmed the flaw was already being weaponised as a zero-day in attacks before the July 14 patch was released.
That sequence, exploitation before patch, CISA KEV listing within two days, and a federal deadline of 19 July, places CVE-2026-58644 among the most urgent SharePoint vulnerabilities in recent years. For organisations running SharePoint Server on-premises, the question is not whether to patch but whether they can do it fast enough, and whether they need to investigate past exposure before patching makes the question moot.
SharePoint Server is Microsoft's on-premises enterprise content management and intranet platform, used by organisations to host document libraries, internal websites, business process workflows, and integration endpoints for other enterprise applications. Unlike SharePoint Online, which runs in Microsoft's cloud infrastructure and receives patches applied automatically by Microsoft, SharePoint Server is deployed and maintained by each customer on their own hardware or private cloud. That means patching is the customer's responsibility, and there is no automatic update that applies the fix without the customer initiating it.
On-premises SharePoint deployments are common in regulated industries and government environments where data sovereignty, compliance requirements, or integration with internal systems that cannot be moved to the cloud make SharePoint Online unsuitable. The same environments where regulatory requirements push organisations toward on-premises SharePoint are frequently the environments that also have the most sensitive data stored in it: legal case files, financial records, health information, internal communications, and documents that meet the definition of materials an attacker would specifically seek out if they could execute code on the SharePoint server. The concentration of sensitive data and the on-premises deployment model that makes patching a manual process is the risk combination that makes CVE-2026-58644 particularly consequential.
Deserialization vulnerabilities occur when an application takes data that was serialised (converted into a storable or transmittable format) and reconstructs it into an object without adequately validating the data's content or type. If an attacker can control the serialised data that an application deserialises, they can craft a payload that, when deserialised, causes the application to execute code of the attacker's choosing rather than reconstructing a legitimate object. Deserialization vulnerabilities have appeared in SharePoint before, and several prior critical SharePoint vulnerabilities, including the widely-exploited CVE-2019-0604 and the more recent critical patches from 2023 and 2024, also involved deserialization or related server-side code execution primitives.
CVE-2026-58644 affects SharePoint Server Subscription Edition, SharePoint Server 2019, and SharePoint Enterprise Server 2016. The three affected versions together represent the current on-premises SharePoint deployment landscape, and any organisation running any of these versions without the July 14 Patch Tuesday update is vulnerable. Microsoft describes the attack complexity as Low, meaning an attacker does not need specialised knowledge, unusual system states, or significant preparation to exploit the vulnerability once they have the required authentication. The only precondition is a valid account with Site Owner-level privileges on a SharePoint site.
The consequence of successful exploitation is full remote code execution on the SharePoint server: the attacker's code runs in the context of the web application, which in a default SharePoint Server installation runs under the SharePoint farm account with significant privileges on both the server and the connected SQL Server database. From code execution on the SharePoint server, an attacker can extract authentication credentials and session tokens, access and exfiltrate the document libraries and lists stored in the SharePoint content databases, modify content in ways that persist after the initial foothold is removed, and use the server's network position and credentials to move laterally to other systems in the environment.
CVE-2026-58644 requires an authenticated attacker with Site Owner privileges, which might seem to imply a relatively high bar. Site Owner in SharePoint's permission model is below Site Collection Administrator and below Farm Administrator, but it is a common permission level that is granted to team leads, project managers, department heads, and anyone else who manages a SharePoint site for their team. In most large SharePoint deployments, hundreds or thousands of users hold Site Owner rights across the sites that have been created for different teams and projects over the years.
This means the authentication requirement for CVE-2026-58644 does not confine exploitation to a small category of highly privileged accounts. Any employee who manages a team site, any contractor who was given Site Owner rights to collaborate on a project, or any account that an attacker has already compromised through phishing or credential theft and that happens to hold Site Owner rights, is a viable starting point for exploitation. The CVSS score of 9.8, rather than 10.0, reflects this single authentication requirement, but in practice the pool of accounts that meet it is large in most enterprise SharePoint deployments.
The zero-day exploitation activity that Microsoft confirmed before the patch was released suggests that attackers were obtaining or already possessed Site Owner-level credentials as part of their attack chains. Given the scale of credential theft activity across enterprise environments, the availability of credentials with SharePoint Site Owner rights from stealer logs and dark web broker listings is entirely plausible. An attacker who purchases a valid credential set that includes SharePoint Site Owner rights in an organisation that has not yet patched CVE-2026-58644 has a direct path to code execution on that organisation's SharePoint server.
CVE-2026-58644 was not the only SharePoint vulnerability in the July 14 Patch Tuesday release, and the exploitation activity Microsoft identified involved a coordinated campaign rather than isolated use of a single flaw. Three additional CVEs, CVE-2026-32201, CVE-2026-45659, and CVE-2026-56164, were involved in the same campaign. The post-exploitation activity specifically identified in the campaign included IIS machine key theft, which is a technique that provides lasting persistence well beyond the initial code execution foothold.
The three additional CVEs in the campaign each represent different attack surfaces within the SharePoint and IIS environment. A coordinated campaign that chains multiple vulnerabilities in the same product family reflects attackers who have done advance reconnaissance on the target environment and developed a complete attack sequence rather than opportunistically exploiting a single vulnerability. Organisations responding to CVE-2026-58644 should assess whether the other three CVEs in the same campaign are also present in their environment and apply patches for all four as part of the same remediation effort rather than treating CVE-2026-58644 in isolation.
The IIS machine key theft technique identified in the campaign deserves specific attention because it is a post-exploitation action that creates a different and more lasting form of persistence than the initial code execution foothold. IIS machine keys are cryptographic keys that ASP.NET applications use to protect session state, authentication cookies, and view state from tampering. They are stored in IIS configuration files, specifically in the machineKey element of web.config or in the Windows Registry, and they are static: they do not rotate unless an administrator explicitly regenerates them.
An attacker who extracts the IIS machine keys from a SharePoint Server (or any ASP.NET application server) can use them to forge authentication cookies and session tokens that the server will accept as legitimate, even after the server has been patched and the original access mechanism has been closed. This is sometimes described as a "golden ticket" equivalent for web applications: having the machine key provides the ability to generate valid authentication material for the application indefinitely, because the application's trust model for its own session tokens is entirely based on the machine key's cryptographic guarantee. Patching CVE-2026-58644 closes the deserialization vulnerability but does not rotate the machine key. If an attacker extracted the machine key during the exploitation window, the organisation needs to regenerate the IIS machine keys as part of its post-compromise remediation, not just apply the patch.
The mandatory patching deadline of 19 July 2026 that CISA set for federal agencies applies specifically to organisations within the US federal civilian executive branch. Private-sector organisations, state and local governments, and international organisations are not bound by the CISA deadline, but the deadline is an authoritative statement about the urgency of the vulnerability that is directly applicable to any organisation running SharePoint Server.
CISA adds vulnerabilities to the KEV catalogue only when it has reliable evidence of active exploitation. The three-day window between the patch release on 14 July and the CISA deadline of 19 July reflects CISA's assessment that the exploitation activity is sufficiently active and consequential to require federal agencies to patch on an emergency timeline. For private-sector security teams making patching prioritisation decisions, a CVSS 9.8 vulnerability in actively used enterprise infrastructure with a CISA KEV listing and a three-day federal deadline translates directly to emergency change management procedures rather than standard patch cycle scheduling. The next maintenance window is not the appropriate timeline for this vulnerability.
Patching SharePoint Server is more operationally complex than patching a standard Windows server. SharePoint Server patches are distributed as Cumulative Updates rather than standard Windows Update packages, and applying them requires running the SharePoint Products Configuration Wizard after installing the update binary, restarting the SharePoint Timer Service, and in some cases manually running the psconfig.exe tool from the command line to complete the update of the SharePoint configuration database. In multi-server SharePoint farms with separate web front-end servers, application servers, and search servers, the patch must be installed and configured correctly on each server in the farm in the correct sequence.
The operational complexity of SharePoint patching is part of why many organisations run SharePoint Server at versions that are months or even years behind the current Cumulative Update baseline. Each skipped Cumulative Update accumulates as technical debt that must be applied when a critical vulnerability forces emergency patching, and in some cases the gap between the installed version and the patched version requires installing multiple intermediate Cumulative Updates rather than jumping directly to the latest version. Organisations in this situation should consult Microsoft's SharePoint update path documentation to identify whether any intermediate updates are required between their current version and the July 2026 Cumulative Update that contains the fix for CVE-2026-58644.
SharePoint Enterprise Server 2016 is one of the three affected versions. Microsoft extended support for SharePoint 2016 to October 2026, which means the July 2026 patch is available for that version, but organisations should be aware that the remaining support window is extremely short. After October 2026, SharePoint Server 2016 will no longer receive security updates, and any vulnerability discovered after that date will not be patched. The presence of CVE-2026-58644 in SharePoint Server 2016 is a reminder that actively exploited zero-days continue to affect all supported versions, not only current ones.
For organisations running SharePoint Server 2016, the appropriate response to CVE-2026-58644 is both to apply the available patch and to accelerate migration planning to a supported SharePoint version or to SharePoint Online before the October 2026 support end date. Running unpatched SharePoint infrastructure after support ends creates an indefinitely expanding attack surface with no vendor-provided remediation path. The July 2026 zero-day demonstrates that SharePoint remains an active target for sophisticated attackers, and that risk does not diminish after support ends. It increases, because the attack surface is fixed while the security posture erodes.
The confirmation that CVE-2026-58644 was exploited as a zero-day before the patch was released means that any organisation with a vulnerable SharePoint Server that was internet-accessible during the pre-patch window should treat the investigation question as a precondition of, or at minimum concurrent with, the patching response. Patching closes the vulnerability but does not remove access that an attacker established before the patch arrived. The IIS machine key theft technique specifically identified in the campaign creates persistence that survives patching.
The investigation priorities for a potentially exposed SharePoint Server include reviewing IIS access logs for unusual request patterns to SharePoint endpoints that are not consistent with known SharePoint functionality or normal user activity, checking the web.config files and Registry for the machineKey values and verifying whether they match the values that were in place before the exploitation window (if historical backups allow this comparison), reviewing the accounts that hold Site Owner rights across all SharePoint sites and identifying any that may have been compromised before or during the exploitation window, and checking for unexpected scheduled tasks, new service accounts, or modifications to the SharePoint farm configuration that were not made by known administrators. Understanding the full scope of your external attack surface is the starting point for this assessment, because the response scope should match the exposure scope, not just the specific vulnerability that opened the initial door.
SharePoint Server is rarely a standalone system. In most enterprise deployments, it is integrated with Active Directory for authentication, with Exchange or Exchange Online for email-related workflows, with SQL Server for its content databases, and through SharePoint's Business Connectivity Services or custom integration code, with line-of-business applications such as ERP systems, CRM platforms, and financial management tools. An attacker who achieves code execution on a SharePoint Server therefore has a starting point that is directly connected to a wide range of internal systems and services, not just the document libraries and sites that SharePoint hosts.
The farm service account, the account under which SharePoint's application pools and services run, typically has elevated rights on the servers in the SharePoint farm and on the SQL Server databases that host SharePoint content. This account is a high-value credential target: if an attacker can extract it from the SharePoint server, they can use it to authenticate to the SharePoint databases and read or modify content directly at the database level, bypassing SharePoint's own access controls entirely. The service account may also have permissions on other SQL Server instances if the same account is used for multiple services, a configuration practice that is discouraged but common in environments where SharePoint was deployed without a dedicated security review of the service account architecture.
The combination of document access and network positioning makes a compromised SharePoint server a powerful reconnaissance platform. An attacker can use SharePoint's built-in search index to locate sensitive documents across the entire SharePoint farm without navigating individual sites, access the SharePoint user profile database to enumerate employees and their roles, and review SharePoint site permissions to identify which accounts have the most privileged access to the most sensitive content. All of this information is available to anyone who can run code on the SharePoint server, regardless of their SharePoint permissions, because server-side code access bypasses the permission model that SharePoint enforces for authenticated web users.
For organisations assessing the blast radius of a potential CVE-2026-58644 exploitation, the relevant scope extends well beyond the documents stored in SharePoint. It includes the credentials that were accessible to the SharePoint farm service account, the network connectivity available from the SharePoint server's position in the infrastructure, and the integration points that connect SharePoint to other enterprise systems. The indicators of compromise associated with these post-exploitation paths are different from those specific to the initial deserialization vulnerability, and investigating only the initial access vector while ignoring what could have followed it leaves the response incomplete.
Vulnerabilities like CVE-2026-58644 are valuable to attackers not only for the immediate code execution they enable but for what comes after: credentials extracted from the compromised server, session tokens harvested from SharePoint's authentication layer, and sensitive documents accessed before remediation closes the window. These materials find their way into dark web markets, stealer logs shared on criminal forums, and initial access broker listings where the next buyer in the chain is already waiting.
Defendis monitors these channels in real time. If credentials or data linked to your organisation surface following an on-premises server compromise, Defendis surfaces the exposure with full context: the individual affected, the data exposed, and how the compromise likely unfolded. That context lets your team respond to the specific confirmed risk rather than running a broad, unfocused investigation from scratch.
Book a demo to see how Defendis approaches dark web monitoring for enterprise security teams.
