The 'local attacker' qualifier in this CVE creates a dangerous framing problem. Read literally, it suggests physical access or domain-joined workstation compromise — a low-priority scenario. But the qualifier almost certainly describes the memory region accessible to the out-of-bounds read (process memory, not remote systems), not the delivery mechanism. In practice, this is a phishing-vector exploit: an attacker sends a malformed .xlsx file, and the out-of-bounds read triggers upon document open. The 'local' label describes what the bug can read, not how the attacker delivers it.
This distinction matters because information disclosure bugs in file parsers are rarely standalone objectives. An out-of-bounds read in Excel's parsing engine serves as reconnaissance — it can expose ASLR offsets, heap layout, or fragments of previously parsed data that enable reliable follow-on code execution. Microsoft Exchange and SharePoint exploitation history shows this pattern repeatedly. The disclosed memory becomes the raw material for a second-stage document delivered hours or days later, by which time the initial probing file is buried in file history, invisible to incident timelines.
The detection reality compounds the risk. Out-of-bounds reads that don't crash are exceptionally difficult to instrument against — access violations are the exception, not the norm. EDR signatures designed for this vulnerability class likely have substantial blind spots. More concerning: the 'local attacker' language has historically appeared in CVEs that were later upgraded to 'exploited in the wild' status once external researchers correlated active exploitation. The qualifier often reflects 'we don't yet have evidence of remote delivery' rather than 'delivery is actually constrained.'
The legacy parser layers add another dimension. Excel maintains compatibility shims for Quattro Pro, Lotus 1-2-3, and Mac file formats from the 1990s. These 'sleeping' code paths activate when opening files with legacy format markers. They haven't received active security review in years because no one expects users to open Lotus spreadsheets — but attackers know where assumptions crystallized before ASLR, and these deprecated parsers are where memory-disclosure bugs tend to be reliable rather than noisy. This is likely what the 'local attacker' fingerprint actually reveals: a fuzzing find in a legacy import path.
Your patch queue likely treats this as lower-priority based on EPSS, but the compound probability of a disclosure bug enabling downstream RCE isn't captured in probability models. Prioritize the patch. Then examine what behavioral signals you actually have for probing-stage exploitation — file parse events, memory access patterns, or legacy format invocation logs. If your detection strategy for this class of bug is 'hope the second stage crashes,' the gap is wider than you think.