CVE-2026-65066 in Data::RingBuffer::Shared
Summary
by MITRE • 07/21/2026
Data::RingBuffer::Shared versions before 0.04 for Perl create a world-readable mmap backing file and open it without O_EXCL or O_NOFOLLOW.
The segment is created in ring.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::RingBuffer::Shared versions before 0.04 represents a critical security flaw that stems from improper file handling practices during shared memory segment creation. This issue manifests through the ring.h implementation where the open() system call is invoked with parameters that create predictable and insecure file permissions. The function call open(path, O_RDWR|O_CREAT, 0666) directly exposes the underlying security risk by setting overly permissive file modes without proper access control considerations.
The fundamental technical flaw lies in the combination of three critical oversights within the file creation process. First, the use of mode 0666 allows world-readability of the created file, which under typical default umask settings of 022 results in 0644 permissions that permit any local user to read the contents. Second, the absence of O_NOFOLLOW flag creates a symbolic link traversal vulnerability where attackers can plant malicious symlinks at the target path to redirect file operations. Third, the lack of O_EXCL flag eliminates the critical safety check that would prevent overwriting existing files, allowing attackers to pre-create files at the target location and effectively hijack the intended file descriptor.
This vulnerability directly maps to CWE-73 and CWE-276 within the Common Weakness Enumeration framework, representing weaknesses in improper file permissions and improper handling of symbolic links. The operational impact is severe for systems utilizing this library, as any local attacker with access to the shared directory can gain read access to sensitive IPC payloads stored within these world-readable segments. The vulnerability becomes particularly dangerous when considering that shared memory segments are typically created in directories like /tmp or /dev/shm where multiple users have write access, creating numerous potential attack vectors.
The race condition aspect of this vulnerability creates additional security implications as attackers can exploit timing windows to pre-create files or symlinks before the legitimate application attempts to open them. This pre-creation race condition allows attackers to effectively control what data gets written to the shared memory segment or to redirect the file operations entirely, potentially leading to information disclosure or even privilege escalation depending on the context in which these segments are used. The attack surface expands significantly when considering that many systems rely on shared memory mechanisms for inter-process communication where sensitive data flows through these vulnerable segments.
Mitigation strategies should focus on implementing proper file creation practices that align with security best practices and industry standards such as those recommended in the OWASP Secure Coding Practices. The most effective immediate fix involves modifying the open() call to include O_EXCL flag to prevent overwriting existing files, adding O_NOFOLLOW to prevent symlink traversal attacks, and using more restrictive file permissions such as 0600 or 0640 instead of 0666. Additionally, applications should avoid creating world-readable files in shared directories and should consider using secure temporary file creation mechanisms that guarantee atomicity and proper access controls. The implementation should also consider validating the target path for symbolic links before attempting to create or open files, ensuring that the file system state remains consistent with security expectations throughout the application lifecycle.