2 actively exploited SharePoint RCEs (CVE-2026-50522, CVE-2026-58644): patch, rotate keys, hunt persistence

Summary. Two unauthenticated remote code execution flaws in on-premises Microsoft SharePoint Server, CVE-2026-50522 and CVE-2026-58644, both rated CVSS 9.8, are being exploited in the wild as of late July 2026. Microsoft shipped fixes for both in the July 14, 2026 security updates. CISA added CVE-2026-58644 to its Known Exploited Vulnerabilities catalog on July 16 and CVE-2026-50522 on July 22, with a three-day federal patch deadline under Binding Operational Directive 26-04. Both affect SharePoint Enterprise Server 2016, SharePoint Server 2019, and SharePoint Server Subscription Edition. The trap: attackers steal your ASP.NET machine keys during exploitation, so a patched server can still be owned. Shadowserver scans still show thousands of internet-exposed SharePoint servers, and IBM puts the 2025 global average breach cost at $4.44 million. In India, a failure to keep reasonable security safeguards can draw up to ₹250 crore under the DPDP Act. Patch, rotate machine keys, restart IIS, then hunt.

If you run SharePoint on your own servers, treat this as an incident, not a routine patch cycle. The July 2026 fixes close the door, but they do not check whether someone already walked through it and copied your keys on the way in. This runbook covers what the two flaws are, why the machine key theft matters, the exact remediation order, and how to hunt for the persistence that survives a patch.

What CVE-2026-50522 and CVE-2026-58644 are

Both vulnerabilities are deserialization of untrusted data flaws, classified as CWE-502. An unauthenticated attacker sends a crafted HTTP request carrying a malicious serialized payload to a vulnerable SharePoint endpoint. SharePoint deserializes it without validation, an attacker-controlled gadget chain runs during object reconstruction, and code executes on the server. Because SharePoint runs under a privileged application pool identity, that code lands with elevated rights on the underlying Windows host.

CVE-2026-50522 earned Microsoft's practical maximum CVSS v3.1 score of 9.8. It was disclosed in the July 14, 2026 updates, a public proof-of-concept followed, and active exploitation began soon after. CISA added it to the KEV catalog on July 22, 2026. CVE-2026-58644 is also CVSS 9.8, also deserialization, and Microsoft confirmed exploitation on disclosure. CISA added that one to KEV on July 16, 2026 and set a three-day remediation clock for federal agencies.

These two did not arrive alone. Security researchers logged this as the fourth SharePoint vulnerability exploited inside a single month, part of a sustained run of on-premises SharePoint attacks through the first half of 2026. On-premises is the exposed surface here; SharePoint Online in Microsoft 365 is not affected by this class of on-server deserialization flaw.

Timeline of the July 2026 SharePoint wave

The response window here was measured in days, not weeks. On July 14, 2026, Microsoft published fixes for both flaws in its monthly security updates, and CISA issued a SharePoint hardening alert the same day. On July 16, after Microsoft confirmed exploitation of CVE-2026-58644, CISA added it to the Known Exploited Vulnerabilities catalog and set a three-day patch deadline for federal agencies under Binding Operational Directive 26-04. By July 22, a public proof-of-concept for CVE-2026-50522 was circulating, exploitation had spread, and CISA added that vulnerability to KEV as well.

The precedent sits one year back. In July 2025, the ToolShell campaign against CVE-2025-53770 and CVE-2025-53771 established the machine key theft technique that both 2026 flaws now reuse. Teams that read the 2026 advisories as a routine patch, rather than as the second act of a known intrusion pattern, are the ones most likely to patch and stay breached. The dates tell you to move today; the 2025 history tells you patching is only the first move.

Why patching alone is not enough

The dangerous part of this attack is what happens after the initial code execution. Attackers use their foothold to read the SharePoint server's ASP.NET machine key material, the ValidationKey and DecryptionKey values that SharePoint uses to sign and encrypt view state. Help Net Security documented operators exfiltrating that key material and then forging signed `__VIEWSTATE` payloads to regain trusted execution on demand.

