CVE-2026-65066: Perl RingBuffer Information Disclosure Flaw

CVE-2026-65066 Overview

CVE-2026-65066 affects Data::RingBuffer::Shared versions before 0.04 for Perl. The module creates a world-readable memory-mapped backing file used for inter-process communication (IPC). The open() call in ring.h uses mode 0666 without the O_EXCL or O_NOFOLLOW flags. Under the default umask of 022, the file is created world-readable (0644). A local attacker on the same host can read IPC payloads from the shared segment. The attacker can also pre-plant a file or symlink at the target path to win a pre-creation race or redirect the open() call to an attacker-controlled location.

Critical Impact
Local users can read sensitive IPC data from world-readable shared segments in /tmp or /dev/shm, and symlink attacks can redirect file creation.

Affected Products

Data::RingBuffer::Shared for Perl, versions prior to 0.04
Applications relying on the module for shared-memory IPC
Linux and Unix-like systems using shared directories such as /tmp and /dev/shm

Discovery Timeline

2026-07-21 - CVE-2026-65066 published to NVD
2026-07-23 - Last updated in NVD database

Technical Details for CVE-2026-65066

Vulnerability Analysis

The vulnerability is a link-following flaw classified as [CWE-59]. The Data::RingBuffer::Shared module implements a shared ring buffer backed by an mmap file. The backing file lives in a shared directory such as /tmp or /dev/shm, where any local user has write access. The module opens the segment file with permissions that allow all local users to read its contents. Because the segment stores IPC payloads, any local user can observe messages exchanged between cooperating processes. The insecure open() behavior also allows a local attacker to substitute the backing file with a pre-planted target.

Root Cause

The open() call in ring.h is invoked with the flags O_RDWR|O_CREAT and mode 0666. Under the default umask of 022, the resulting file mode is 0644, which is world-readable. The absence of O_NOFOLLOW causes the call to follow symbolic links. The absence of O_EXCL causes the call to reuse an existing file rather than fail. These missing safeguards violate secure file creation practices for files placed in shared directories.

Attack Vector

A local attacker with an account on the host performs two related attacks. First, the attacker reads the world-readable segment directly, exposing IPC payloads written by other users. Second, the attacker pre-creates a file or symlink at the predictable segment path before the victim process starts. Because O_EXCL is missing, the victim reuses the pre-planted file. Because O_NOFOLLOW is missing, the victim follows the symlink to an attacker-chosen target. Both variants require only local, low-privilege access.

Detection Methods for CVE-2026-65066

Indicators of Compromise

Unexpected files or symbolic links matching Data::RingBuffer::Shared segment names in /tmp or /dev/shm
Backing files with world-readable permissions (0644) owned by service accounts
Symlinks in shared directories pointing to sensitive files targeted by long-running Perl processes

Detection Strategies

Inventory installed Perl modules and flag any Data::RingBuffer::Shared version below 0.04
Audit /tmp and /dev/shm for files created by Perl processes with mode 0644 or broader
Monitor open() and openat() syscalls from Perl interpreters using auditd or eBPF for missing O_EXCL and O_NOFOLLOW flags

Monitoring Recommendations

Alert on symlink creation events in shared directories that target predictable IPC paths
Track file access to shared-memory backing files by unexpected user identities
Baseline the set of processes that legitimately create shared segments and flag deviations

How to Mitigate CVE-2026-65066

Immediate Actions Required

Upgrade Data::RingBuffer::Shared to version 0.04 or later on all systems
Identify Perl applications using the module and restart them after upgrade
Restrict local shell access on hosts that run affected applications until patched

Patch Information

The maintainer released Data::RingBuffer::Shared version 0.04, which corrects the open() flags in ring.h. Details are available in the MetaCPAN Change Log and the MetaCPAN Diff Comparison between versions 0.03 and 0.04.

Workarounds

Place shared segments in a directory not writable by untrusted local users, such as an application-specific directory with mode 0700
Set a stricter process umask (for example, 077) before invoking code that creates the segment
Ensure the segment path does not exist before startup and enforce this with a wrapper script

bash

# Enforce a restrictive umask and a private segment directory
umask 077
install -d -m 0700 -o appuser -g appuser /var/run/myapp/ringbuf
export RINGBUF_DIR=/var/run/myapp/ringbuf
# Remove any stale or attacker-planted file before starting
rm -f -- "$RINGBUF_DIR/segment"
exec /usr/bin/perl /opt/myapp/bin/service.pl