SharePoint RCE lands on CISA's must-patch list – the bulletin came weeks after the fix

Microsoft shipped the fix for CVE-2026-45659 in May's cumulative update, but didn't publish the security bulletin until May 21: weeks after the patch was already live. CISA has since confirmed active exploitation and added the flaw to its Known Exploited Vulnerabilities (KEV) catalog, giving federal agencies until July 4 to patch.

The vulnerability carries a CVSS score of 8.8 and allows remote code execution via unsafe deserialization of untrusted data: the kind of bug that, on an internet-facing SharePoint server, can go from "interesting finding" to "full compromise" in one request.

The timeline, reconstructed

Put in order, the sequence looks like this:

• Early May 2026: Microsoft ships the fix silently, bundled inside the regular monthly cumulative update for SharePoint Server.
• May 21: the security bulletin for CVE-2026-45659 is published, weeks after the patch was already downloadable.
• Late June: CISA confirms active exploitation in the wild and adds the flaw to the Known Exploited Vulnerabilities catalog.
• July 4: the remediation deadline for US federal civilian agencies.

A KEV listing is worth translating for anyone outside the US federal orbit. Under Binding Operational Directive 22-01, civilian agencies are legally required to remediate KEV entries by the stated deadline, but the catalog's real influence is broader. It has become the de facto industry shortlist of vulnerabilities actually being used against real targets right now, and many private-sector patching programs key their own priorities off it even though nothing obliges them to.

The bug class matters too. Unsafe deserialization means the server takes attacker-supplied data and reconstructs it into live objects without properly validating it first, which in practice often hands the attacker code execution with the service's own privileges. It is a bug class with a long history in SharePoint and other .NET applications, and one that exploit developers are extremely comfortable weaponizing quickly once a patch shows them where to look.

Why the disclosure gap matters

The lag between "patch available" and "bulletin published" is the part worth paying attention to. Most patch-management programs are built around vendor bulletins as the trigger for prioritization – if the bulletin isn't out yet, the cumulative update it's bundled in often gets treated as routine, non-urgent maintenance. That's exactly the gap attackers who reverse-engineer patches are built to exploit.

Are you affected

• Running SharePoint Server on-premises (this is not an issue for SharePoint Online / Microsoft 365).
• Applied Patch Tuesday updates on your normal cadence, without specifically confirming the May cumulative update landed.
• Expose SharePoint, directly or through a reverse proxy, to users outside a tightly controlled network.

What to do now

Don't assume routine patch cadence already covers this one. Confirm explicitly that your SharePoint Server farm is on the May cumulative update, not just "up to date" per your patch dashboard. If you can't confirm patched status quickly, treat internet-facing SharePoint as exposed and consider restricting access at the network layer until you can.

Frequently asked questions