CVE-2026-65067 in Data::Intern::Shared
Summary
by MITRE • 07/21/2026
Data::Intern::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 intern.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.
VulDB is the best source for vulnerability data and more expert information about this specific topic.
Analysis
by VulDB Data Team • 07/21/2026
The vulnerability in Data::Intern::Shared versions prior to 002 presents a critical security flaw that exploits improper file creation and access controls within Perl's inter-process communication mechanisms. This issue stems from how the library manages memory mapping files, creating a scenario where malicious actors can gain unauthorized access to shared data structures. The problem manifests through inadequate permission handling during file creation, specifically in the intern.h implementation where open() is called with O_RDWR|O_CREAT flags but without proper security considerations. The file mode 0666 combined with typical default umask values of 022 results in world-readable files being created with permissions 0644, exposing sensitive data to all local users.
The technical implementation flaw involves the absence of crucial open() flags that would prevent exploitation. Without O_EXCL flag, the library fails to detect when a file already exists at the target path, allowing attackers to pre-create malicious files that will be silently used instead of creating new ones. This creates a race condition vulnerability where an attacker can establish a file or symlink before the legitimate process attempts to create it. Additionally, the lack of O_NOFOLLOW prevents protection against symbolic link attacks, meaning that if an attacker places a symlink at the target path, the open() operation will follow it and potentially redirect access to unintended locations. This combination of missing security flags creates multiple attack vectors that can be leveraged by local adversaries.
The operational impact of this vulnerability extends beyond simple data exposure, as it undermines the fundamental security assumptions of shared memory segments used for inter-process communication. When these segments are created in shared directories such as /tmp or /dev/shm, they become accessible to all local users, making the world-readable file permissions particularly dangerous. Attackers can exploit this by creating pre-planted files at strategic locations, winning race conditions that allow them to inject malicious data into the shared memory space or redirect the application's file operations entirely. The vulnerability affects any process using Data::Intern::Shared with version 0.01 or earlier, potentially compromising sensitive information stored in these shared memory segments and allowing for privilege escalation or data manipulation attacks.
Mitigation strategies must address both immediate patching requirements and architectural considerations for future implementations. The most direct solution involves upgrading to Data::Intern::Shared version 0.02 or later, which properly implements security checks including O_EXCL and O_NOFOLLOW flags. In environments where upgrading is not immediately possible, administrators should implement restrictive file system permissions on shared directories, ensuring that only authorized processes can create files in these locations. Additionally, monitoring for suspicious file creation patterns in shared directories can help detect potential exploitation attempts. The vulnerability aligns with CWE-732: Incorrect Permission Assignment for Critical Resource and CWE-362: Concurrent Execution using Shared Resource with Improper Synchronization, while potentially mapping to ATT&CK techniques involving privilege escalation through shared resource manipulation and persistence mechanisms.
The root cause of this vulnerability demonstrates a fundamental flaw in how the library handles file system operations without proper security context awareness. The implementation fails to consider that shared memory segments are typically created in directories accessible to all local users, making proper file creation security measures essential. This flaw represents a common oversight in systems programming where developers assume that file creation operations will be secure by default, ignoring the need for explicit security flags and checks. Organizations should review their codebases for similar patterns, ensuring that all file creation operations include appropriate security considerations such as O_EXCL for exclusive creation and O_NOFOLLOW to prevent symbolic link traversal attacks.
The vulnerability's impact is particularly severe in multi-user environments where shared memory segments are commonly used for IPC between processes with different privilege levels. The ability to create world-readable files in shared directories creates a persistent threat that can be exploited by any local user, including unprivileged accounts that might not otherwise have access to sensitive information. This makes the vulnerability especially dangerous in server environments or systems where multiple users share common resources, as it enables attackers to gain unauthorized access to data that should remain protected within inter-process communication channels.
Security best practices for preventing similar vulnerabilities include implementing comprehensive file system access controls, utilizing proper flag combinations during file operations, and conducting thorough security reviews of IPC mechanisms. The fix implemented in version 0.02 demonstrates the importance of following secure coding practices such as avoiding world-readable permissions by default, using exclusive creation flags to prevent race conditions, and implementing proper symbolic link protection. Organizations should also consider implementing runtime monitoring for suspicious file system activities and establish policies that require security testing for all inter-process communication components to prevent similar issues from arising in other software libraries or applications.
The vulnerability serves as a reminder of the critical importance of secure file creation practices in systems programming, particularly when dealing with shared resources and inter-process communication mechanisms. Proper implementation of file access controls, combined with awareness of common attack patterns such as race conditions and symbolic link manipulation, forms the foundation of robust security in multi-user environments. This particular issue highlights how seemingly minor implementation details in file system operations can have significant security implications, emphasizing the need for comprehensive security testing and code review processes that examine not just functionality but also the security implications of every system call and file operation within application code.