The EPSS score for this SharePoint deserialization flaw is dangerously misleading—and the danger isn't the number itself, it's what it does to your patching decisions.
You have a CVSS 9.8 RCE confirmed on CISA KEV, meaning it's actively exploited. Yet EPSS shows roughly 6% probability of exploitation in the next 30 days. That gap exists because EPSS models mass scanning signatures and threat telemetry—but deserialization vulnerabilities are exploited through surgical payloads that don't generate the scanning noise EPSS uses as input. The low score reflects absence of automated scanning, not absence of targeted exploitation.
For SharePoint, this distinction matters more than most platforms. SharePoint isn't just a web application—it's your identity broker, document repository, and workflow engine. Compromising it gives attackers lateral movement into HR systems, finance pipelines, and M&A data rooms that trust SharePoint's authentication. A single targeted attacker with the right payload has a wider effective blast radius than mass-scanning worms.
The operational reality compounds this: SharePoint patch cycles routinely require 6+ hours of downtime and break custom workflows. The moderate EPSS score becomes linguistic cover for deferral decisions already driven by operational friction. But EPSS is modeling mass-exploitation probability—it cannot measure targeted internal network exploitation, which is exactly the threat vector your SharePoint farm faces if an attacker gains any internal foothold.
If your SharePoint is internally accessible or serves as an authentication pivot for other systems, treat the 9.8 severity as your decision anchor. The 6% EPSS is a historical snapshot of mass-scanning activity, not a measure of your actual exposure. Prioritize based on your architecture's connectivity, not the probability model's blind spots.