The EPSS-CVSS gap is your first signal that this isn't a straightforward case. The 0.00359 EPSS places this firmly in low-exploit-probability territory — but that metric models opportunistic internet scanning, not document-based targeted attacks. This vulnerability lives in software that processes untrusted input from email attachments constantly. A malicious .docx or .pptm delivered via spear-phishing doesn't require 'local privilege escalation' in the traditional sense — the victim opening the file IS the initial access vector. The 'local code execution' framing in the description obscures this: macro-based execution from a weaponized document is how most real campaigns achieve initial access, regardless of what the CVE says.
The second signal is the vulnerability class itself. Out-of-bounds reads in Office parsers have a documented genetic signature going back to CVE-2008-4841 and its contemporaries: they function as information-disclosure primitives that enable ASLR bypass, which then enables RCE. This isn't a standalone exploit — it's a force multiplier in a chain. An attacker who lands a malicious document doesn't need this to achieve remote code execution directly; they need it to reliably defeat DEP/ASLR for their actual payload. That's why sophisticated actors value this class of bug even when EPSS says it's unlikely to be scanned.
The third signal is where the bug actually lives. Out-of-bounds reads in Office disproportionately inhabit legacy code paths — RTF parsers, old Excel binary format handlers, deprecated OLE object processors. These are code branches that haven't had a security review in years, kept alive purely for backward compatibility. The 'nobody uses .xls anymore' assumption is wrong: the parser still processes legacy format branches every time it opens a binary Office file, and attackers know this. When an OOB read gets patched in the current branch, exploit developers diff the binary, check whether the legacy path received the same fix, and frequently find it didn't.
For defenders, this means three things. First, treat document-based code execution as initial access — don't triage it as a secondary privilege-escalation step. Second, your patch window isn't measured from Microsoft's release date; it's measured from when your organization actually deploys Office updates, which in many enterprises runs months behind. Third, audit your document-processing supply chain: email gateways, cloud preview services, document management systems, and any Python or third-party libraries that parse Office formats. They may all share the same vulnerable code paths with different patch cadences.
The patch itself will tell you whether this is surgical or symptomatic. If it's a single bounds check at one call site, treat it as a one-year fix and start planning the architectural review of your legacy parser branches. If the patch restructures how the parser handles untrusted input, that's a stronger signal that Microsoft is addressing the root cause rather than just the symptom.