Severity by source
AV:N/AC:L/PR:N/UI:N/S:U/C:H/I:N/A:H
Exploitation requires local write access to the shared-memory backing file, so AV:L and PR:L; the out-of-bounds read discloses adjacent memory (C:H) and can crash the process (A:H), with no integrity impact.
Primary rating from Vendor (9b29abf9-4ab0-4765-b253-1875cd9b441e).
CVSS VectorVendor: 9b29abf9-4ab0-4765-b253-1875cd9b441e
Lifecycle Timeline
5DescriptionCVE.org
Data::HashMap::Shared versions before 0.14 for Perl allow an out-of-bounds read via an unvalidated arena offset and length in shm_str_copy.
The attach-time validator shm_validate_header checks the header scalars and region layout against the file size, but does not validate the array contents it then trusts. shm_str_copy does memcpy(dst, arena + off, len) with off and len read raw from the mmap'd segment and unbounded, on the each, keys, values, pop, shift, take, swap, drain and cursor paths. The get path bounds off and len separately and is not affected.
A local peer that can write the backing file can leave the header valid while poisoning a record's offset and length, so iterating or draining the map copies a file-controlled offset and length out of the arena, reading adjacent memory or crashing the process.
AnalysisAI
Out-of-bounds read in the Perl module Data::HashMap::Shared before 0.14 lets a local peer that can write the shared-memory backing file corrupt per-record offset and length values, causing the map to copy attacker-controlled regions out of the arena. The flaw affects the each, keys, values, pop, shift, take, swap, drain and cursor code paths and can leak adjacent process memory or crash the process. There is no public exploit identified at time of analysis and EPSS exploitation probability is low (0.16%, 5th percentile).
Technical ContextAI
Data::HashMap::Shared is a Perl module that implements a hash map backed by an mmap'd shared-memory segment (the arena), enabling multiple processes to share a map through a common backing file. The root cause is CWE-125 (out-of-bounds read): the attach-time validator shm_validate_header verifies header scalars and region layout against the file size but never validates the array record contents it subsequently trusts. The copy helper shm_str_copy performs memcpy(dst, arena + off, len) with the offset (off) and length (len) read raw and unbounded from the mmap'd segment, so any path that dereferences a record via that helper (each, keys, values, pop, shift, take, swap, drain, cursor) reads from a file-controlled position. The separate get path independently bounds off and len and is therefore not affected.
RemediationAI
Vendor-released patch: 0.14 - upgrade Data::HashMap::Shared to version 0.14 or later, which adds bounds validation on the record offset and length in the affected copy path (see the 0.13-to-0.14 diff of shm_generic.h at https://metacpan.org/release/EGOR/Data-HashMap-Shared-0.14/diff/EGOR/Data-HashMap-Shared-0.13#shm_generic.h and the changelog at https://metacpan.org/release/EGOR/Data-HashMap-Shared-0.14/changes). Where immediate upgrade is not possible, restrict filesystem write permissions on the shared-memory backing file so only the trusted owning process can modify it (remove group/other write and place the file in a directory not writable by untrusted local users), which removes the poisoning precondition at the cost of preventing legitimate multi-writer sharing across differently-privileged accounts; additionally, prefer the get accessor over the each/keys/values/pop/shift/take/swap/drain/cursor paths on untrusted maps, since get independently bounds off and len and is not affected, though this limits functionality to single-key lookups.
Same weakness CWE-125 – Out-of-bounds Read
View allSame technique Buffer Overflow
View allShare
External POC / Exploit Code
Leaving vuln.today
EUVD-2026-46355
GHSA-4m33-8fcc-g5rp