SharePoint CVE-2026-50522: the machine keys outlive the patch

On July 22, 2026, CISA added CVE-2026-50522 to the Known Exploited Vulnerabilities catalog with a remediation deadline of July 25 — three days. It is the fourth on-premises SharePoint vulnerability to enter that catalog in twenty-two days. What makes this one worth writing about is not the CVSS 9.8, and not the pre-auth remote code execution. It is what the attackers do with the code execution once they have it: they read the server's ASP.NET machine keys and leave. Those keys are still valid after you install the July update. The patch closes the door they came through and leaves them holding a key to the building.

Four SharePoint CVEs in CISA KEV in 22 days

Pulled straight from the KEV JSON feed (catalog version 2026.07.22), the on-prem SharePoint entries of the last month:

CVE	Added to KEV	Due	Class	Note
CVE-2026-45659	2026-07-01	2026-07-04	CWE-502 deserialization	Authenticated RCE, patched silently in May
CVE-2026-56164	2026-07-14	2026-07-17	CWE-306 missing authentication	Privilege escalation over the network
CVE-2026-58644	2026-07-16	2026-07-19	CWE-502 deserialization	Unauthenticated RCE
CVE-2026-50522	2026-07-22	2026-07-25	CWE-502 deserialization	Unauthenticated RCE, machine-key theft

Every one of those required-action fields cites BOD 26-04, the directive that in June 2026 replaced BOD 22-01's flat fourteen-day rule with risk-tiered deadlines. Internet-facing critical software lands in the shortest tier, which is how a CVE published on July 14 ends up with a July 25 deadline. CISA also issued a standalone hardening alert on July 14 naming four separate SharePoint CVEs under active exploitation. This is not a vulnerability. It is a season.

Exposure is smaller than the noise suggests but concentrated badly. Censys mapping cited by Help Net Security puts roughly 1,500 internet-facing instances in the affected line, most identifying as SharePoint Server 2019 — the version most likely to hold a decade of accumulated document libraries for an organisation that never finished its cloud migration.

Inside CVE-2026-50522: a forged token at /_trust/default.aspx

The bug is CWE-502, deserialization of untrusted data, scored CVSS 9.8 with the vector 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.

A researcher publishing as Janggggg released a PowerShell proof-of-concept on GitHub on July 20. Per BleepingComputer's write-up, it delivers a malicious .NET BinaryFormatter payload as the cookie of a forged SecurityContextToken, wrapped in a WS-Federation sign-in response and POSTed to /_trust/default.aspx. SharePoint's federated-authentication path takes that token and deserializes it before establishing that the sender is anybody at all, reconstructing the attacker's object graph into live .NET objects. BinaryFormatter is the gadget substrate ysoserial has industrialised for a decade: control what it rebuilds and you control the process.

The endpoint choice is the elegant part. /_trust/default.aspx is the sign-in receiver. It has to be reachable pre-authentication — that is its entire job. Access-control hardening around /_layouts/ does nothing for it.

The advisory said "Site Owner". The exploit did not agree

Read Microsoft's own record for this CVE and you find two incompatible statements sitting side by side. The FAQ says:

In a network-based attack, an attacker authenticated as at least a Site Owner, could write arbitrary code to inject and execute code remotely on the SharePoint Server.

The CVSS vector on the same advisory says PR:N — no privileges required. NVD's description says "an unauthorized attacker". The exploitation observed in the wild is unauthenticated, a discrepancy Security Affairs flagged explicitly. A defender who triaged this CVE by reading the FAQ — the paragraph written in prose, the one a human actually reads — concluded they were looking at a post-authentication bug reachable only by users who already hold site ownership. That is a Tuesday-next-month patch, not a tonight patch.

The machine-readable fields were no better. Microsoft's exploitability assessment at publication read Publicly Disclosed:No; Exploited:No; Latest Software Release: Exploitation More Likely, with a temporal vector of E:U — exploit maturity unproven. Defused was already seeing undocumented SharePoint deserialization attacks three days later, on July 17. By July 20 there was a working public PoC. By July 22 it was in KEV. "Unproven" had a shelf life of eight days.

