SharePoint deserialization: why patching does not end the incident

Five of the ten SharePoint entries in the estate's KEV matches are the same bug class: deserialization of untrusted data. The mechanism that keeps biting is not the parser bug itself, it is what the attacker steals on the way through, because a stolen ASP.NET machine key keeps working long after the update lands. If you still run on-premises SharePoint because the migration keeps slipping, the patch is step one of five, not the end of the job.

What happened

The 2026 run of SharePoint exploitation is not one incident, it is a cadence. CVE-2026-20963, a critical deserialization flaw allowing unauthenticated remote code execution with no user interaction, was fixed in January's Patch Tuesday and added to CISA's KEV catalogue on 18 March 2026 with a three-day federal patching deadline, at a point when Microsoft had still not updated its advisory to indicate active exploitation (src: The Register). CVE-2026-32201 followed into KEV on 14 April, CVE-2026-45659 on 1 July, then July's Patch Tuesday brought CVE-2026-56164 into KEV the same day it shipped, CVE-2026-58644 on 16 July and CVE-2026-50522 on 22 July (src: CISA).

Two of those deserve a closer look. CVE-2026-58644 shipped on 14 July without an exploitation designation; Microsoft flagged it as exploited the following day, meaning it had been weaponised as a zero-day before fixes were available (src: Rapid7). For CVE-2026-50522, proof-of-concept code was published by researcher Janggggg (src: SC Media), and watchTowr's global honeypot network recorded successful exploitation attempts within hours of that release, on 20 July (src: Help Net Security).

One correction to the metadata that seeded this piece: it recorded no public exploit. That is wrong. Public PoC code exists and honeypots caught it working. Treat any affected on-premises host as facing a working, commodity exploit.

The precedent everyone should be reasoning from is ToolShell in July 2025, where CVE-2025-53770 (CVSS 9.8) and CVE-2025-53771 bypassed the fixes for CVE-2025-49704 and CVE-2025-49706. Check Point counted more than 4,600 compromise attempts against over 300 organisations (src: The Hacker News), and Microsoft attributed activity to Storm-2603 alongside Chinese state actors Linen Typhoon and Violet Typhoon, with Warlock ransomware deployed (src: Computer Weekly).

How it works

Step one is ordinary and boring: untrusted input reaches a deserialiser. CVE-2026-58644 is a CWE-502 deserialization of untrusted data issue with a CVSS v3.1 score of 9.8 (src: Rapid7). For CVE-2026-50522, the attacker sends a crafted serialized object to a vulnerable endpoint; Defused captured a .NET deserialization payload delivered to a SharePoint sign-in endpoint, and noted the requests carried no authentication material at all (src: The Hacker News).

Step two is the part that survives your patch. ASP.NET protects __VIEWSTATE with a MAC derived from the machineKey validation and decryption keys. In 2025, the spinstall0.aspx web shell was used to read the SharePoint instance's machineKey configuration including the validationKey; with those secrets in hand the actors could generate valid, signed __VIEWSTATE payloads, forge authentication tokens, impersonate users and reach unauthenticated RCE without ever touching the original exploit path again (src: Truesec).

The 2026 cluster repeats it. Resecurity documents exfiltration of the machineKey section from the SharePoint root web.config on both web front ends; because a farm uses identical validation and decryption keys across nodes for ViewState compatibility, forged payloads can be signed and encrypted offline with ysoserial.net, turning a low-privilege foothold into arbitrary code execution under the application pool account on any front end (src: Resecurity). watchTowr's summary is the whole post in two clauses: attackers are pulling SharePoint machine keys with a single request, and patching is not enough, so rotate credentials on anything that may have been exposed (src: The Hacker News).

Step three is persistence designed to outlive your maintenance window. Resecurity describes a custom ASP.NET HTTP handler compiled as a DLL, dropped into the Global Assembly Cache and registered in web.config under httpHandlers, responding only to a specific User-Agent substring. That gives interactive access with no need for a fresh deserialization trigger, survives application pool recycling, and dodges naive file-based hunting (src: Resecurity).

Step four is why this is a domain problem, not a portal problem. SharePoint web front ends routinely hold routes into Active Directory, SQL Server, service accounts, content databases and internal applications (src: Cyber Press). CISA frames these weaknesses as chainable to unauthorised access, RCE, persistent access and lateral movement (src: CISA).

Why it matters

This is on-premises only. The affected products are SharePoint Server Subscription Edition, 2019 and 2016, including Subscription Edition despite its continuous update model (src: Censys). If you are on SharePoint Online, Microsoft patches it and this is not your incident.

