SharePoint's RCE Chain Just Grew a Fourth CVE, and Machine Keys Are Walking Out the Door

I wrote about CVE-2026-45659 a couple of weeks back, filed it under "patch this, it's on KEV, move on", and honestly thought that was the end of it. Turns out it was the opening chapter. Three more CVEs later, this is a proper chain now, and the bit that actually stopped me mid-scroll wasn't the RCE, it was the machine key theft. Patch a chain like this and you can still lose, because the thing the attacker stole doesn't expire when Microsoft ships a fix.

So here's the fuller picture: what each of the four bugs actually does, how they fit together, why CISA and Microsoft disagree on how bad one of them is, and what I'd actually go and check on my own farm if I ran one.

What it is

Four vulnerabilities in on-prem SharePoint Server (2016, 2019, and Subscription Edition) that, used together, let an attacker go from zero access to running code on the box, then help themselves to the server's ASP.NET machine keys on the way out. SharePoint Online in Microsoft 365 isn't affected. This is on-prem only.

None of these four is new in the sense of "just discovered". CVE-2026-32201 was patched back in April, CVE-2026-45659 in May. What changed is that CISA now has evidence someone is stringing them together, and the two newest bugs, CVE-2026-56164 and CVE-2026-58644, only surfaced in the last two weeks alongside confirmation the whole chain is being actively exploited.

How we got here

Worth laying out, because "patch your SharePoint" undersells how this actually unfolded. It's not one disclosure, it's four bugs landing over three months that only became a story once someone worked out they fit together.

Why it matters

• Individually survivable, together not. "Needs Site Member" and "just a spoofing bug" both sound like second-tier findings on their own. Chained, they add up to an unauthenticated attacker running code on your server.
• On-prem is still everywhere. Government agencies, universities, and plenty of enterprises that never fully moved to SharePoint Online still run these farms, often internet-facing for extranet or partner access.
• What gets stolen doesn't expire with the patch. The machine key theft is the sting in the tail here. Patching the deserialisation bug stops new exploitation; it does nothing about keys already taken.
• CVSS disagreement is a real prioritisation problem. If your vulnerability management tooling pulls scores from the vendor feed, CVE-2026-56164 shows up as a 5.3 medium. Pulled from NVD, it's a 9.8 critical. Same bug.

Root cause

What deserialisation means, quickly, because it comes up a lot in bugs like this: when an app sends data over the network or writes it to disk, it often "serialises" it first, turning a live object in memory into a flat string or byte stream. Deserialisation is the reverse: reading that stream back and rebuilding a live object from it. The problem starts the moment the app deserialises something it didn't create itself, and hasn't properly checked. What comes back isn't just data any more. It can be an object that runs code the instant it's reconstructed.

Both RCE bugs here, CVE-2026-45659 and CVE-2026-58644, are exactly that: CWE-502, deserialisation of untrusted data, in SharePoint's own code. CVE-2026-32201 (spoofing, CWE-20 improper input validation) and CVE-2026-56164 (CWE-306, missing authentication for a critical function) are what get an attacker close enough that SharePoint trusts their request in the first place. Take the RCE bugs on their own and an attacker needs an account. Add the other two and they don't.

When NVD scores a bug 9.8 and the vendor that wrote the code scores it 5.3, that gap is exactly where "wait, why is this only medium in our dashboard" turns into an incident report.

The exploitation chain

CISA hasn't published a full technical walkthrough of this one (unlike some vendor write-ups I've covered before), so I'm keeping this at the shape CISA and Tenable have described, not a step-by-step recipe. That's also the responsible way to write this up, given it's being actively exploited right now.

Check where your own farm actually stands

This is the practical bit: three checks you can run today, on a farm you're authorised to touch, that tell you more than "am I patched" alone.

1. Get the real build number. Don't trust the "Version" shown in Central Admin's About page, it lags. From the SharePoint Management Shell:

(Get-SPFarm).BuildVersion

2. Compare against the minimum safe build. Because these four were fixed in different rounds, the number you actually need is the highest one, from the July round. It covers all four at once:

3. Hunt for the campaign's own signatures. Microsoft ships AMSI and Defender detections for this specific activity. Worth checking your Defender logs even if you've already patched, in case exploitation happened before you did:

Get-WinEvent -LogName "Microsoft-Windows-Windows Defender/Operational" |
  Where-Object { $_.Message -match "ToolPaneAuthBypass|SuspSignoutReqBody|LeakFang" }

