CVE-2026-50522 is an unauthenticated deserialization remote code execution flaw (CWE-502) in on-premises Microsoft SharePoint Server. NVD scores it 9.8 (CVSS:3.1/AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:H/A:H). Microsoft shipped the fix in the July 14, 2026 updates and rated exploitation "More Likely" at release. Honeypot operator Defused captured exploitation attempts on July 17, a public proof-of-concept appeared on July 20, watchTowr recorded successful compromises across its honeypot network within hours of that release, and CISA added the CVE to the Known Exploited Vulnerabilities catalog on July 22 with a July 25 federal remediation deadline. The reported post-exploitation objective is theft of the farm's ASP.NET machine keys, which is why patching alone does not close this out. SharePoint Online and Microsoft 365 are not affected.
This is the third SharePoint remote code execution flaw exploited in a month, alongside CVE-2026-58644 and CVE-2026-45659. The same July 14 update packages remediate all of them.
Am I vulnerable?
Exposure is a function of build version, not of which SharePoint features you have enabled. Any on-premises farm running a build below the July 2026 fixed level is exploitable, and reachability from the internet raises it from a hunt item to an incident-response item. Censys counted roughly 1,500 internet-exposed on-premises SharePoint instances on July 17, predominantly SharePoint Server 2019.
Affected versions
| Product |
Vulnerable range |
Fixed build |
| SharePoint Enterprise Server 2016 |
16.0.0 through 16.0.5561.1000 |
16.0.5561.1001 |
| SharePoint Server 2019 |
16.0.0 through 16.0.10417.20174 |
16.0.10417.20175 |
| SharePoint Server Subscription Edition |
16.0.0 through 16.0.19725.20433 |
16.0.19725.20434 |
Note the fixed builds on Server 2019 and Subscription Edition differ from the vulnerable ceiling only in the fourth (revision) field. Comparing the first three fields will tell you nothing.
Diagnostic commands
Read-only checks, safe to run on production:
- Farm build (SharePoint Management Shell):
(Get-SPFarm).BuildVersion. Vulnerable if the build is below your SKU's fixed threshold, for example a Server 2019 farm reporting Major 16, Minor 0, Build 10417, Revision 20174.
- Per-server patch state across the farm:
Get-SPProduct -Local | Format-List ProductName, PatchableUnitDisplayNames, Servers. A farm where the July 2026 package was installed but PSConfig was never run still serves vulnerable binaries, so treat any "upgrade required" or version-mismatch output as unpatched.
- On-disk assembly version (per-server ground truth):
(Get-Item "$env:CommonProgramFiles\Microsoft Shared\Web Server Extensions\16\ISAPI\Microsoft.SharePoint.dll").VersionInfo.FileVersion. This reflects what IIS actually loads, independent of what the configuration database reports.
- Registry-recorded build (no SharePoint snap-in required):
Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Office Server\16.0' | Select-Object BuildVersion, PatchVersion.
- External exposure sweep:
curl -s -I -4 https://<sharepoint-host>/ | grep -i 'MicrosoftSharePointTeamServices'. The header returns a build in the form 16.0.0.10417. Censys warns that this header omits the revision field, so on Server 2019 and Subscription Edition it identifies an exposed on-premises farm but cannot confirm patch status. Use it to build the target list, then confirm with a local check.
Vulnerability
The flaw is a deserialization of untrusted data (CWE-502) in SharePoint's federated sign-in path. Per BleepingComputer's reporting, the attack reaches /_trust/default.aspx, the WS-Federation sign-in response handler, and delivers a malicious .NET BinaryFormatter payload embedded inside a forged SecurityContextToken cookie. The vulnerable code path deserializes that token before establishing an authenticated session, so the gadget chain executes as the SharePoint application pool identity inside w3wp.exe. In most farms that identity is a domain service account with elevated rights on the SQL Server backend, not a sandboxed low-privilege user.
The CVE originated at Pwn2Own Berlin 2026, where splitline of the DEVCORE Research Team chained two bugs against a default SharePoint installation through a single unauthenticated HTTP request. Microsoft credits DEVCORE in the advisory acknowledgements.
One discrepancy is worth resolving before you scope the risk. Microsoft's CVSS vector is PR:N and its description says "unauthorized attacker", but the MSRC FAQ states an attacker would need to be authenticated as at least a Site Owner. Defused's captured exploitation requests carry no authentication material at all, and the Pwn2Own demonstration used an unauthenticated request. Treat this as unauthenticated.
The second-stage behaviour reported by watchTowr is the part that changes remediation planning. Attackers are retrieving the server's IIS and ASP.NET machine keys in a single request. Those keys sign and encrypt ViewState and authentication tokens, so an attacker holding them can mint valid tokens and impersonate users at their privilege level without touching the vulnerable code path again. That access survives installation of the patch. The same technique drove Microsoft's existing SharePoint hardening guidance after the 2025 ToolShell chain (CVE-2025-53770).
Threat model
Who would exploit this: The most likely operators are opportunistic, mass-scanning criminals and initial-access brokers. A public proof-of-concept landed on July 20, 2026 and honeypot networks recorded successful exploitation within hours, which is the signature of commodity scanning rather than patient targeted intrusion. On-premises SharePoint farms sit disproportionately in government, healthcare, manufacturing, legal, and enterprises that never migrated to Microsoft 365, so state-aligned collectors have a strong secondary interest in the same target set. Insiders are the least relevant category, because the flaw needs no credentials and no internal position.
What they are after:
- Initial foothold on an internet-facing server (unauthenticated, no user interaction, reliable)
- ASP.NET and IIS machine keys, retrievable in a single request, enabling forged authentication tokens
- Persistence that survives patching, via those keys and via web shells dropped in SharePoint template directories
- Data exfiltration from content databases: contracts, HR records, intellectual property, internal documentation
- Lateral movement into Active Directory and SQL Server using the farm service account
- Access resale by brokers to ransomware and extortion affiliates
Attack chain: Operators enumerate internet-exposed SharePoint using Shodan, Censys, and direct scanning, then send a single crafted unauthenticated request to the sign-in endpoint that reaches the deserialization sink. Code executes in the context of the SharePoint application pool identity inside w3wp.exe. Reported follow-on activity is theft of the server's machine keys plus web shells written into the LAYOUTS directory under the Web Server Extensions template path. With the keys in hand, an attacker forges valid authentication and ViewState tokens, and the farm service account provides a path onward into SQL Server and Active Directory.
Blast radius: A compromised farm exposes every content database it serves, which in practice means contracts, HR files, board and legal material, design documents, and the credentials people routinely paste into documents and site pages. The farm service account typically carries elevated rights on the SQL backend and is a domain account, so the compromise extends to database contents and to adjacent file shares and Active Directory objects reachable by that identity. The most durable damage is the machine keys: an attacker who took them before you patched retains access after you patch.
CISA records knownRansomwareCampaignUse as Unknown for this CVE. No primary source names a specific actor or campaign, so this write-up makes no attribution.
Mitigation
Patch
Microsoft's July 14, 2026 updates fix this. There is no CVE-specific vendor workaround; "Customer Action Required" is marked Yes.
| Product |
Fixed build |
Update |
| SharePoint Enterprise Server 2016 |
16.0.5561.1001 |
KB5002891 (supersedes KB5002880) |
| SharePoint Server 2019 |
16.0.10417.20175 |
KB5002883 (supersedes KB5002874) |
| SharePoint Server Subscription Edition |
16.0.19725.20434 |
KB5002882 (supersedes KB5002873) |
Install on every server in the farm and run PSConfig. A farm with one lagging node is still exploitable through that node.
Configuration mitigation
Sequencing matters here. Microsoft's guidance, as relayed by Help Net Security, is to hunt for and remediate intrusion artifacts before rotating machine keys. Rotation does not evict an actor already resident on the host, and rotating first destroys the token evidence you would use to scope the intrusion.
Enable AMSI in Full Mode together with Microsoft Defender Antivirus on all SharePoint servers. This is Microsoft's standing on-premises SharePoint hardening guidance and was reiterated in CISA's July 14, 2026 alert.
Rotate ASP.NET view state machine keys after patching and after hunting:
# Run from SharePoint Management Shell as a farm administrator.
# Omitting -DecryptionKey/-ValidationKey generates random keys.
Set-SPMachineKey -WebApplication <SPWebApplicationPipeBind>
# Deploy the new decryption and validation keys to every server in the farm.
# Skipping this (or using -Local) leaves load-balanced sessions failing across unsynchronised servers.
Update-SPMachineKey -WebApplication <SPWebApplicationPipeBind>
# Restart IIS on ALL SharePoint servers in the farm once rotation has completed.
iisreset.exe
Alternative: the built-in rotation timer job (Subscription Edition 25H1 and later, or SharePoint 2016/2019 with the September 2025 PU or later):
Central Administration -> Monitoring -> Review job definitions -> "Machine Key Rotation Job" -> Run Now
The job runs weekly by default and reports no visible change on completion. Subscription Edition encrypts the machineKey section of web.config, so keys are not readable from web.config alone on that SKU.
Compensating controls
- Remove internet exposure from any on-premises farm that does not need it. Front the rest with a reverse proxy or VPN, and rate-limit unauthenticated POSTs to sign-in endpoints.
- Reduce the farm service account's blast radius: strip local administrator rights where the farm does not require them, constrain its SQL permissions to the content databases it owns, and confirm it is not a member of privileged domain groups.
- Rotate the farm service account credentials alongside the machine keys on any farm that was internet-reachable and unpatched between July 14 and the date you patched.
- Baseline the LAYOUTS and virtual directory trees against known-good post-patch content on every front-end, and alert on writes by the application pool identity.
Detection (starter rules — validate before deploying)
These rules are AI-generated starter content. Test against your own telemetry and tune falsepositives before deploying to production.
Network and log signals
- IIS logs (
C:\inetpub\logs\LogFiles\W3SVC*\): POST requests to sign-in and authentication endpoints (/_trust/default.aspx, /_layouts/15/signin.aspx, /_forms/default.aspx, /_layouts/15/Authenticate.aspx) that carry no authentication material (blank cs-username, no session cookie) yet return 200 or 302, with a cs-bytes body size well above your baseline for those URIs. Sort the last 30 days by cs-bytes descending per URI and review the outliers plus any single source IP sweeping many vhosts.
- New or modified
.aspx, .ashx, .asmx, or .dll files under C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS\ and C:\inetpub\wwwroot\wss\VirtualDirectories\<port>\, with timestamps outside a patch or deployment window and created by the application pool identity. Diff against a known-good baseline rather than matching file names, which rotate.
- Forged
__VIEWSTATE reuse: requests bearing large __VIEWSTATE values from IPs or user agents with no prior session, the same blob replayed from multiple sources, or a successful request pattern that continues after the patch was applied. After rotating keys, alert on continued acceptance of pre-rotation tokens.
- Outbound connections from
w3wp.exe under the SharePoint app pool identity to non-baseline destinations. Legitimate traffic goes to SQL, domain controllers, and internal services, so HTTPS egress to unfamiliar hosts, raw TCP on odd ports, or lookups of newly registered domains from that process is a strong second-stage indicator.
- ULS logs (
...\16\LOGS\): bursts of unhandled exceptions, serialization or ViewState MAC validation errors, and cryptographic failures from the sign-in pipeline, plus unexplained app pool recycles correlated with the anomalous POST bursts. Failed attempts leave exception noise even when successful ones do not.
- Persistence performed by the app pool identity rather than an admin account: new scheduled tasks or services, new local or domain accounts, IIS module or handler registrations,
web.config writes, and encoded PowerShell whose parent chain traces back to w3wp.exe.
YARA
rule SharePoint_CVE_2026_50522_PostExploit_ASPX_Artifacts
{
meta:
description = "Starter rule for ASPX artifacts dropped after exploitation of the SharePoint deserialization RCE CVE-2026-50522: generic webshells and machine key dumpers written under TEMPLATE\\LAYOUTS or the IIS web root"
author = "CVE Brief (AI-generated starter rule)"
date = "2026-07-27"
reference = "https://nvd.nist.gov/vuln/detail/CVE-2026-50522"
cve = "CVE-2026-50522"
confidence = "medium"
note = "AI-generated starter rule. No CVE-specific file hashes are asserted. Scope scanning to SharePoint web directories and validate against known-good farm content before deploying."
strings:
// ASPX / ASP.NET server page markers
$aspx1 = "<%@ Page" ascii nocase
$aspx2 = "<%@ Assembly" ascii nocase
$aspx3 = "<%@ Import" ascii nocase
$aspx4 = "<script runat" ascii nocase
$aspx5 = "<%@ WebHandler" ascii nocase
// Generic request-to-execution webshell plumbing
$shell1 = "Request.Form[" ascii nocase
$shell2 = "Request.Item[" ascii nocase
$shell3 = "Request.QueryString[" ascii nocase
$shell4 = "System.Diagnostics.Process" ascii nocase
$shell5 = "ProcessStartInfo" ascii nocase
$shell6 = "RedirectStandardOutput" ascii nocase
$shell7 = "cmd.exe /c" ascii nocase
$shell8 = "FromBase64String" ascii nocase
$shell9 = "eval(Request" ascii nocase
$shell10 = "Assembly.Load" ascii nocase
// Machine key / crypto secret theft (observed objective: forged __VIEWSTATE persistence)
$key1 = "MachineKeySection" ascii nocase
$key2 = "ValidationKey" ascii nocase
$key3 = "DecryptionKey" ascii nocase
$key4 = "System.Web.Configuration" ascii nocase
$key5 = "GetApplicationConfig" ascii nocase
$key6 = "compilationSection" ascii nocase
// .NET deserialization formatter and gadget indicators
$des1 = "LosFormatter" ascii nocase
$des2 = "ObjectStateFormatter" ascii nocase
$des3 = "BinaryFormatter" ascii nocase
$des4 = "ObjectDataProvider" ascii nocase
$des5 = "TypeConfuseDelegate" ascii nocase
$des6 = "ActivitySurrogateSelector" ascii nocase
// Base64 form of the standard BinaryFormatter serialization header record
$des7 = "AAEAAAD/////" ascii
condition:
filesize < 500KB
and any of ($aspx*)
and (
2 of ($shell*)
or 2 of ($key*)
or any of ($des*)
)
}
Sigma
title: SharePoint IIS Worker Process Spawning Suspicious Child Process (CVE-2026-50522 Post-Exploitation)
id: b4d1f6c2-9e37-4a58-b0c1-2f7a5e93d84c
status: experimental
description: |
Detects the SharePoint IIS worker process (w3wp.exe) spawning command interpreters, discovery utilities, download tools, or an unexpected .NET compiler.
This is the highest-signal post-exploitation behaviour for the unauthenticated .NET deserialization RCE CVE-2026-50522 in SharePoint Server 2016, 2019, and Subscription Edition,
where attacker-supplied gadget chains execute inside w3wp.exe under the SharePoint application pool identity.
Tune by restricting to hosts running SharePoint, or by adding a ParentCommandLine filter for your SharePoint application pool GUIDs.
AI-generated starter rule. Validate in your environment before deploying.
author: CVE Brief (AI-generated starter rule)
date: 2026/07/27
references:
- https://nvd.nist.gov/vuln/detail/CVE-2026-50522
- https://www.cisa.gov/known-exploited-vulnerabilities-catalog
tags:
- attack.initial-access
- attack.t1190
- attack.execution
- attack.t1059.001
- attack.t1059.003
- attack.persistence
- attack.t1505.003
logsource:
category: process_creation
product: windows
detection:
selection_parent:
ParentImage|endswith: '\w3wp.exe'
selection_interpreter:
Image|endswith:
- '\cmd.exe'
- '\powershell.exe'
- '\pwsh.exe'
- '\wscript.exe'
- '\cscript.exe'
- '\mshta.exe'
- '\rundll32.exe'
- '\regsvr32.exe'
- '\certutil.exe'
- '\bitsadmin.exe'
- '\curl.exe'
- '\net.exe'
- '\net1.exe'
- '\whoami.exe'
- '\nltest.exe'
- '\schtasks.exe'
- '\sc.exe'
selection_compiler:
Image|endswith:
- '\csc.exe'
- '\vbc.exe'
filter_aspnet_compilation:
CommandLine|contains:
- 'Temporary ASP.NET Files'
- '.cmdline'
condition: selection_parent and (selection_interpreter or (selection_compiler and not filter_aspnet_compilation))
fields:
- Image
- CommandLine
- ParentImage
- ParentCommandLine
- User
- ProcessId
falsepositives:
- ASP.NET runtime page compilation, which legitimately spawns csc.exe or vbc.exe from w3wp.exe (excluded by the filter, but non-default compilation paths will still fire)
- Custom or third-party SharePoint solutions, timer job wrappers, and workflow activities that intentionally shell out to cmd.exe or powershell.exe
- Backup, patching, monitoring, inventory, and antivirus agents that execute helper binaries in the context of the web application
- Administrators running diagnostics or maintenance scripts through a web-based management interface hosted on the same server
- Application pool health checks or startup scripts configured to invoke net.exe or sc.exe
level: high
Rule notes
The Sigma rule keys on process ancestry (w3wp.exe spawning an interpreter, discovery, or download binary, plus .NET compiler invocations lacking the normal ASP.NET compilation command line), which is the lowest-noise evidence that a deserialization payload executed inside the SharePoint worker process. It covers post-exploitation only: a payload that stays in memory and never spawns a child process, including the single-request machine key theft, will not trigger it. That gap is why the log signals above matter as much as the rule. The YARA rule is deliberately generic behavioural coverage for dropped ASPX webshells and key dumpers rather than any specific sample, so baseline it against legitimate LAYOUTS content before enabling it farm-wide.
References