CVE-2026-64617 in Data::PubSub::Shared
Summary
by MITRE • 07/21/2026
Data::PubSub::Shared versions before 0.07 for Perl create a world-readable mmap backing file and open it without O_EXCL or O_NOFOLLOW.
The segment is created in pubsub.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::PubSub::Shared versions prior to 007 involves a critical flaw in how shared memory segments are created and managed within Perl applications. This issue stems from improper file system permissions and opening flags that create exploitable conditions for local privilege escalation and information disclosure. The problem manifests specifically in the pubsub.h implementation where the open() system call is invoked with insufficient security parameters, creating a dangerous race condition scenario that can be exploited by malicious local users.
The technical flaw centers on the file creation process that uses open(path, O_RDWR|O_CREAT, 0666) without proper security considerations. The default mode 0666 combined with typical umask values of 022 results in world-readable files with mode 0644, making sensitive IPC data accessible to all local users. Furthermore, the absence of O_NOFOLLOW flag creates a symlink traversal vulnerability where attackers can place malicious symbolic links at the target path, causing the application to open unintended files. The lack of O_EXCL flag compounds this issue by allowing silent operation on pre-existing files rather than failing with an error condition that would alert administrators to potential tampering.
This vulnerability directly impacts system security by enabling unauthorized access to shared memory segments that typically contain sensitive data exchanged between processes. When these segments are created in shared directories like /tmp or /dev/shm, the world-readable permissions expose IPC payloads to any local user who can access these locations. The race condition aspect becomes particularly dangerous as attackers can pre-create files or symlinks at the target path before the legitimate application creates them, effectively hijacking the intended memory mapping and potentially gaining access to confidential information or manipulating data flows within applications using this library.
The operational impact extends beyond simple information disclosure to include potential privilege escalation scenarios and data manipulation attacks. An attacker with local access can exploit this vulnerability to read sensitive information stored in shared memory segments, intercept communications between processes, or even inject malicious data into the IPC system. This represents a significant weakness in the security model of applications relying on Data::PubSub::Shared for inter-process communication, particularly in multi-user environments where proper file system permissions and atomic operations are essential for maintaining data integrity and confidentiality.
The vulnerability aligns with CWE-732: Incorrect Permission Assignment for Critical Resource and CWE-362: Concurrent Execution using Shared Resources, while also mapping to ATT&CK techniques involving privilege escalation through local reconnaissance and exploitation of insecure file permissions. Organizations should immediately update to Data::PubSub::Shared version 0.07 or later, which implements proper file creation flags including O_EXCL and O_NOFOLLOW, and ensures appropriate file permissions are set during shared memory segment creation. Additional mitigations include restricting access to shared directories, implementing proper file system monitoring, and conducting regular security audits of applications using this library to prevent exploitation of similar vulnerabilities in other components.