Once an attacker holds your validation and decryption keys, they can craft payloads the server treats as its own, impersonate users, and re-enter at will. Applying the July patch closes the deserialization hole, but it does not change the keys. A patched server whose keys leaked before the fix is still an open server. This is why the correct response is a sequence, not a single action.

This is not a theory. It is the same playbook from the 2025 "ToolShell" incident, CVE-2025-53770 and CVE-2025-53771, disclosed around July 18, 2025. In that campaign attackers dropped a web shell named spinstall0.aspx, used it to read the SharePoint machineKey configuration including the validation key, and forged their own signed view-state payloads. Bitsight's threat brief on ToolShell recorded victims across United States federal agencies, universities, and energy firms. The 2026 flaws reach the same objective through a different door. If you patched in 2025 but never rotated keys, assume the 2025 keys may still be valid and rotate now.

The remediation runbook

Order matters. Rotating keys before you have evicted a key-stealing web shell just hands the attacker your new keys. Hunt first, patch, rotate, restart, then verify. ThreatLocker's containment guidance and Microsoft's own advice converge on this sequence.

1. Hunt for existing compromise before you touch anything. Look for unfamiliar .aspx files in the SharePoint LAYOUTS and web-root directories, spinstall-style file names, and w3wp.exe spawning cmd.exe or powershell.exe. If you find key-stealing artifacts, treat the farm as compromised and run full incident response, because rotation alone will not help.

1. Confirm Antimalware Scan Interface integration is enabled for every SharePoint web application, and confirm Microsoft Defender or your endpoint agent is live on every server in the farm. AMSI is the control that catches many of these deserialization payloads at runtime.

1. Apply the correct security update for your exact build. The same KB covers SharePoint Enterprise Server 2016 and SharePoint Server 2016; SharePoint Server 2019 and Subscription Edition have their own packages. Verify each server in the farm actually installed the update, because a farm is only as patched as its slowest node.

1. Rotate the machine keys. Use the PowerShell cmdlet Set-SPMachineKey (or Update-SPMachineKey on builds that expose it), or trigger the Machine Key Rotation job from Central Administration. This invalidates every key an attacker may have stolen.

1. Restart IIS across the whole farm with iisreset on each server so the new keys load everywhere. A partial restart leaves old keys resident in memory on the servers you skipped.

1. Re-hunt with telemetry after rotation to confirm no forged-token access, no new web shells, and no scheduled tasks or services the attacker planted for persistence.

Patch only versus full remediation

The gap between "we patched" and "we are clean" is where most SharePoint incidents in 2026 are living. The table below shows why the shortcut fails.

Patching is necessary and urgent, but on its own it treats an active intrusion as if it were a routine update. If the server was reachable from the internet before July 14, 2026, plan for rotation and hunting rather than assuming the update was enough.

Detection and threat hunting

Focus your hunt on the signals that survive a patch. On the file system, enumerate recently created or modified .aspx files under the SharePoint web root and the _layouts path, and compare against a known-good baseline. Web shells in this campaign have been small .aspx files placed where SharePoint will serve them.

In IIS and Windows event logs, look for anomalous POST requests to SharePoint endpoints around and before your patch date, unexpected child processes under w3wp.exe, and any process reading the web.config machine key section. Microsoft Defender and AMSI detections for SharePoint deserialization should be reviewed for the window stretching back to at least July 14, 2026, and earlier if the server was exposed during the 2025 ToolShell wave.

Network-side, restrict who can reach the SharePoint farm. Many of the internet-exposed servers in recent Shadowserver scans had no business being reachable from the open internet. A reverse proxy, a VPN, or IP allow-listing removes most of the drive-by exploitation risk while you complete remediation. For teams standardising this kind of detection work across services, our notes on MCP server hardening with concrete CVE configs and the July 2026 Patch Tuesday triage of 570-plus flaws show the same hunt-then-remediate discipline applied more broadly.

