Redis, a widely adopted open-source in-memory data structure store, has addressed a critical use-after-free vulnerability (CVE-2026-23479) that could allow an authenticated attacker to execute arbitrary operating system commands. The flaw, discovered by an autonomous AI bug-hunting tool named Xint Code, remained undetected in stable Redis branches for over two years before being patched on May 5th. This vulnerability poses a significant risk, especially given Redis’s prevalence in cloud environments, often deployed with minimal authentication.
The severity of CVE-2026-23479 is underscored by its CVSS ratings, with a 8.8 under CVSS 3.1 and a 7.7 under CVSS 4.0. The vulnerability was introduced in Redis version 7.2.0 and has affected all subsequent stable releases until the recent fix. Security researchers at Wiz highlighted that the extensive cloud footprint of Redis, combined with default configurations that often lack strong password protection, exacerbates the threat. Even a user with basic authenticated access could potentially exploit this flaw.
Redis Authentication Bypass Vulnerability and Exploit Chain
The technical details of the vulnerability reveal that the flaw resides within the `unblockClientOnKey()` function in `src/blocked.c`. This function is triggered when a key event causes a blocked command to resume execution. The problematic sequence involves Redis freeing a client’s memory while still attempting to process commands associated with that client. This leads to a use-after-free condition, a common class of memory corruption errors (CWE-416), where the software continues to access memory that has already been deallocated.
According to Wiz’s analysis, the bug was introduced through two specific commits in early 2023. A January 2023 refactor unchecked a client call, and a subsequent March 2023 change increased client data access after the initial problematic call. While neither commit was inherently dangerous in isolation, their combined effect, integrated into Redis version 7.2.0, created the exploitable condition that bypassed standard security reviews.
The exploit chain, as detailed by Wiz and Team Xint Code, is a multi-stage process that leverages several Redis functionalities. Initially, a Lua script is used to leak a heap pointer, which is crucial for locating specific memory addresses. Subsequently, an attacker manipulates client memory limits to prepare for the core exploit. By parking a large client on a stream and then reducing its memory limits, Redis is tricked into freeing the client’s memory mid-operation. Immediately following this, a specially crafted `SET` command reclaims the freed memory slot, effectively placing a fake client structure in its place.
The final stage capitalizes on Redis’s internal memory accounting. The function `updateClientMemoryUsage()` performs an out-of-bounds decrement operation, utilizing attacker-controlled fields. This manipulation targets the Global Offset Table (GOT), a table that stores addresses of functions and variables, to overwrite the address of `strcasecmp()` with that of `system()`. Consequently, the next command Redis parses is executed as a system command, achieving remote code execution (RCE).
The default Redis Docker image simplifies the final exploitation step due to its configuration, which leaves the GOT writable at runtime. While Address Space Layout Randomization (ASLR) and Position-Independent Executables (PIE) are designed to thwart such attacks, they are rendered ineffective here because the critical write operation is relative to a globally fixed offset, determined at build time.
Implications for Cloud Deployments and Security Posture
The exploit requires authentication and privileges associated with the `@admin`, `@scripting`, `@stream`, and `@read/@write` ACL categories. Disturbingly, the default Redis user often possesses all these necessary privileges. In many common deployment scenarios, these permissions are consolidated into a single shared application or operator role, making the default configuration particularly vulnerable.
Team Xint Code, the discoverer of this critical Redis security flaw, is an autonomous AI security tool developed to identify bugs in large codebases. They publicly demonstrated a working exploit at ZeroDay.Cloud 2025, a cybersecurity event held in London in December. While Redis has reported no evidence of active exploitation in its own or customer environments, the public disclosure of the full technical details significantly increases the risk of future attacks.
Redis has released patched minor versions across its stable branches to address CVE-2026-23479. These include versions 7.2.14, 7.4.9, 8.2.6, 8.4.3, and 8.6.3, all made available on May 5th. For users unable to immediately patch, several mitigation strategies are recommended. Keeping Redis instances isolated from the public internet and protected behind TLS encryption is paramount. Additionally, tightening Access Control Lists (ACLs) to prevent any single role from combining `@admin`, `CONFIG`, and `@scripting` privileges is crucial. Disabling `@scripting` entirely is also an option for organizations that do not utilize Lua scripting, as this would neutralize the initial memory leak stage of the exploit.
Organizations should prioritize patching internet-exposed Redis instances and any roles that possess broad access, particularly those combining `CONFIG`, scripting, and stream command capabilities. Rotating any widely shared Redis credentials should also be a part of the immediate security response. This latest vulnerability follows a series of RCE-class Redis flaws disclosed recently, including the RediShell flaw from 2025, underscoring the ongoing need for vigilance in securing this vital infrastructure component.
The next expected step for users is to apply the available patches or implement the recommended mitigation strategies. The ongoing development and deployment of AI-driven bug-hunting tools suggest that such sophisticated vulnerabilities may continue to be discovered, highlighting the dynamic nature of cybersecurity threats and the importance of proactive security measures.