Microsoft's analysts are forecasting the future like everyone else, and the point is not that they got it wrong. It is that exploitability ratings are a prior, and a weak one. The only measurement that returns a fact instead of a forecast is running the attack against your own server.

Why the machine keys are the actual breach

ASP.NET protects __VIEWSTATE — the serialized state blob that round-trips through the browser on every classic ASP.NET page — with a MAC derived from the validationKey in web.config, optionally encrypting it with the decryptionKey. The server trusts any ViewState carrying a valid signature. That trust is the whole design: it is how the framework knows the state it is deserializing is state it sent.

So the highest-value move after landing code execution on SharePoint is not dropping a web shell. It is reading validationKey and decryptionKey out of the configuration, exfiltrating 128 hexadecimal characters, and disconnecting. watchTowr, whose Attacker Eye honeypot network captured successful compromises within hours of the PoC going public, put it plainly: attackers are pulling machine keys in a single request, and "patching is not enough, defenders should rotate credentials on any assets that may have been exposed."

With those keys an attacker signs an arbitrary serialized payload and POSTs it as __VIEWSTATE to any ordinary page on the farm. The server validates the signature — correctly, because the signature is genuine — deserializes the payload, and executes it. No CVE is involved. Consider what each side sees:

Blue team, August: "We patched CVE-2026-50522 on July 22, well inside the KEV deadline. The scanner is clean. The vulnerability management dashboard is green for the SharePoint farm."

Red team, August: "We don't need the vulnerability. We took the farm's signing key on July 20. Every request we send is cryptographically valid. We are not exploiting your server, we are authenticating to it."

Patch status and security status are different variables, and the July 2026 SharePoint wave is the cleanest demonstration of that gap in recent memory. A stolen validationKey converts a one-time vulnerability into standing authorisation, and there is no patch for standing authorisation. There is only rotation.

The precedent is exactly one year old. CVE-2025-53770 — "ToolShell", July 2025 — had the same shape: unauthenticated deserialization in on-prem SharePoint, machine keys stolen, persistence surviving the emergency patch, the spinstall0.aspx web shell in the LAYOUTS directory. Organisations that patched ToolShell and did not rotate stayed compromised. The industry has now run this experiment twice.

What the intrusion looks like after the patch

Resecurity's analysis of the July 2026 SharePoint attacks traces the chain past initial access, and the post-exploitation behaviour is what defenders should be hunting for. Their reporting describes:

• Web shells written to ...\16\TEMPLATE\LAYOUTS\ and C:\inetpub\wwwroot\wss\VirtualDirectories\80\_layouts\ — filenames observed include spinstall0.aspx, info3.aspx, and AssetHandler.axd posing as a handler.
• validationKey and decryptionKey lifted from web.config by reflection, then either ViewState forgery or a malicious IIS module (FarmAuthNative.dll) registered in applicationHost.config — persistence that survives both patching and web-shell cleanup.
• The farm service account used to pivot into SQL Server and Active Directory. SharePoint sits on the identity plane; RCE there is a route to the domain, not a destination.
• Exfiltration staged in hidden document libraries, files renamed to .log and .tmp, then egressed over HTTPS in 5 MB chunks — deliberately sized under the DLP thresholds that fire on bulk transfer.

That last bullet is a detection problem, not a patching problem. Chunked, TLS-wrapped, originating from a legitimate service account on a server whose job is to serve documents: every individual request is unremarkable. The signal only exists in the aggregate shape of the traffic over hours.

Remediation

1. Am I affected?

Check the farm build, not the KB list — a KB can be installed on some servers of a farm and not others.

# On any SharePoint server, run in the SharePoint Management Shell
Get-SPFarm | Select-Object BuildVersion
(Get-SPFarm).Servers | Select-Object Name, Status, Role
Get-SPProduct -Local | Select-Object ProductName, @{n='Patches';e={$_.PatchableUnitDisplayNames}}

You are vulnerable if the build is below the fixed build for your edition:

