A significant vulnerability has been identified in Redis, a widely used data structure store, termed CVE-2026-23631 and informally referred to as “DarkReplica.” This flaw poses a serious threat to authenticated deployments by enabling remote code execution (RCE) through an intricate use-after-free (UAF) condition stemming from issues within the replication subsystem. The discovery of this vulnerability was made by security researcher Yoni Sherez during a recent ZeroDay event.
In the competitive landscape of cloud technologies, particularly highlighted during the Cloud 2025 competition, the flaw demonstrates a concerning link between Redis’s internal Lua execution model and its replication mechanisms. Together, these interconnected systems can be manipulated to achieve a complete compromise of the server.
Understanding the Vulnerability
The vulnerability specifically preys on Redis deployments where attackers have already acquired valid authentication credentials. By utilizing the SLAVEOF command, a malicious actor can force a targeted Redis instance to replicate data from a malicious controller server. This action sets off a chain reaction that can be exploited by interfering with the synchronization process and instigating unsafe memory handling during Lua function executions.
Redis supports two different Lua execution models: the traditional scripting engine utilizing EVAL/EVALSHA commands and the more recent functions engine that employs FUNCTION LOAD and FCALL commands. The latter of these models is crucial to the vulnerability, as functions registered through it are persistent and synchronized across cluster nodes, providing a sizable attack surface for potential exploitation.
While Redis has mechanisms to enforce sandboxing and execution constraints, its single-threaded architecture introduces particular edge cases. For instance, to avoid blocking operations, Redis implements a Lua hook mechanism that checks for timeouts and processes pending events through its processEventsWhileBlocked() function. Although this mechanism allows for limited command execution while scripts are running, an oversight exists: replication traffic from a controller server is processed without the necessary validation regarding ongoing Lua function executions.
This oversight creates a precarious situation. An attacker can manipulate this flaw by executing a deliberately lengthy Lua function, such as an infinite loop, and simultaneously trigger a FULLRESYNC from a malicious master server. During this synchronization phase, Redis attempts to clear existing function contexts through functionsLibCtxClearCurrent(), which leads to the freeing of the global lua_State object.
Once control returns to the still-active Lua function, execution continues using the freed lua_State, resulting in a classic use-after-free condition. This vulnerability potentially allows attackers to corrupt memory areas and ultimately achieve arbitrary code execution.
Exploitation Mechanics
To effectively exploit this vulnerability, attackers must engage in meticulous heap manipulation, particularly since Redis utilizes jemalloc. By leveraging Lua primitives like tostring(), attackers can leak heap addresses and orchestrate controlled allocations to reclaim previously freed memory regions. For example, an attacker could free a coroutine object and subsequently replace it with data they’ve controlled:
local a = coroutine.create(function() end)
local addr = tostring(a)
a = nil
collectgarbage("collect")
a = "AAAAAA..." -- Reallocates at same addressTo maintain stable execution, attackers utilize a separate Lua state with the help of coroutines, enabling them to operate within a controlled environment. They can then create arbitrary read/write primitives by exploiting the internals of Lua tables, ultimately facilitating the manipulation of critical function pointers.
One reliable exploitation route includes overwriting the lua_State->l_G->frealloc pointer, which serves as a custom memory allocator. By redirecting this pointer towards the system() function and controlling its argument, attackers can execute arbitrary commands:
write(fake_l_G + offsetof(global_State, frealloc), system);
write(fake_l_G + offsetof(global_State, ud), command_payload_addr);
coroutine.resume(co); -- Triggers system()Response and Recommendations
The Redis development team addressed this critical vulnerability on May 5, 2026, releasing patches applicable across all supported versions. The versions that are notably affected include Redis 7.2.0 to 7.2.13, 7.4.0 to 7.4.8, 8.2.0 to 8.2.5, 8.4.0 to 8.4.2, and 8.6.0 to 8.6.2. The fixed versions are now identified as 7.2.14, 7.4.9, 8.2.6, 8.4.3, and 8.6.3.
Organizations operating Redis in production environments are urged to prioritize immediate patching to mitigate risks associated with this vulnerability. Furthermore, implementing strict authentication controls, restricting unnecessary replication configurations, and turning off unneeded Lua functionalities can significantly reduce exposure.
Given the extensive adoption of Redis in cloud-native and microservices architectures, the implications of this vulnerability are considerable. If left unmitigated, it could become a significant risk, facilitating lateral movement and potential infrastructure compromise within organizations. Addressing this vulnerability proactively is essential to maintaining the integrity and security of affected systems.