The exposed population is smaller than headlines suggest. Censys found that almost all internet-facing SharePoint is SharePoint Online, and counting hosts rather than web properties, roughly 1,500 run self-managed on-premises editions, mostly 2019 (src: Censys). You will see a figure of over 10,000 exposed servers in secondary reporting (src: Help Net Security); that almost certainly includes SharePoint Online, but the reconciliation is inference on my part, so prefer the Censys number. Small population, high value, repeat targeting.

The scoring hazard is worth calling out separately. CVE-2026-56164 is a missing-authentication flaw (CWE-306) needing no credentials and no user interaction, yet Microsoft assigned CVSS 5.3 "Moderate" while NVD independently scored it 9.8 Critical (src: Tech Times). In an automated queue sorted by vendor severity, an actively exploited bug sits behind dozens of items that are not being exploited (src: Windows Forum).

On track record: since November 2021 CISA has flagged 11 exploited SharePoint vulnerabilities, 7 of which were also used in ransomware (src: BleepingComputer). The estate's KEV data marks 2025's ToolShell entries as ransomware-linked and every 2026 SharePoint entry as not. Read that as an absence of public evidence, not safety. The 2025 precedent shows how fast that gap closes.

Two things remain genuinely unresolved and I am not going to pretend otherwise. First, authentication for CVE-2026-58644: Microsoft's advisory language requires an attacker authenticated as at least a Site Owner (src: The Hacker News), Tenable says the same (src: Tenable), yet Rapid7 describes it as unauthenticated RCE (src: Rapid7) and Defused's captured traffic contained no authentication material (src: Help Net Security). Treat it as unauthenticated-reachable until Microsoft reconciles its own advisory. Second, patch provenance: VulnCheck says CVE-2026-58644 was patched in June but inadvertently left off the June cycle (src: Cybersecurity Dive), while Rapid7 dates the advisory to 14 July. Also no named actor and no named victims for the 2026 cluster in anything I read (src: Truesec).

What to do about it

The seed conversation for this post had the checklist in the wrong order, and the ordering is the operationally important bit. CISA's sequence is: apply the patches and verify they installed; verify AMSI integration is enabled for each SharePoint web application; scan for and remove intrusion artifacts, including machine key harvesting tools, before rotating IIS machine keys, so the new keys are not stolen too; establish tailored logging; and stop exposing SharePoint directly to the internet unless you must (src: The Hacker News). Field Effect makes the same point, that rotation should follow completion of threat hunting, and adds full request-body scanning where possible (src: Field Effect). Rotating first is theatre.

Concretely, in order:

Answer the asset question first. Nothing in the estate's data tells me we run on-premises SharePoint. The checklist is meaningless until someone confirms whether an affected host exists.
Apply the full 14 July release across every SharePoint server and verify it completed. Rapid7 states customers who applied all 14 July updates are protected against both in-the-wild vulnerabilities, and that this should be treated as emergency remediation (src: Rapid7). Resecurity's position is to patch all six July issues regardless of observed exploitation (src: Resecurity).
Enable AMSI on every web application, not just the obvious one, and use Defender and AMSI detections to look for exploitation attempts (src: CISA).
Hunt before you rotate. Review authentication records, web server logs, SharePoint audit events, admin account changes, suspicious process execution, unexpected scheduled tasks, unusual outbound connections, newly created privileged users, permission changes and web shells (src: Cybersecurity News). For the known pattern: unauthorised .aspx files in the layouts directories (/15/ or /16/), spinstall0.aspx and anything similarly named, w3wp.exe spawning cmd.exe and PowerShell, and log hits on ToolPane.aspx (src: Truesec). Add GAC-registered handlers and httpHandlers entries in web.config to the list (src: Resecurity).
Then rotate machine keys. Microsoft's procedure: Set-SPMachineKey -WebApplication to generate, Update-SPMachineKey -WebApplication to deploy across the farm, then iisreset.exe on every SharePoint server; alternatively run the Machine Key Rotation Job from Central Administration under Monitoring, Review job definitions, followed by iisreset (src: MSRC). The iisreset is not housekeeping, it flushes attacker-loaded web shells and memory-resident payloads (src: Logpoint).
Cut the exposure. Block external access to Central Administration, restrict farm and database communications to required systems, and work through Microsoft's role-specific hardening guidance (src: CISA).

One last thing about our own process. The estate's exploit feed logged the CVE-2026-50522 KEV addition on 23 July and a securitylab.ru item the day before making exactly this argument, that one patch is not enough. The four briefs that followed on 29 July led on Cisco FMC, Rails, VMware, Gitea, Check Point and an unrelated AI incident, with no SharePoint item at all. We watched the KEV entries land and then moved on while exploitation was still developing. That is the failure mode this post is about, and it applies to feeds as much as to servers.

Sources