What researchers published and what Redis shipped on July 23
On July 23, Redis released seven security updates after researchers published authenticated remote‑code‑execution (RCE) proofs of concept against stock Redis 6.2.22, 7.4.9, 8.6.4, and 8.8.0. The published proofs target two distinct memory‑corruption chains; Redis's July fixes map to different branches and sub‑fixes across the 6.x, 7.x, and 8.x lines.
How both exploit paths use RESTORE (and additional requirements)
All four published exploit chains require the RESTORE command. The Streams chains also require EVAL and XGROUP; the Redis 8.8.0 chain additionally requires EVAL and the bundled RedisBloom module. Redis says the underlying memory flaws may lead to remote code execution. The short, concrete mitigation published alongside the fixes is straightforward: upgrade to the fixed release for the deployed branch. Until that upgrade, revoke RESTORE from accounts that do not strictly need it and block untrusted network access — restricting RESTORE cuts off both disclosed paths.
Streams shared‑NACK chain: double‑free to system()
The first path is a shared‑ownership bug in Redis Streams. A corrupt RDB object can make two consumers point to the same pending‑entry record, internally represented by a streamNACK. Removing the first consumer frees the object and leaves the second holding a dangling pointer; removing the second consumer then frees the same object again. The published script is designed to turn that double‑free into arbitrary memory access and ultimately invoke system().
Notably, Redis 8.6.4's release notes cite PR #15081, but a source review by The Hacker News found the tagged 8.6.4 source lacked the duplicate‑ownership check added by that change; the guard appears in Redis 8.6.5, released July 23. Redis 6.2.23, 7.2.15, and 7.4.10 were listed as fixes for the Streams shared‑NACK use‑after‑free on the branches that needed it.
RedisBloom TDigest chain: out‑of‑bounds write to system()
The second path sits in the RedisBloom TDigest RDB loader. The loader allocated centroid arrays from one serialized compression value but 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 published Redis 8.8.0 script is designed to turn that mismatch into read and write primitives, leak Redis and libc addresses, poison a database hash function, and call system().
Redis's July fixes require the loaded TDigest capacity to match the allocation derived from the compression value and also bound the merged and unmerged node counters before reading the arrays. Redis 8.8.1 fixes the RedisBloom and TDigest loaders; earlier 8.8.0 contained the Streams guard already but needed the loader corrections.
Release mapping, CVE status, and the vendor record
Redis's July 23 releases span multiple branches: Redis 6.2.23, 7.2.15, and 7.4.10 address the Streams shared‑NACK issue on those branches; Redis 8.2.8, 8.4.5, and 8.6.5 fix both the Streams issue and the RedisBloom/TDigest out‑of‑bounds writes; Redis 8.8.1 addresses the RedisBloom and TDigest loaders while Streams protections were already present in 8.8.0.
The public repository noted that the Streams issue is part of a CVE‑2026‑25589 "incomplete fix family," but Redis maps CVE‑2026‑25589 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. Searches by The Hacker News as of July 24 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.
Two of the targeted PoC destinations — Redis 6.2.22 and 7.4.9 — were the May security updates Redis had told users to install, but those releases did not include the shared‑NACK ownership guard; by July they needed another update. The advisory language is blunt: check the exact branch version, not whether Redis was merely "recently patched."
What this means for technologists, procurement leaders, and adversaries
- Technologists and security teams: The immediate action is branch‑aware patching and temporary privilege restriction — upgrade to the fixed release for your deployed branch, revoke RESTORE where it is not required, and block untrusted network access. These steps match the remedies published alongside the fixes.
- Procurement and operations leaders: The incident underscores the need to verify exact package and branch versions during supply‑chain and patching cycles; Redis 6.2.22 and 7.4.9 were previously recommended but lacked the later guard.
- Adversaries and threat actors: The published PoCs are authenticated‑RCE chains that demonstrate paths from RESTORE to system() when the additional prerequisites (EVAL, XGROUP, RedisBloom where applicable) are present. As of July 24, neither Redis's July 23 release notes nor the public PoC repositories reviewed reported in‑the‑wild exploitation.
There is an extra note on attribution and automation: Chaofan Shou posted that Kimi K3 agents found 19 Redis zero‑days in about 90 minutes and that another run produced the Redis 8.8.0 exploit in 27 minutes. Those counts, timings, and the claimed degree of autonomy are self‑reported; Redis's public record confirms the flaws and fixes but does not validate the claimed zero‑day count or how independently the agents worked.
For now, the record is firm on the technical pathways, the versions affected, and the immediate mitigations: RESTORE is the pivot, Streams and RedisBloom provide separate memory‑corruption routes, fixed releases are available for each maintained branch, and temporary privilege removal will block the disclosed exploits. As of July 24, 2026, no public report showed in‑the‑wild exploitation; operators should verify exact branch versions and deploy the branch‑specific fixes without delay.
Source: The Hacker News — Kimi K3 Agents Found Redis Zero‑Days and Built RCE Exploit
