📢 New post: The Doors Open Today: 20x Marketplace Listings, and Three Weeks to Say Goodbye to FedRAMP Ready · 📝 Also fresh: "Exploitation Less Likely": CVE-2026-45659 and the Advisory Field That Isn't a Promise · 🚦 Beacon — the FedRAMP 20x KSI emitter — design partners open ✨ · 🆕 20x Hub: program reference, kept current · 🧪 Free tool: KSI Quick Check — paste, run, get the verdict
← Blog
FedRAMPConMonCISAVulnerability Management

"Exploitation Less Likely": CVE-2026-45659 and the Advisory Field That Isn't a Promise

When we wrote about BOD 26-04 and FedRAMP's NTC-0014 a week ago, the rule we kept circling was Assume It's Automatable — FedRAMP's instruction to treat every exploit as weaponizable by default, unless you can produce evidence otherwise. We called it "refusing to bet against a trend that has been remarkably consistent."

This week the trend delivered a tidy exhibit.

On July 1, CISA added CVE-2026-45659 to the Known Exploited Vulnerabilities catalog, with a federal remediation deadline of July 4 — the three-day band. It's a deserialization-of-untrusted-data flaw in on-premises Microsoft SharePoint Server (Subscription Edition, 2019, and Enterprise Server 2016), CVSS 8.8, allowing an authenticated attacker to execute arbitrary code on the server.

Here's the part worth slowing down on. Microsoft patched this bug in late May, via an out-of-band update — and the accompanying advisory assessed it as "Exploitation Less Likely." Five weeks later it's on the KEV catalog, which has exactly one admission criterion: reliable evidence of exploitation in the wild.

The mechanism, briefly

Deserialization bugs in SharePoint have a familiar shape, and this one follows it. An attacker with access to the server sends a crafted serialized payload; SharePoint reconstructs it without adequately validating what it's rebuilding, and attacker-controlled code executes inside the SharePoint worker process, under the application pool's service identity.

The notable wrinkle is the privilege bar: exploitation requires authentication, but only at the level of Site Member — no elevated or administrative rights. On a collaboration platform, Site Member is not a high fence. It's the permission level of roughly everyone: every employee with a team site, every over-provisioned contractor account, every guest invitation nobody cleaned up, and — the case that matters for this CVE — every one of those accounts an attacker has already phished. "Authenticated" narrows the attacker population much less than it sounds like it should when the platform's entire purpose is broad internal access.

And if the summer of 2025 is any guide — when the ToolShell exploit chain tore through on-premises SharePoint worldwide — a SharePoint RCE doesn't stay boutique for long. The population of internet-reachable, slow-to-patch SharePoint farms is large, well-mapped, and historically productive for attackers.

The field that isn't a promise

We don't bring up the "Exploitation Less Likely" rating to dunk on Microsoft. Exploitability indices are honest, well-reasoned estimates made at publication time, and most of the time they're right. That's precisely what makes them dangerous as a scheduling input: they're probabilistic weather forecasts, and patch queues quietly treat them as commitments.

Think about how this CVE traversed a typical vulnerability-management pipeline. It arrived in late May as an out-of-band patch — already an awkward fit for a monthly cycle — carrying an 8.8 that isn't a 9.8, an "authenticated attacker required" that reads like mitigation, and a vendor assessment saying exploitation is less likely. Every one of those signals whispers next sprint is fine. A CVSS-sorted queue puts it below that week's crop of 9-point-somethings. A triage process that weights the exploitability index defers it honestly and defensibly.

Five weeks later, all of that reasoning is overtaken by a single fact — someone is exploiting it — and the calendar you get is not the one you planned: three days, ending July 4, which for U.S. readers lands on a federal holiday weekend. The KEV clock has never cared about your sprint boundaries, but it has a particular sense of humor about long weekends.

This is the empirical case for the burden-shift in NTC-0014. "Assume it's automatable" sounds paranoid until you watch a less-likely bug get weaponized inside its own patch cycle. The default posture — treat it as weaponizable, earn the right to relax — would have had this patched in June for reasons that had nothing to do with predicting the future.

The signal arrived with no story attached

One more detail worth noticing: CISA has shared nothing about the observed attacks, and there were no public reports of in-the-wild exploitation before the catalog entry appeared. No vendor writeup, no threat-intel blog with IOCs, no named campaign. The KEV listing is the disclosure.

That matters operationally. If your remediation process implicitly waits for the narrative — the technical analysis, the attribution, the detection guidance — before treating a vulnerability as urgent, this CVE never triggers it. The catalog entry is a due date wearing no explanation, and under BOD 26-04 that's all it needs to be. The story, if one ever becomes public, will arrive long after July 4.

If you're inside a FedRAMP boundary

The clock mechanics are the ones we've walked through before: a KEV listing inherits its federal due date as your remediation deadline, overriding the routine ConMon windows. The SharePoint-specific questions:

  • Is on-prem SharePoint even in your boundary? SharePoint Online is Microsoft's problem, inside Microsoft's authorization. But hybrid estates are exactly where on-prem farms linger — the legacy intranet that never migrated, the records system with a compliance reason to stay on-prem, the acquisition's file server nobody has rationalized. As with PAN-OS, the first deliverable is a fast, defensible yes-or-no.
  • Are you on the late-May build? The fix shipped out-of-band in late May. If your patching motion is strictly Patch-Tuesday-shaped, an out-of-band SharePoint update is exactly the kind of thing that falls between the rails — verify the build number, don't trust the cadence.
  • Who counts as Site Member? The privilege bar makes account hygiene part of the remediation story. A patched farm with a thousand stale authenticated accounts is fixed; a patched farm is still the only kind that's fixed. Patch first — but the access review this bug implies is worth opening as its own item.
  • What's the evidence trail? Build numbers before and after, the scan delta, the boundary determination if your answer is "not ours" — written down, dated, attached. The artifact that survives the assessment is the trail.

What we keep coming back to

Every KEV post we write ends up pointing at the same unglamorous machinery — the inventory that answers in seconds, the CVE feed wired to the asset list, the evidence that collects itself. This one adds a sharper corollary: any prioritization field that estimates the future — exploitability indices, "less likely," even a CVSS temporal score — is a forecast, and forecasts belong in the risk discussion, not in the deadline calculation. The only field that should set your clock is the one that reports the present tense. This week, for on-prem SharePoint, the present tense changed on a Tuesday.

It's the posture we're building the Novaprospect audit engine around — KEV entries landing in the same triage queue as the asset inventory they refer to, so that the gap between "CISA says it's exploited" and "we know exactly which of our farms it touches" is measured in minutes, not in a scramble that eats half of a three-day window.

Reference