Heap buffer overflow in Microsoft Access parsing (.accdb/.mdb files) with local code execution impact—CVE-2026-64906, CVSS 7.8, EPSS 0.0031.
The EPSS/CVSS gap here is not a scoring inconsistency. It's a market signal. Threat actors price vulnerabilities on expected return, and local execution requiring victim interaction (opening a malicious file) signals low ROI for mass targeting. Low EPSS does not mean this is hard to exploit—it means attackers are finding more attractive initial access vectors elsewhere. That's a tactical choice by adversaries, not an intrinsic property of the bug.
But here's what should keep defenders up at night: the vulnerability isn't the heap overflow in the parser. It's the organizational assumption that Access file handling is a bounded application problem. Access databases are data interchange nodes embedded in enterprise workflows—files traverse email attachments, SharePoint, shared drives, Power Automate flows, and SQL integration pipelines that treat .accdb artifacts as implicitly safe. When you deprioritize this patch because the EPSS is low, you're making a bet that attackers will continue to find other paths more attractive. That's a reasonable operational trade-off—but name it honestly: you're accepting residual risk because you have other fires, not because the code is 'genuinely hard to exploit.'
More critically, the file itself becomes the persistent attack surface. Access patches often lag behind infrastructure patches by months—it's end-user software outside automated deployment pipelines. A weaponized .accdb file created today will remain effective against unpatched systems well after the vendor patch exists, because the deployment window compounds the exposure. Measure this as exposure-person-days, not CVSS scores: a 7.8 with a six-month exposure window is categorically different from a 7.8 with a two-week window, even if EPSS is identical at disclosure.
Before patching, answer this: does your organization have any visibility into how many Access files are floating through your infrastructure as unsanctioned, unowned data pipelines? Who owns the .accdb files on that forgotten network share? Which Power Automate flows ingest Access data without provenance tracking? The patch matters. But the inventory of what your organization is still running on top of .accdb files matters more. If Microsoft has patched 3-4 parsing heap overflows in Access across the last decade and each response was a bounds-checking surface patch rather than architectural investment in memory-safe parsing, then you're not looking at an isolated incident—you're looking at a predictable failure mode that will recur.