Data::SpatialHash::Shared EUVD-2026-46367

Requires a local peer that can write the shared memory-mapped backing file used by Data::SpatialHash::Shared - filesystem write access to that specific file is the concrete prerequisite. The attacker poisons the array contents (a buckets[] head index, an entry next link, or the free_head free-list index) while keeping sph_validate_header's header/region checks satisfied. Exploitation is not self-triggering: a separate consumer process must perform a query (sph_walk_cell) to trigger the out-of-bounds read or an insert (sph_alloc_slot) to trigger the out-of-bounds write - this is the UI:R (user interaction) limiter. Limiting factors: local access only (AV:L, no network path), the required write permission on the shared file (not present under properly restricted permissions), the need for a victim process to operate on the poisoned file, and affected versions being strictly below 0.02.

The NVD CVSS 3.1 vector CVSS:3.1/AV:L/AC:L/PR:N/UI:R/S:U/C:H/I:H/A:H yields 7.8 (High), driven by full C/I/A impact from memory corruption but gated by local attack vector (AV:L) and required user interaction (UI:R - a victim process must query or insert against the poisoned file). This is a genuine memory-safety defect, but its real-world risk is bounded: exploitation is not remote and not automatable in the usual sense - it presupposes an attacker who can already write the shared backing file, i.e. a co-located local peer sharing that resource. The low EPSS (0.17%, 7th percentile) and absence from CISA KEV are consistent with a niche local-only bug rather than an internet-facing threat. Note a tension worth flagging: the CVSS marks PR:N (no privileges), yet the description's precondition - 'a local peer that can write the backing file' - is itself a meaningful access requirement that PR:N does not capture; defenders should treat filesystem write access to the shared file as the true gate. Weaponizing generic out-of-bounds writes into reliable code execution is non-trivial, so crash/DoS and integrity corruption are the most likely practical outcomes.

On a multi-user host, a low-privileged local user with write access to the shared backing file leaves the header fields valid but rewrites a bucket head (or an entry's next link, or free_head) to point outside the entries table. When a higher-privileged process later runs a lookup via sph_walk_cell or an insert via sph_alloc_slot, it reads or writes through the out-of-bounds index, corrupting its memory or crashing it. No public exploit code is currently identified, and reliable code execution would require additional heap-layout control.