CISA Flags SharePoint Deserialization Bug CVE-2026-45659 as Actively Exploited

CISA added a high-severity Microsoft SharePoint Server vulnerability to its Known Exploited Vulnerabilities catalog on Wednesday, citing evidence of in-the-wild abuse.

The bug is tracked as CVE-2026-45659 and carries a CVSS score of 8.8. Root cause: deserialization of untrusted data leading to remote code execution. An authenticated attacker with the right privileges can trigger the flaw over the network.

SharePoint on-prem has been a magnet for state-aligned and financially motivated crews for years. The ToolShell cluster of bugs earlier this cycle drew exploitation from actors overlapping with China-nexus activity that Microsoft tracks as Linen Typhoon and Violet Typhoon, alongside Storm-2603. Whether CVE-2026-45659 sits in that same operational orbit is not yet public, and single-source attribution here would be premature.

What we know is narrower than what most readers will want.

CISA's KEV listing is, by design, a signal of confirmed exploitation rather than a technical writeup. The agency does not typically name victims, sectors, or operators when it adds an entry. No vendor has publicly tied CVE-2026-45659 to a named intrusion set at the time of writing. Treat any early attribution as low confidence until a CTI vendor publishes telemetry.

Federal civilian agencies have three weeks from the KEV listing date to remediate under BOD 22-01. Private-sector defenders should treat that as a floor, not a target.

Deserialization flaws in SharePoint tend to chain well. Historically, operators have paired them with ViewState abuse, IIS module drops, and web shell staging under _layouts or _vti_bin. The ToolShell activity earlier this year leaned on stolen MachineKey material to forge __VIEWSTATE payloads and maintain access even after patching. Defenders who patched but did not rotate keys learned that lesson the hard way.

Recommended actions for anyone running SharePoint on-prem:

• Apply the relevant Microsoft security update immediately and verify the build number on every farm node, not just the WFE you happened to RDP into.
• Rotate SharePoint MachineKeys after patching, then restart IIS. Assume prior compromise if the server was internet-facing.
• Hunt for anomalous w3wp.exe child processes, unexpected .aspx files under SharePoint layout directories, and outbound connections from SharePoint service accounts to non-Microsoft infrastructure.
• Constrain SharePoint egress at the network layer. There is rarely a legitimate reason for a content server to initiate arbitrary outbound HTTPS.

SharePoint Online is not affected by on-prem deserialization paths, though tenants federated with compromised on-prem farms inherit risk through hybrid identity.

Expect a vendor writeup in the coming days. Until then, patch, rotate, and hunt.