Novaprospect

Two weeks ago we wrote about CVE-2026-45659 — a deserialization RCE in on-premises SharePoint Server that Microsoft had rated "Exploitation Less Likely" right up until CISA added it to the KEV catalog. The lesson there was about the gap between a probability field and a due date.

On July 14, CISA added CVE-2026-56164 — SharePoint again — with a federal remediation deadline of July 17, which, if you're reading this the day it went up, is today. That's two actively-exploited on-prem SharePoint bugs in fifteen days. But this one isn't a repeat. It broke a different thing, and it broke it in a way that removes the one guardrail the last one still had.

The mechanism, and the guardrail it drops

CVE-2026-56164 is a missing-authentication-for-critical-function flaw — CWE-306. SharePoint exposes functionality that should sit behind an authentication check, and on the affected builds it doesn't. An attacker who can reach the server over the network invokes that function directly and elevates privileges, with no credentials required.

Hold that next to the July 2 bug. CVE-2026-45659 was a deserialization RCE that needed the attacker to authenticate first — only at Site Member, a low fence, but a fence. We spent a paragraph there arguing that "authenticated" narrows the attacker population much less than it sounds like on a collaboration platform where everyone's a member.

This one doesn't even ask. PR:N — no privileges required. The distinction that made the last post's fence worth arguing about is simply gone. Anything that can complete a TCP handshake to the SharePoint front end is in scope. That single change is why a farm you'd mentally filed as "internal, low-risk, behind the VPN" deserves a fresh look: the bug's exposure is now exactly equal to the farm's network reachability, and nothing else.

When the graders disagree

Here's the wrinkle that makes this a scoping problem and not just a patching one. The two authoritative severity scores don't agree, and they don't disagree by a little:

NVD (NIST): 9.8, Critical.
Microsoft (the CNA): 5.3, Medium.

That's not a rounding difference. It's the gap between drop everything and next maintenance window, assigned to the same CVE by two organizations both acting in good faith. The spread almost always comes down to assumptions baked into the vector — how reachable the vulnerable function actually is in a default configuration, whether a precondition the vendor considers uncommon is treated as the base case. Microsoft is scoring the shape of the bug as it ships; NIST is scoring the worst defensible reading of where it can be reached.

We made a version of this point about the "Exploitation Less Likely" rating two weeks ago: any field that estimates the future is a forecast, not a deadline. The CVSS disagreement is the same trap from a different angle. A CVSS-sorted patch queue that trusts the vendor's 5.3 files this below the week's 8s and 9s and moves on. A queue that trusts NVD's 9.8 puts it at the top. Both queues are wrong to let the number decide, because the KEV catalog already answered the only question that sets the clock — it's being exploited in the wild — and that fact doesn't care which grader you believe. When the base scores split this far, that's the cue to stop litigating the number and go answer the exposure question about your estimate directly.

Is it even inside your boundary?

Which is the whole post, really. Before the CVSS argument, before the patch, the first deliverable is a fast, defensible yes-or-no: does on-prem SharePoint Server exist inside your authorization boundary, at what build, reachable from where?

SharePoint Online is Microsoft's problem, inside Microsoft's authorization — not yours to patch. But this CVE is specifically on-premises SharePoint Server, and on-prem farms are exactly the assets that go undrawn on the boundary diagram:

The farm nobody migrated. The legacy intranet, the records system with a compliance reason to stay on-prem, the acquired company's file server nobody has rationalized yet. As with PAN-OS, the asset most likely to be in scope is the one least likely to be written down.
"Internal-only" was doing the risk work. If the mitigating control in your head was it requires a login or it's behind the VPN, this bug erodes the first outright and demands you actually verify the second. Unauthenticated + network-reachable is a much shorter path than the story you may have been telling yourself.
Which build are you on? The fixes land at specific builds — 16.0.5561.1001 for Server 2016, 16.0.10417.20175 for 2019, 16.0.19725.20434 for the Subscription Edition (verify against Microsoft's advisory for your exact SKU). An out-of-cycle SharePoint update is precisely the kind of thing a strictly Patch-Tuesday-shaped motion lets slip.

If your answer to "is it ours?" is not sure, that uncertainty is the finding — and it's a more expensive one on a today deadline than the patch would have been.

The clock already moved

The KEV-clock mechanics are the ones we've walked through before: a catalog listing inherits its federal due date as your remediation deadline, overriding the routine 30/90/180-day ConMon windows. Here that date is July 17 — a three-day band from a July 14 listing, and for most readers it has already arrived or passed.

A deadline that's already here changes the task. You're not scheduling remediation; you're producing evidence of where you stand:

The boundary determination, if your answer is "not ours" — written down, dated, defensible. A clean this asset is outside the boundary is a complete answer to a KEV item, but only if it's an artifact, not a memory.
The build numbers before and after, and the scan delta that shows the fix landed.
If you can't meet the date, the POA&M entry that says so, with the interim mitigation (CISA's required action explicitly contemplates restricting exposure, or discontinuing the product, where a fix isn't available yet).

And under BOD 26-04, the triage question was never "what's the CVSS?" — which is convenient, because this week the CVSS can't make up its mind. It's "is it exposed, is it automatable, does it grant control, is it being exploited?" This one answers exploited outright, automatable plainly — an unauthenticated network request is about as scriptable as it gets — and grants control by definition, since privilege elevation is the payload. Three yeses, no number required.

What we keep coming back to

Every KEV post lands on the same unglamorous machinery: the inventory that answers in seconds instead of a scramble, the CVE feed wired to the asset list, the evidence that collects itself. This SharePoint pair sharpens the point from two sides. The July 2 bug said your exploitability forecast is not your deadline. This one says your severity score can be actively disputed and it still doesn't matter — because the field that sets the clock is the catalog entry, and the question that decides whether the clock is survivable is one only your inventory can answer: which of your farms does this touch, and is that farm inside the boundary or outside it?

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 the gap between "CISA says it's exploited" and "we know exactly which farms it reaches, at what build, inside or outside the boundary" is measured in minutes. When the deadline is today and the graders can't agree, the only thing that saves you is having drawn the map before you needed it. Which farms are on your diagram — and which ones are you about to go find out about?

Reference

Known Exploited Vulnerabilities Catalog — CISA
CVE-2026-56164 — NVD
BOD 26-04, Prioritizing Security Updates Based on Risk — how the KEV clock and the four risk questions fit together
"Exploitation Less Likely": the July 2 SharePoint KEV item — the authenticated deserialization RCE this one echoes

No Login Required: CVE-2026-56164 and Whether That SharePoint Farm Is Even Inside Your Boundary