On machine-key rotation itself, I'll be straight with you: I haven't found (or tested) the exact PowerShell Microsoft wants you to run for a clean rotation on this campaign, and I'm not going to paste a guess and let you find out the hard way. Go through Microsoft's own SharePoint machine-key guidance for the actual steps. What I can tell you with confidence is the bit people skip: rotating the key without also cleaning up whatever the attacker planted using the old one just gives you a compromised box with a new key.

Detection & hunting

• AMSI / Defender signatures. Per Tenable's analysis of the campaign: Exploit:Script/SuspSignoutReqBody.A (Subscription Edition), Exploit:Script/ToolPaneAuthBypass.A and .C (all versions), and Backdoor:MSIL/LeakFang.A!dha for post-exploitation machine-key access.
• Request signals. Unexpected POSTs to ToolPane.aspx or other _layouts endpoints from sources with no business hitting them, especially from IPs with no prior SharePoint session.
• Process telemetry. w3wp.exe spawning cmd.exe, powershell.exe, or anything unexpected is the classic tell for a web-app deserialisation RCE landing. Alert on it generally, not just for this campaign.
• Auth anomalies. Site Owner or Site Member actions from accounts that don't normally touch those permissions, particularly around the time of any of the requests above.

Remediation

• Patch to the July builds in the table above. That closes all four CVEs in one update, not just the headline one.
• Get Central Admin off the internet. CISA's specific guidance here: don't expose SharePoint Central Administration directly, and restrict who can reach it.
• Turn on AMSI integration for SharePoint and the IIS worker processes, and set Request Body Scan mode to Full. Both are in CISA's hardening guidance for this campaign.
• Rotate machine keys properly. Rotation alone isn't the fix if you haven't first found and removed whatever a prior compromise left behind. Assume compromise if you were unpatched and internet-facing at any point since April, and act accordingly before you rotate.

MITRE ATT&CK mapping

• T1190 · Exploit Public-Facing Application (the SharePoint endpoints themselves).
• T1068 · Exploitation for Privilege Escalation (CVE-2026-56164).
• T1552 · Unsecured Credentials (the IIS machine key theft).
• T1105 · Ingress Tool Transfer (malware deployment reported in post-exploitation).

References

• CISA: CISA Urges SharePoint Hardening After New Exploitations
• CISA: Known Exploited Vulnerabilities Catalog
• NVD: CVE-2026-58644
• NVD: CVE-2026-56164
• NVD: CVE-2026-45659
• NVD: CVE-2026-32201
• Tenable: SharePoint CVEs FAQ (CVE-2026-32201, -45659, -56164)
• The Hacker News: SharePoint RCE CVE-2026-45659 Added to CISA KEV
• The Register: CISA sounds alarm over trio of exploited SharePoint flaws

FAQ

Is Microsoft 365 / SharePoint Online affected by this chain?

No. All four CVEs (2026-32201, 2026-45659, 2026-56164, 2026-58644) only affect on-prem SharePoint Server: 2016, 2019 and Subscription Edition. SharePoint Online in Microsoft 365 is a different codebase and isn't listed as affected in any of the advisories.

What is CVE-2026-58644?

A CVSS 9.8 remote code execution bug in on-prem SharePoint Server caused by deserialising untrusted data. It needs at least Site Owner permissions to trigger. Microsoft confirmed active exploitation on 15 July 2026, and CISA added it to the KEV catalog the next day.

Do I need to patch all four CVEs, or just the newest one?

All four. They were fixed in different monthly rounds between April and July, and attackers are chaining them together. Patching only the July round closes all four anyway, since each product's July build number is higher than the earlier fixes for the same product.

Is this the same as last year's ToolShell attack?

Not the same CVEs, but the same shape: chain an auth bypass into a deserialisation bug on-prem SharePoint, then harvest IIS machine keys for persistence. Microsoft attributed 2025's ToolShell to Chinese state-linked groups; nobody has been publicly attributed for this round yet.

Related reading

• Exploited This Week: SharePoint, ColdFusion & Langflow (where CVE-2026-45659 first showed up on my radar)
• CVE-2026-8451: NetScaler CitrixBleed Pre-Auth Memory Overread (another pre-auth chain built on a parser that trusted too much)
• More threat briefs