CVE-2026-65068 in Data::SpatialHash::Shared
Summary
by MITRE • 07/21/2026
Data::SpatialHash::Shared versions before 0.02 for Perl create a world-readable mmap backing file and open it without O_EXCL or O_NOFOLLOW.
The segment is created in sphash.h with open(path, O_RDWR|O_CREAT, 0666). The mode is 0666, so under the default umask 022 the file is created mode 0644 (world-readable). O_NOFOLLOW is absent, so a symlink planted at the path is followed, and O_EXCL is absent, so the open silently uses a pre-planted file instead of failing.
A "Shared" segment naturally lives in a shared directory such as /tmp or /dev/shm, where any local user can read the IPC payloads stored in the world-readable segment, and a pre-planted file or symlink at the path lets a local attacker win a pre-creation race or redirect the open.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/21/2026
The vulnerability in Data::SpatialHash::Shared versions before 002 involves a critical flaw in file creation and access control mechanisms within Perl's spatial hashing implementation. This issue stems from improper file descriptor management during the creation of shared memory segments that are essential for inter-process communication. The problem manifests when the library creates a memory-mapped file using open() system call with insufficient security parameters, specifically failing to implement proper access controls and race condition protections.
The technical implementation flaw occurs in sphash.h where the file creation process uses open(path, O_RDWR|O_CREAT, 0666) without adequate security considerations. The mode parameter 0666 results in world-readable files when combined with default umask settings of 022, creating a file with permissions 0644 that can be accessed by any local user. This violates fundamental security principles for shared memory segments that should typically have restricted access patterns to prevent unauthorized data exposure.
The operational impact of this vulnerability is significant within local privilege escalation contexts and information disclosure scenarios. When the library creates segments in shared directories such as /tmp or /dev/shm, any local attacker can exploit the missing O_NOFOLLOW flag to manipulate symbolic links and redirect file operations to malicious targets. Additionally, the absence of O_EXCL creates a race condition vulnerability where attackers can pre-create files at the target path, allowing them to bypass normal file creation procedures and potentially inject malicious data into the shared memory segment.
This vulnerability aligns with CWE-732: Incorrect Permission Assignment for Critical Resource and CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, while also mapping to ATT&CK techniques involving privilege escalation and credential access. The flaw represents a classic case of insufficient file access control in shared memory contexts, where the security model fails to account for local user manipulation capabilities. The use of world-readable permissions combined with missing protective flags creates an attack surface that directly enables unauthorized data access and potential manipulation of IPC payloads stored within these segments.
Recommended mitigations include implementing proper file creation flags such as O_EXCL to prevent race conditions, adding O_NOFOLLOW to prevent symbolic link manipulation, setting restrictive file permissions during creation, and avoiding shared directories for critical IPC segments. Organizations should also consider upgrading to patched versions of Data::SpatialHash::Shared or implementing additional access controls at the system level to restrict file creation in shared directories where such vulnerabilities may exist.