CyberSpec
Join the waitlist

Patching SharePoint does not evict the intruder

The 2026 on-prem SharePoint exploit chain steals IIS machine keys. Patch, hunt, then rotate — in that order, or the attacker keeps their access.

CyberSpec

2 min read

Two paths to the same server — the patch stops the exploit path, while a second path opened by a stolen signing key runs straight past it and is closed only by a later key rotation

On 14 July 2026, CISA urged emergency hardening of on-premises SharePoint Server after a run of active exploitation covering CVE-2026-32201, CVE-2026-45659, CVE-2026-56164, CVE-2026-58644 and CVE-2026-50522. Every supported on-prem version is in scope: Subscription Edition, 2019 and 2016. What makes this campaign worth a dedicated writeup is not the initial remote code execution — it is what attackers do in the sixty seconds afterwards, and why a fully patched server can still belong to someone else.

Description of the vulnerability

The chain gets an attacker to unauthenticated code execution on an internet-facing SharePoint server. That much is a normal, if serious, RCE story. The post-exploitation step is the interesting part.

Once running code on the box, attackers harvest the IIS / ASP.NET machine keys — the validationKey and decryptionKey that the server uses to sign and encrypt __VIEWSTATE and other application state. Those keys are the server's trust anchor for data it hands to clients and expects back unaltered.

With the keys in hand, an attacker can forge a __VIEWSTATE payload the server will accept as genuine and deserialise, giving code execution on demand, authenticated as the application itself. That capability does not depend on the original vulnerability. Patch the RCE and the forged-key path still works — the intrusion has been promoted from a bug you can fix to a credential you have to revoke. Operators have used it to drop webshells (the spinstall*.aspx family is the well-documented example) and deploy malware for long-term access.

Resolution steps

Order matters here more than in a routine patch cycle. Rotating keys before you have removed the attacker's key-harvesting foothold just hands them the new keys.

  1. Apply the July 2026 SharePoint updates to every on-prem instance, Subscription Edition, 2019 and 2016 alike.
  2. Hunt before rotating. Look for spinstall*.aspx-class webshells and other unexpected .aspx files in the layouts directories, unsigned or anomalous __VIEWSTATE payloads in IIS logs, unexpected w3wp.exe child processes, and scheduled tasks or services created around the intrusion window.
  3. Remove every artefact you find — webshell, dropped binary, persistence entry — and only then continue.
  4. Rotate the ASP.NET machine keys on each affected server, then restart IIS so the running worker processes pick up the new material. Farm members share keys: rotate across the farm, not one node.
  5. Audit AD FS DKM ACLs if the environment federates through AD FS. The same campaign has reached for that token-signing material, and a stolen signing key outlives every SharePoint patch you apply.
  6. Reduce the exposure. On-prem SharePoint published directly to the internet is the precondition for all of the above. Put it behind an identity proxy or VPN, or move it, if the business case allows.

Conclusion

The lesson generalises well past SharePoint: for any application whose compromise leaks signing or encryption keys, patching closes the door but does not change the locks. Your remediation checklist for this class of bug needs three steps, not one — patch, hunt, rotate — and the hunt has to sit in the middle or the rotation is wasted work.

It also assumes you know that the server exists and is reachable from outside. CyberSpec's continuous scanning inventories what is actually exposed on your perimeter and maps each finding to the SOC 2 and ISO 27001 controls it affects, so "we didn't know it was public" stops being a plausible post-incident line.

Related