Edition	Fixed build	KB
SharePoint Enterprise Server 2016	16.0.5561.1001	KB5002891
SharePoint Server 2019	16.0.10417.20175	KB5002883
SharePoint Server Subscription Edition	16.0.19725.20434	KB5002882

Then establish exposure. /_trust/default.aspx reachable from the internet is the condition that turns this from urgent to emergency:

curl -sk -o /dev/null -w '%{http_code}\n' https://<host>/_trust/default.aspx

SharePoint Online is not affected. This is an on-premises-only issue.

2. Patch — exact fixed versions

Install the update for your edition on every server in the farm, then run the configuration wizard so the binaries and the content databases agree:

# after installing the KB on each server, on each server in turn:
PSConfig.exe -cmd upgrade -inplace b2b -wait -cmd applicationcontent -install -cmd installfeatures

Verify with Get-SPFarm | Select BuildVersion on each node. A farm where one WFE is unpatched is an unpatched farm.

3. Can't patch now? Compensating controls

• Enable AMSI integration in Full Mode for SharePoint and pair it with an up-to-date antimalware engine on every farm server. This is Microsoft's own primary mitigation for this class of deserialization attack and it blocks the request before the payload deserializes. If you cannot enable AMSI, key rotation after patching is not optional.
• Remove /_trust/default.aspx from internet reachability. If federated sign-in is not in use externally, block the path at the reverse proxy or WAF. This endpoint has no business being open to the world in most deployments.
• Block POST requests to /_trust/default.aspx carrying oversized cookies at the edge; the forged SecurityContextToken cookie is anomalously large.
• Disconnect the farm from the internet if it is internet-facing and cannot be patched or AMSI-protected within the KEV deadline. CISA's required action explicitly permits discontinuing use where mitigations are unavailable.

4. Hunt for compromise

Assume exposure if the server was internet-reachable and unpatched at any point between July 14 and the moment you patched. Hunt across four surfaces.

IIS logs — look for the initial access attempt and the ToolShell-lineage patterns Resecurity reported:

# POSTs to the federated sign-in receiver
findstr /i "_trust/default.aspx" C:\inetpub\logs\LogFiles\W3SVC*\*.log | findstr "POST"
# ToolPane with edit mode + spoofed SignOut referer
findstr /i "ToolPane.aspx" C:\inetpub\logs\LogFiles\W3SVC*\*.log | findstr /i "DisplayMode=Edit"

Filesystem — any .aspx or .axd in the layouts directories newer than your last legitimate deployment is suspect until proven otherwise:

$p = @(
  "C:\Program Files\Common Files\Microsoft Shared\Web Server Extensions\16\TEMPLATE\LAYOUTS",
  "C:\inetpub\wwwroot\wss\VirtualDirectories"
)
Get-ChildItem $p -Recurse -Include *.aspx,*.asmx,*.ashx,*.axd -ErrorAction SilentlyContinue |
  Where-Object { $_.LastWriteTime -gt (Get-Date).AddDays(-30) } |
  Select-Object FullName, LastWriteTime, Length | Sort-Object LastWriteTime -Descending

Named IOCs from Resecurity's reporting: spinstall0.aspx, info3.aspx, AssetHandler.axd, FarmAuthNative.dll.

IIS configuration — the module-based persistence is the one that survives a web-shell sweep:

Get-WebGlobalModule | Select-Object Name, Image | Sort-Object Name
%windir%\system32\inetsrv\appcmd.exe list config /section:system.webServer/globalModules

Cross-check every native module against a known-good farm. Windows Event Log IDs 29 and 50 in the IIS-Configuration channel record module additions and configuration changes.

Process ancestry — w3wp.exe spawning cmd.exe, powershell.exe, or csc.exe is the highest-fidelity single signal available. SharePoint's worker process compiling C# at runtime is normal exactly once, at first page load after a deployment; it is not normal at 03:00 on a Sunday.