Reduce SharePoint's attack surface going forward

Two configuration changes cut the long-term risk. First, adopt the automatic machine key rotation timer job. Stefan Gossner documented the automatic rotation job introduced with the September 2025 cumulative update, which periodically refreshes the ASP.NET keys used for view-state encryption and validation. Regular rotation shrinks the value of any single key theft, because a stolen key expires on a schedule instead of living forever.

Second, keep AMSI on and keep the farm off the open internet. The pattern across the 2025 and 2026 SharePoint incidents is the same: an internet-reachable on-premises farm, a deserialization flaw, a web shell, and key theft. Removing any one link breaks the chain. The related pattern of Kerberos RC4 hard enforcement remediation from July 2026 is a useful companion here, because both are Microsoft identity-and-trust hardening steps that teams tend to defer until an incident forces the issue. As AI lowers the cost of finding and weaponising flaws like these, the window between disclosure and mass exploitation keeps shrinking, a trend we cover in enterprise defence against AI-assisted cyberattacks.

India-specific considerations

For Indian enterprises and the Global Capability Centres that run shared services on SharePoint, the exposure is regulatory as well as operational. Under the Digital Personal Data Protection Act, 2023, the Data Protection Board of India can impose penalties of up to ₹250 crore per instance for a failure to take reasonable security safeguards that leads to a personal data breach, plus up to ₹200 crore for failing to notify the Board and affected users. Those ceilings are fixed rupee amounts set in the Schedule to the Act and are assessed per instance, so a single SharePoint intrusion that exposes personal data across several obligations can compound quickly.

The DPDP Board weighs mitigating factors such as prompt remediation and a documented compliance record, which means the runbook above has direct financial value: rotating keys, hunting persistence, and keeping evidence of the response can reduce penalty exposure. With full DPDP compliance obligations landing on May 13, 2027, teams should fold SharePoint incident response into their broader programme now. Our DPDP engineering playbook for Indian startups covers the breach-notification and safeguard duties in more depth. Whether your data is in India or abroad, the security steps are identical; only the reporting duties differ.

FAQ

How eCorpIT can help

eCorpIT is a Gurugram-based technology organisation, founded in 2021 and certified for CMMI Level 5, MSME, and ISO 27001:2022, with senior-led engineering teams and a Microsoft partnership. We help enterprises run SharePoint incident response the right way: hunt for compromise, apply the correct updates, rotate machine keys, and validate eviction with telemetry, while keeping the evidence trail that matters under the DPDP Act. We design remediation and monitoring aligned with ISO 27001 and DPDP requirements rather than treating a patch as the finish line. If you run on-premises SharePoint and want a second set of hands on this, contact our team.

References

1. CISA — CISA urges SharePoint hardening after new exploitations (July 14, 2026)

1. Microsoft Security Update Guide — CVE-2026-50522

1. Rapid7 — CVE-2026-58644 SharePoint RCE exploited in the wild

1. The Hacker News — Critical SharePoint RCE CVE-2026-50522 under active exploitation

1. The Hacker News — CISA adds exploited SharePoint RCE zero-day CVE-2026-58644 to KEV

1. SecurityWeek — Fourth SharePoint vulnerability exploited in past month's wave of attacks

1. Help Net Security — SharePoint CVE-2026-50522 exploited: patch, then rotate machine keys

1. ThreatLocker — How to hunt and contain the latest SharePoint exploits

1. Stefan Gossner — Understanding machine key rotation using the automatic SharePoint timer job

1. Bitsight — ToolShell threat brief: SharePoint RCE CVE-2025-53770 and CVE-2025-53771

1. IBM — 2025 Cost of a Data Breach report

1. BleepingComputer — CISA warns admins to patch actively exploited SharePoint flaws

1. Tenable — CVE-2026-50522

1. King Stubb & Kasiva — Penalties and adjudication under India's DPDP Act 2023

_Last updated: August 2, 2026._