Redis patched a two-year-old use-after-free bug in its blocking-client code that could let an authenticated user run operating system commands on the host, after an autonomous AI security tool uncovered the flaw in the database software.
KEY FACTS
- CVE The bug is tracked as CVE-2026-23479.
- Scope It affected Redis 7.2.0 through 8.6.2 before the May 5 fixes.
- Risk NVD rates the issue 8.8 under CVSS 3.1, while Redis lists it at 7.7 under CVSS 4.0.
- Exposure Wiz said Redis is widely deployed in cloud environments and many instances run without a password.
The flaw was reported by Team Xint Code, and a technical analysis outlined how the bug could be turned into remote code execution. Redis said there was no evidence of exploitation in its own or customer environments.
The issue was introduced in Redis 7.2.0 and remained in every stable branch until the May 5 updates, where fixes landed for 7.2.14, 7.4.9, 8.2.6, 8.4.3 and 8.6.3. The report said the bug lived in unblockClientOnKey() in blocked.c, where a client pointer could be reused after the client had been freed.
According to the disclosure, the exploit chain began with a heap address leak, then used client memory grooming and a blocked stream command to reclaim freed memory with a fake client structure. It then used Redis memory accounting to overwrite a function pointer and redirect strcasecmp() to system().
The full chain required an authenticated session with CONFIG SET, EVAL, stream commands and basic read and write access. The advisory said that in many deployments the default user already has those privileges, and that partial RELRO in the official Docker image leaves the GOT writable at runtime.
WHY IT MATTERS
Redis is widely used in cloud environments, so a flaw that can turn routine database access into command execution can raise the impact of exposed or overprivileged deployments. Operators that cannot patch immediately are being told to restrict internet exposure, tighten ACLs and remove unnecessary scripting access.