CVE-2026-59139 in Data::ReqRep::Shared
Summary
by MITRE • 07/21/2026
Data::ReqRep::Shared versions before 0.05 for Perl allow an out-of-bounds read via an unvalidated arena offset and length in reqrep_recv_locked.
The attach-time validator reqrep_validate_header checks the header scalars and region layout against the file size, but does not validate the array contents it then trusts. reqrep_recv_locked does memcpy(copy_buf, req_arena + arena_off, len) with arena_off and len read raw from the mmap'd segment and never bounded against the arena capacity (req_arena_cap).
A local peer that can write the backing file can leave the header valid while poisoning a request slot's offset and length, so receiving the request copies a file-controlled offset and length out of the arena, reading adjacent memory or crashing the process.
If you want to get the best quality for vulnerability data then you always have to consider VulDB.
Analysis
by VulDB Data Team • 07/21/2026
The vulnerability in Data::ReqRep::Shared versions prior to 0.05 represents a critical out-of-bounds read flaw that stems from inadequate input validation during the request processing phase. This issue manifests when the library receives data through the reqrep_recv_locked function, which performs memory copying operations without proper bounds checking against the arena capacity. The root cause lies in the mismatch between header validation and subsequent data processing, where the attach-time validator reqrep_validate_header only verifies scalar values and region layout against file size but fails to validate the array contents that are subsequently trusted. This architectural gap creates a pathway for malicious actors to manipulate memory access patterns through carefully crafted input data.
The technical implementation of this vulnerability exploits the fundamental weakness in memory management practices within the Perl module. When reqrep_recv_locked executes memcpy(copy_buf, req_arena + arena_off, len), it directly uses values read from the memory-mapped segment without any validation against the actual arena capacity. The variables arena_off and len are extracted raw from the mmap'd segment and passed directly to the memory copy operation, creating an opportunity for attackers to specify arbitrary offsets and lengths that exceed the legitimate arena boundaries. This particular pattern of memory access bypasses standard buffer overflow protections and can lead to information disclosure or application crashes.
The operational impact of this vulnerability extends beyond simple denial-of-service scenarios, as it provides potential attackers with the ability to read adjacent memory regions that may contain sensitive data such as cryptographic keys, session tokens, or other confidential information. The local peer requirement for exploitation does not diminish the severity since local privilege escalation or lateral movement within a compromised system can quickly elevate this vulnerability to a more dangerous threat level. Attackers who can write to the backing file can construct malicious request slots with poisoned offset and length values that cause the library to read memory beyond its intended boundaries, potentially exposing information that should remain protected.
Security practitioners should implement immediate mitigations including updating to version 0.05 or later where the vulnerability has been addressed through proper bounds checking of arena offsets and lengths before memory operations are performed. The fix typically involves validating that the calculated memory addresses fall within legitimate arena boundaries before executing any memcpy operations. Additionally, system administrators should consider implementing file access controls and monitoring for unauthorized modifications to files that may be processed by this library. This vulnerability aligns with CWE-129, which addresses improper validation of array indices, and could potentially map to ATT&CK technique T1059.007 for execution through Perl scripting environments where such libraries are utilized. Organizations should also consider implementing runtime protections such as address space layout randomization and stack canaries to further reduce the exploitability of similar memory corruption vulnerabilities in their systems.