CVE-2026-65063 in Data::RadixTree::Shared
Summary
by MITRE • 07/21/2026
Data::RadixTree::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 radix.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::RadixTree::Shared versions prior to 002 involves a critical flaw in how temporary memory mapping files are created and accessed within Perl applications. This issue stems from improper file creation permissions and security considerations when establishing shared memory segments that are essential for inter-process communication. The problem manifests specifically in the radix.h implementation where the open() system call is invoked with O_RDWR|O_CREAT flags but without adequate security measures to prevent malicious interference.
The technical implementation flaw occurs when the library creates a backing file using open(path, O_RDWR|O_CREAT, 0666) which establishes world-readable permissions by default. Under standard umask conditions of 022, this results in 0644 permissions allowing any local user to read the contents of the memory mapping segment. This represents a classic security misconfiguration that violates the principle of least privilege and creates an information disclosure vulnerability. The absence of O_NOFOLLOW flag exposes the system to symbolic link attacks where attackers can create malicious symlinks at the target path, causing the application to open unintended files.
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, they become accessible to all local users who can potentially read sensitive IPC payloads stored within these memory mappings. The lack of O_EXCL flag creates a race condition vulnerability where an attacker can pre-create a file at the target path before the legitimate process attempts to open it, effectively allowing the attacker to control what data is loaded into the memory segment. This vulnerability aligns with CWE-732: Incorrect Permission Assignment for Critical Resource and represents a significant weakness in the application's security posture.
The exploitability of this vulnerability follows ATT&CK technique T1068: Exploitation for Privilege Escalation through local attack vectors. Attackers can leverage this flaw by either creating symbolic links to gain access to arbitrary files or by pre-creating files to manipulate the memory mapping contents. The shared nature of these segments in world-readable directories creates an ideal environment for information gathering and potential data corruption attacks. Organizations using this library in production environments face significant risk exposure, particularly when applications handle sensitive data through these memory mappings.
Mitigation strategies should focus on implementing proper file creation security measures including setting restrictive permissions during file creation, utilizing O_EXCL flag to prevent race conditions, and avoiding the use of world-readable directories for shared memory segments. System administrators should also consider updating to version 0.02 or later where these security issues have been addressed. Additionally, implementing proper access controls and monitoring for unauthorized file creation in shared directories can help detect potential exploitation attempts. The fix typically involves modifying the file creation logic to use more restrictive permissions and ensuring atomic file creation operations that prevent attackers from manipulating the file system state during the creation process.
This vulnerability demonstrates the critical importance of secure coding practices in memory management and inter-process communication libraries. The issue highlights how seemingly minor implementation details in file handling can create significant security implications, particularly when dealing with shared resources in multi-user environments. Security-conscious development practices must always consider the full attack surface of temporary file operations, including proper permission management, race condition prevention, and symlink handling to prevent exploitation by local attackers who may have limited privileges but can manipulate the file system state.