Critical Redis Vulnerability Could Let Attackers Execute Code and Hijack Servers

A critical vulnerability in Redis, tracked as CVE-2026-23631 and dubbed “DarkReplica,” exposes authenticated deployments to remote code execution (RCE) through a complex use-after-free (UAF) condition in the replication subsystem. Discovered by security researcher Yoni Sherez during the ZeroDay.

In the Cloud 2025 competition, the flaw demonstrates how Redis’s internal Lua execution model and replication logic can be chained together to achieve full server compromise.

Critical Redis Vulnerability

The vulnerability specifically targets Redis deployments where attackers already possess valid authentication credentials. By abusing the SLAVEOF command, an attacker can coerce a target Redis instance into becoming a replica of a malicious controller server.

This sets the stage for exploitation by manipulating the synchronization process and triggering unsafe memory handling within Redis’s Lua functions engine.

Redis supports two Lua execution models: the legacy scripting engine (EVAL/EVALSHA) and the newer functions engine (FUNCTION LOAD/FCALL). The latter is central to this vulnerability.

Functions registered through this engine are persistent and synchronized across cluster nodes, making them a powerful attack surface. While Redis enforces sandboxing and execution constraints, its single-threaded architecture introduces edge cases when handling long-running scripts.

To prevent blocking, Redis uses a Lua hook mechanism that periodically checks for timeouts and processes pending events via processEventsWhileBlocked().

This mechanism allows limited command execution even while a script is running. However, a critical oversight exists: while most client commands are restricted during this state, replication traffic from a controller server is still processed without validating whether a Lua function is actively executing.

This creates a race condition. An attacker can execute a deliberately slow Lua function, such as an infinite loop, and then trigger a FULLRESYNC from the malicious master.

During synchronization, Redis clears existing function contexts using functionsLibCtxClearCurrent(), which ultimately frees the global lua_State object:

void functionsLibCtxClearCurrent(int async) {
    functionsLibCtxFree(curr_functions_lib_ctx);
    dictRelease(engines); // Frees lua_State
    functionsInit();
}

Once control returns to the still-running Lua function, it continues execution using a freed lua_State, resulting in a classic use-after-free condition. This primitive enables attackers to corrupt memory and eventually gain arbitrary code execution.

Exploitation requires careful heap manipulation because Redis uses jemalloc. Attackers leverage Lua primitives such as tostring() to leak heap addresses and controlled allocations to reclaim freed memory regions. For example, a coroutine object can be freed and replaced with attacker-controlled data:

local a = coroutine.create(function() end)
local addr = tostring(a)
a = nil
collectgarbage("collect")
a = "AAAAAA..." -- Reallocates at same address

To stabilize execution, attackers pivot to a separate Lua state using coroutines, allowing them to operate in a controlled environment. From there, they construct arbitrary read/write primitives by abusing Lua table internals, ultimately enabling manipulation of critical function pointers.

One reliable exploitation path involves overwriting the lua_State->l_G->frealloc pointer, which acts as a custom memory allocator. By redirecting this pointer to system() and controlling its argument, attackers achieve command execution:

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()

Redis addressed the vulnerability on May 5, 2026, releasing patches across all supported versions. Affected versions include Redis 7.2.0 through 7.2.13, 7.4.0 through 7.4.8, 8.2.0 through 8.2.5, 8.4.0 through 8.4.2, and 8.6.0 through 8.6.2. Fixed versions are 7.2.14, 7.4.9, 8.2.6, 8.4.3, and 8.6.3.

Organizations running Redis in production environments should prioritize patching immediately. Additionally, restricting replication configuration, turning off unnecessary Lua functionality, and enforcing strict authentication controls can reduce exposure.

Given Redis’s widespread use in cloud-native and microservices architectures, this vulnerability poses significant risk for lateral movement and infrastructure compromise if left unaddressed.

Follow us on Google News, LinkedIn, and X to Get Instant Updates and Set GBH as a Preferred Source in Google.