CVE-2026-50522: Patch Critical SharePoint RCE Now

CVE-2026-50522 gives an unauthenticated remote attacker a path to execute code on vulnerable on-premises Microsoft SharePoint servers, earning Microsoft’s highest practical CVSS v3.1 rating of 9.8 Critical. The flaw was disclosed with Microsoft’s July 14, 2026 security updates and affects SharePoint Enterprise Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition.
Detailed in Microsoft’s Security Update Guide, the vulnerability stems from deserialization of untrusted data in Microsoft Office SharePoint. Microsoft’s CVSS vector describes a network-based, low-complexity attack that requires neither privileges nor user interaction, with potentially high impact to confidentiality, integrity, and availability.
Administrators should treat the July SharePoint updates as an emergency change for any internet-facing farm. Microsoft has confirmed that the vulnerability exists and has released corrected builds, although there was no public indication at disclosure that CVE-2026-50522 itself was being actively exploited.

Cybersecurity dashboard depicts an exploited SharePoint vulnerability, threatened servers, and an urgent patch recommendation.Three Supported SharePoint Lines Need Updates​

Microsoft lists the following on-premises products and vulnerable build ranges:
  • Microsoft SharePoint Enterprise Server 2016 is affected on builds earlier than 16.0.5561.1001.
  • Microsoft SharePoint Server 2019 is affected on builds earlier than 16.0.10417.20175.
  • Microsoft SharePoint Server Subscription Edition is affected on builds earlier than 16.0.19725.20434.
Those version thresholds provide a direct compliance check for administrators and vulnerability-management teams. A server should not be considered protected merely because an update was approved in WSUS, Microsoft Configuration Manager, or another patch-management product; the installed SharePoint build must meet or exceed the corrected version for its product line.
The affected-product list is limited to Microsoft’s on-premises SharePoint Server products. Microsoft 365 SharePoint Online is not listed as vulnerable, which is consistent with Microsoft handling service-side remediation for its hosted platform rather than requiring tenants to deploy SharePoint Server packages.
Farms containing multiple application, web-front-end, search, or distributed-cache servers require particular care. The security update must be installed across the farm according to Microsoft’s supported SharePoint servicing process, followed by the required configuration work, rather than being applied to one outward-facing node and treated as complete.

The CVSS Vector Leaves Little Room for Delay​

CVE-2026-50522 carries the vector CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H. In operational terms, the important components are network reachability, low attack complexity, no required account, and no need to persuade an administrator or user to open a file or click a link.
The underlying weakness is classified as CWE-502, deserialization of untrusted data. Deserialization bugs become dangerous when an application reconstructs an object from attacker-controlled input without adequately restricting the types, properties, or code paths that can be invoked. In a server application such as SharePoint, successful exploitation can move the incident beyond a compromised site or document library and into arbitrary code execution on the server.
Microsoft rates the potential effect as high across all three core security categories. An attacker who successfully reaches the vulnerable code path could potentially read protected information, modify SharePoint content or server state, and interrupt service.
The practical impact depends on the context and permissions of the compromised SharePoint process, along with the farm’s service-account configuration and surrounding security controls. Remote code execution should nevertheless be treated as the start of a broader compromise investigation, not as an isolated application error, because an attacker may attempt credential theft, persistence, lateral movement, or access to SharePoint’s SQL Server databases and connected services.

“Confirmed” Describes Evidence, Not Active Attacks​

