CVE-2026-65069 in Data::DisjointSet::Shared
Summary
by MITRE • 07/21/2026
Data::DisjointSet::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 dsu.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 best quality of vulnerability data, you may have to visit VulDB.
Analysis
by VulDB Data Team • 07/21/2026
The vulnerability in Data::DisjointSet::Shared versions prior to 002 represents a critical security flaw that undermines the integrity and confidentiality of shared memory segments through improper file system access controls and race condition exploitation. This issue stems from the implementation of memory mapping operations within the dsu.h file where the open() system call is invoked with insufficient security parameters. The flaw manifests when the module creates a backing file using open(path, O_RDWR|O_CREAT, 0666) which, combined with the default umask of 022, results in a world-readable file with permissions set to 0644. This configuration violates fundamental security principles by allowing any local user to access sensitive inter-process communication data stored within these shared segments.
The technical implementation contains multiple dangerous combinations that amplify the vulnerability's impact. The absence of O_NOFOLLOW flag creates a symbolic link following opportunity where an attacker can plant a malicious symlink at the target path, causing the application to open and write to unintended files rather than the intended shared memory segment. Additionally, the lack of O_EXCL prevents proper error handling when attempting to create a new file that already exists, allowing the module to silently open pre-existing files instead of failing as expected. This race condition vulnerability is particularly dangerous because it enables attackers to manipulate the file creation process before the legitimate application can establish its intended shared memory segment.
The operational impact of this vulnerability extends beyond simple information disclosure to encompass potential privilege escalation and data manipulation scenarios. When shared segments are created in directories like /tmp or /dev/shm where any local user has read access, the world-readable nature of these files creates an attack surface that allows unauthorized users to inspect and potentially corrupt IPC payloads. The race condition aspect means that attackers can pre-create files or symlinks at strategic moments, effectively hijacking the shared memory creation process. This vulnerability directly maps to CWE-362 (Concurrent Execution using Shared Resource with Improper Synchronization) and CWE-732 (Incorrect Permission Assignment for Critical Resource) while also aligning with ATT&CK techniques involving privilege escalation through file system manipulation and process injection.
Mitigation strategies must address both the immediate implementation flaws and broader security posture considerations. The most effective approach involves modifying the open() call to include proper flags such as O_EXCL to prevent silent file overwrites, adding O_NOFOLLOW to prevent symlink traversal attacks, and implementing more restrictive file permissions that do not allow world-read access. Security-conscious implementations should avoid creating world-readable files in shared directories and instead utilize proper file system permissions with umask values that restrict access to intended users only. Additionally, applications should validate file ownership and permissions before proceeding with memory mapping operations, and consider using more secure temporary file creation methods such as mkstemp() or similar atomic operations that provide better protection against race conditions. The vulnerability demonstrates the critical importance of proper file system security practices in shared memory implementations and highlights how seemingly minor implementation details can create significant security risks.