ATT&CK mapping for the chain: T1190 (exploit public-facing application) → T1505.003 (web shell) → T1552.001 (credentials in files — the machine keys in web.config) → T1546.003/T1505.004 (IIS module persistence) → T1078 (valid accounts, via forged ViewState) → T1041 (exfiltration over C2 channel).

5. Eradicate and verify

Rotate the machine keys. This is the step that ends the incident, and patching does not do it for you.

# Rotate for each web application, then restart IIS across the farm
Get-SPWebApplication | ForEach-Object { Update-SPMachineKey -WebApplication $_ }
# every server in the farm:
iisreset.exe /noforce

Or via Central Administration → Monitoring → Review job definitions → Machine Key Rotation Job → Run Now, per Microsoft's ViewState key-management guidance. On Subscription Edition 25H1 and the September 2025 public update for 2016/2019, automatic rotation is available — turn it on.

Order matters and gets this wrong in practice more often than not: patch first, then rotate. Rotating a key on a still-vulnerable server just hands the attacker a fresh one on their next request.

Then finish the job:

1. Rotate the farm service account and application-pool identity passwords, plus any credential stored in the Secure Store Service.
2. Remove web shells and unrecognised native IIS modules; re-run the filesystem and globalModules sweeps afterwards to confirm they stay gone.
3. Audit the SharePoint farm account's footprint in Active Directory — group memberships added since July 14, new service principals, Kerberos delegation changes.
4. Review outbound egress from the SharePoint servers for the previous fourteen days, specifically sustained small-chunk HTTPS to destinations the farm has no history of contacting.
5. Re-test. After rotation, replay the attack: does a __VIEWSTATE signed with the old key still validate? If it does, the rotation did not take effect across every web application and every server, which is the most common failure mode of this remediation.

Step 5 is the one that gets skipped, and it is the only step that produces evidence rather than intention.

Where continuous, adversarial validation changes the outcome

Everything above assumes you can answer one question: after all that work, is the server actually clean? A scanner cannot tell you. It reads the build number, compares it against 16.0.10417.20175, and reports compliant. It does not sign a ViewState with the key you were supposed to have retired and check whether the farm accepts it.

That is the gap Zero Hunt's 10-agent AI swarm is built to close. The Recon agent maps which /_trust/default.aspx endpoints are genuinely reachable from outside, rather than which ones the network diagram calls internal. The Exploit agent writes the chain fresh for your environment — generative, per-target code produced by a local LLM on the appliance, not a downloaded PoC a WAF signature already knows. The Post-Exploit agent goes after what matters: it attempts machine-key extraction, then, after your rotation, attempts to reuse the old key. A forged ViewState that still executes is a finding. A forged ViewState that fails is proof — timestamped and ECDSA-signed at write time, which is the artefact an auditor will ask for when BOD 26-04 and NIS2 both want to know what you did between July 22 and July 25. Every skill the swarm uses is backtested in the AI Gym against Vulhub, NYU CTF Bench and 314 CVE-based black-box tasks before it goes near a production farm, and it all runs on-premises with no cloud callback — which matters when the target is the document store holding your legal and HR files. Pointed at this attack pattern, the engine's Knowledge RAG surfaced CVE-2025-53770 — ToolShell — within three hops, unprompted: the machine had already seen this movie and recognised the sequel from the deserialization path alone.

The exfiltration half needs a different sensor. Chunked 5 MB HTTPS transfers out of a document server, staged from hidden libraries under a legitimate farm account, trip no signature and look wrong in no single request. Zero Hunt's AI Traffic Analysis model — four parallel inference heads for suspicious traffic, malware classification, attack-type identification and application fingerprinting, trained on billions of PCAP sequences and running at 2.7+ Gbit/s on the appliance GPU — scores the shape of the session rather than the payload, while the transfer is happening rather than in the morning's SIEM digest. For an intrusion whose defining property is that every request it sends is cryptographically valid, behaviour is the only thing left to detect.

Four SharePoint CVEs in twenty-two days is not a patching problem you can win by patching faster. See how continuous validation differs from periodic scanning, or get in touch if you want the July SharePoint wave re-run against your own farm.