Redis shipped seven security releases on July 23 after researchers published authenticated RCE PoCs for stock Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0.
All four chains require RESTORE. The Streams chains also need EVAL and XGROUP; the 8.8.0 chain needs EVAL and the bundled RedisBloom module. Redis says the underlying memory flaws may lead to remote code execution.
Redis 6.2.23, 7.2.15, and 7.4.10 fix the Streams shared-NACK use-after-free; Redis 8.2.8, 8.4.5, and 8.6.5 fix both the Streams issue and the RedisBloom and TDigest out-of-bounds writes; Redis 8.8.1 fixes the RedisBloom and TDigest loaders, while the Streams guard was already present in Redis 8.8.0.
Two PoC targets, Redis 6.2.22 and 7.4.9, were the May security updates Redis told users to install, but those releases did not include the shared-NACK ownership guard.
Upgrade to the fixed release for the deployed branch. Until then, revoke RESTORE from accounts that do not strictly need it and block untrusted network access. Restricting RESTORE cuts off both disclosed paths.
Neither Redis's July 23 release notes nor the public PoC repositories reviewed reported in-the-wild exploitation as of July 24, 2026.
Two Paths Through RESTORE
The Redis Streams path is a shared-ownership bug. A corrupt RDB object can make two consumers point to the same pending-entry record, so removing both consumers frees the same object twice.
The published script is designed to turn the resulting memory corruption into arbitrary memory access and ultimately invoke system().
The RedisBloom path is an out-of-bounds write in the TDigest RDB loader. The loader allocated memory from one serialized value but trusted a separate attacker-controlled capacity field when deciding how much data to load.
The Redis 8.8.0 script is designed to turn that mismatch into read and write primitives, leak Redis and libc addresses, and call system().
The Streams Shared-NACK Chain
The first path is in Redis Streams. A corrupt RDB object can make two consumers point to the same pending-entry record, represented internally by a streamNACK. Removing the first consumer frees the object and leaves the second holding a dangling pointer. The scripts then remove the second consumer too. One chunk, two frees.
Redis 8.6.4's release notes cite PR #15081. But a source review by The Hacker News found that the tagged 8.6.4 source lacks the duplicate-ownership check added by that change. The guard appears in Redis 8.6.5, released on July 23.
The published Redis 8.6.4 script is designed to turn the double-free into arbitrary memory access, then poison a database hash function so a crafted GET invokes system(). It restores the pointer and checks whether Redis still responds.
The RedisBloom TDigest Chain
The second path sits in the RedisBloom TDigest RDB loader. It allocated its centroid arrays from a serialized compression value, then trusted a separate attacker-controlled capacity field when deciding how many nodes could be loaded. A small real allocation paired with inflated metadata produces an out-of-bounds write.
The Redis 8.8.0 script is designed to turn the write into read and write primitives, leak Redis and libc addresses, and poison a database hash function so a crafted GET calls system(). A separate proof of concept published the same root cause and an authenticated RCE chain against Redis 8.8.0.
Redis's July fix requires the loaded TDigest capacity to match the allocation derived from the compression value. It also bounds the merged and unmerged node counters before reading the arrays.
Seven Releases, No New CVE Records
The repository calls the Streams issue part of a CVE-2026-25589 "incomplete fix family," but Redis maps that CVE to RedisBloom memory corruption during RESTORE, not the Streams shared-NACK flaw. Redis's July release notes list no CVE or CVSS score for either new bug class.
As of July 24, searches by The Hacker News found no separate NVD record for the July shared-NACK or TDigest findings. NVD still listed the May records for CVE-2026-25243 and CVE-2026-25589. A search of CISA's Known Exploited Vulnerabilities catalog returned no entry for either identifier.
The disclosure follows another AI-discovered Redis RCE flaw patched in May. Bera Buddies describes itself as "AI Agent Research." Chaofan Shou said on X that Kimi K3 agents found 19 Redis zero-days in about 90 minutes, and said another run produced the Redis 8.8.0 exploit in 27 minutes.
Those counts, timings, and the claimed degree of autonomy remain self-reported. Redis's public record confirms the flaws and fixes. It does not validate the claimed zero-day count or how independently the agents worked.
Redis 6.2.22 and 7.4.9 were the May destination. By July, both needed another update. Check the exact branch version, not whether Redis was merely "recently patched."
Found this article interesting? Follow us on Google News, Twitter and LinkedIn to read more exclusive content we post.