Microsoft Patched This SharePoint Bug in May. CISA Gave Agencies 3 Days to Fix It in July. Here’s the Gap That Matters.

By Dmitriy

On July 1, 2026, CISA added a Microsoft SharePoint Server vulnerability to its Known Exploited Vulnerabilities catalog and told federal agencies to fix it by July 4 — a three-day window, about as urgent as the agency’s directive gets. The vulnerability itself, tracked as CVE-2026-45659, wasn’t new. Microsoft had already shipped a fix for it in an out-of-band security update back in late May.

That two-month gap between “patch exists” and “attackers are actively using this against unpatched systems” is the actual story here. The vulnerability is a detail. The gap is the pattern that keeps recurring across nearly every KEV entry, and it’s worth understanding why it keeps happening even at organizations that, on paper, have a patch management process.

What the Bug Actually Does

CVE-2026-45659 is a deserialization-of-untrusted-data flaw in SharePoint Server, carrying a CVSS score of 8.8. Microsoft’s own advisory describes the exploitation path: an attacker who’s already authenticated to SharePoint — needing nothing more than baseline Site Member permissions, not an administrator account — can trigger remote code execution over the network, with no user interaction required on the victim’s end. That’s a meaningfully low bar. It doesn’t require phishing someone into clicking a link or tricking an admin into running a malicious file; a low-privilege account that’s already inside the system is enough to escalate to full code execution.

CISA confirmed active exploitation when it added the CVE to the KEV catalog but hasn’t published details of the observed attacks — standard practice, since disclosing exploitation specifics can hand attackers a roadmap while investigations are ongoing.

Why “Patched in May, Exploited in July” Is the Normal Case, Not the Exception

It’s tempting to read a KEV addition as “a new threat just emerged.” Far more often, what actually happened is that a patch has existed for weeks or months, and the newsworthy event is attackers finally getting around to weaponizing it against the population of systems that never applied it. SharePoint Server, in particular, tends to run in enterprise environments where patching means real downtime, change-management approval, and testing against custom configurations and third-party integrations — the opposite of a one-click cloud update. An out-of-band patch shipped in May doesn’t mean every SharePoint instance running it was patched by June; it means the fix was available starting in May, and adoption from there follows whatever cadence each organization’s IT operations can sustain.

Attackers know this. A patched vulnerability with public technical details (even indirect ones, inferred from diffing the patch itself) becomes more, not less, useful to attack over time, because the pool of unpatched-but-known-vulnerable targets is easier to find than an actual zero-day. The three-day remediation window CISA set isn’t really a response to a new threat; it’s a response to the fact that a two-month-old patch clearly hadn’t reached saturation, and active exploitation was the signal that forced the issue.

The Bigger Shift: CISA Is Now Triaging by Risk, Not Treating Every KEV Entry the Same

The three-day deadline itself reflects a change in how CISA structures urgency. Under Binding Operational Directive 26-04, which replaced the older blanket-deadline approach, agencies now face remediation timelines calibrated to actual risk factors rather than a single fixed window for every KEV entry. A vulnerability that checks every box — it gives an attacker total control of a publicly exposed system, it can be exploited automatically without human effort, and it’s confirmed in the KEV catalog — gets the shortest possible deadline: three days, plus a requirement that agencies perform forensic triage to determine whether they were already compromised before the patch went in. Lower-risk KEV entries get correspondingly longer windows. CVE-2026-45659 landed in the three-day tier because SharePoint’s exploitation path checks all three boxes: broad exposure, low attacker effort, confirmed active use.

The directive also sets a longer horizon: agencies have until December 7, 2026 to fully adopt this risk-based remediation posture across their environments, rather than treating BOD 26-04 as a one-time emergency response mechanism.

What This Actually Means for Anyone Running SharePoint

The practical takeaway isn’t “watch out for SharePoint” in the abstract — it’s that the population of organizations still running an unpatched instance of a bug fixed two months ago is apparently large enough that attackers found it worth exploiting at scale, and large enough that CISA felt the need for an emergency directive rather than routine advisory language. If a company’s patch cadence for enterprise collaboration software runs on a quarterly or “when we get to it” schedule, this is the kind of vulnerability that turns that gap into an active incident rather than a theoretical risk. The fix has existed since May. The only variable that changed between May and July was whether it got installed.