The report-confidence field supplied with the vulnerability is marked Confirmed. That metric addresses confidence in the existence of the flaw and the credibility of the available technical information; it does not mean Microsoft has confirmed exploitation in customer environments.
Microsoft’s acknowledgement, CVSS assessment, affected-build ranges, and released fix provide a high level of certainty that the vulnerability is real. The National Vulnerability Database had not completed its own enrichment when the record first appeared, but it reproduced Microsoft’s description and 9.8 severity assessment.
CISA’s initial SSVC data classified exploitation of CVE-2026-50522 as “none,” while judging the attack to be automatable and capable of total technical impact. That is an important but time-sensitive distinction: defenders had no public evidence of exploitation at disclosure, yet the characteristics of the flaw make it suitable for automated scanning and attacks if reliable technical details or proof-of-concept code emerge.
Administrators should also avoid confusing CVE-2026-50522 with other SharePoint vulnerabilities disclosed in the same update cycle. July’s SharePoint packages address several security defects, and at least one separately tracked SharePoint issue was associated with active exploitation reporting. Shared affected-build thresholds do not make those CVEs interchangeable, nor does exploitation of another flaw prove that CVE-2026-50522 has been weaponized.
That distinction matters for accurate incident reporting, but it should not become a reason to postpone patching. Internet-facing SharePoint servers have a history of attracting rapid attention after critical vulnerabilities become public, particularly when exploitation requires no authentication.

Installing the Package Is Only Half the SharePoint Job​

SharePoint servicing is more involved than installing a normal Windows cumulative update. Administrators must update every server in the farm and complete the SharePoint Products Configuration Wizard or the supported PSConfig.exe process where required, ensuring databases, features, and application content are upgraded consistently.
Before deployment, teams should record the current farm build, verify recent backups, check database availability, and review available disk space on each server. A staged approach can reduce outage risk in farms designed for high availability, but leaving a vulnerable web front end online while other nodes are upgraded preserves an attack path.
After installation, administrators should verify:
  • Every SharePoint server reports the corrected or later build for its product version.
  • The SharePoint configuration process completes successfully on all required nodes.
  • Central Administration shows no pending upgrade work or servers requiring attention.
  • Web applications, search, authentication, workflows, and Office integration function normally.
  • Security monitoring continues to watch IIS, SharePoint, Windows, and endpoint-protection logs for suspicious activity.
Organizations unable to patch immediately should reduce external exposure rather than relying on the absence of published exploitation. Restricting SharePoint access through a VPN, reverse proxy, application gateway, or tightly controlled network allowlist can lower risk, although those measures do not repair the vulnerable deserialization code.
A web application firewall may detect some exploit attempts after signatures become available, but it is not a substitute for Microsoft’s update. Deserialization payloads can be encoded or shaped in ways that make generic filtering unreliable, particularly before defenders have concrete request patterns and indicators.

Previously Exposed Servers Need More Than a Build Check​

Installing the July update prevents future exploitation of the corrected code path, but it cannot determine whether an attacker reached the server beforehand. Organizations with internet-exposed SharePoint farms should preserve and review IIS logs, SharePoint diagnostic logs, Windows event logs, endpoint telemetry, and reverse-proxy records covering the period before patch installation.
Unexpected child processes launched by SharePoint or IIS components deserve scrutiny, as do newly written executable files, unusual assemblies, unfamiliar scheduled tasks, modified authentication settings, and outbound network connections from SharePoint servers. Security teams should compare findings against normal farm behavior because legitimate SharePoint administration and solution deployment can also create unusual-looking processes and file changes.
If evidence suggests code execution occurred, responders should assume that credentials and secrets accessible to the server may have been exposed. The investigation may need to extend to service accounts, machine accounts, application pools, SQL Server access, certificate material, and any systems that trust SharePoint-generated identities or tokens.
For most administrators, the immediate milestone is unambiguous: move SharePoint Enterprise Server 2016 to build 16.0.5561.1001 or later, SharePoint Server 2019 to 16.0.10417.20175 or later, and SharePoint Server Subscription Edition to 16.0.19725.20434 or later. The unresolved issue is how quickly technical exploitation details will become available—and whether attackers began probing exposed farms before defenders completed that work.

References​

  1. Primary source: MSRC
    Published: 2026-07-14T07:00:00-07:00
  2. Related coverage: caloes.ca.gov
  3. Related coverage: windowscentral.com
  4. Related coverage: techradar.com
  5. Related coverage: tomshardware.com
  6. Related coverage: pcgamer.com
 

Back
Top