Redis RESTORE RCEs: Patch the Branch, Then Take RESTORE Away

On July 23, Redis published seven security releases: 6.2.23, 7.2.15, 7.4.10, 8.2.8, 8.4.5, 8.6.5 and 8.8.1. They came after researchers published proofs of concept for authenticated remote code execution against stock Redis 6.2.22, 7.4.9, 8.6.4 and 8.8.0. The Hacker News reports that the researchers say Kimi K3 agents found the bugs. The AI angle will get the headlines; I care more that every published chain needs RESTORE. Application code rarely has a reason to call that command, yet the default Redis user is allowed to run it.

What actually got fixed#

Two bug classes, both reachable through RESTORE:

• Streams shared-NACK. The 8.6.5 release note describes a crafted stream RESTORE payload that makes two consumers share the same NACK, causing a use-after-free that may lead to remote code execution. Per The Hacker News, removing both consumers then frees the same pending-entry record twice.
• RedisBloom and TDigest. Crafted RESTORE payloads can trigger out-of-bounds writes. According to The Hacker News, the TDigest loader sized its allocation from one serialized value but trusted a separate capacity field that the attacker controls.

What each branch fixes:

• 6.2.23, 7.2.15 and 7.4.10 fix the Streams issue.
• 8.2.8, 8.4.5 and 8.6.5 fix both issues.
• 8.8.1 fixes the RedisBloom and TDigest loaders. The Streams guard was already in 8.8.0.

The Streams chains also need EVAL and XGROUP. The 8.8.0 chain needs EVAL plus the bundled RedisBloom module. Every chain requires an authenticated connection. As of July 24, neither Redis's release notes nor the public PoC repositories The Hacker News reviewed reported in-the-wild exploitation. The release notes list no CVE or CVSS score for the new bugs.

"Recently patched" is not a version#

What bothers me most is the May updates. Two PoC targets, 6.2.22 and 7.4.9, were the May security releases Redis told users to install, and they did not include the shared-NACK ownership guard. The Hacker News also found that the 8.6.4 release notes cite the relevant fix, but the tagged 8.6.4 source lacks the duplicate-ownership check.

A team that patched in May and closed the ticket needs to upgrade again. Track the exact version each instance is running, from INFO server, instead of a status field that says "patched". Production, staging, compose files and CI containers drift separately.

Authenticated is not a mitigation#

Teams routinely deprioritize authenticated bugs. With Redis that reasoning is weak. The ACL documentation shows that a freshly started server with the default configuration has a single user, default, defined as on nopass ~* &* +@all. Every new connection is authenticated automatically and can call every command.

A password helps less than it seems: requirepass just sets a password on that same default user, which still has +@all. That credential usually sits in every app server's environment, CI secrets and worker connection strings. On an unpatched instance, one leaked credential, say from an environment dump, is a path to code execution on the Redis host.

The cheap fix: take RESTORE away#

The Hacker News says to upgrade and, until then, to revoke RESTORE from accounts that do not strictly need it and block untrusted network access. Restricting RESTORE alone cuts off both disclosed paths.

ACL SETUSER app -restore
ACL GETUSER app

Before rolling it out, from the docs:

• RESTORE is listed under both @dangerous and @keyspace. Removing @dangerous would take RESTORE away, but it also removes INFO, KEYS, CLIENT, SORT and CONFIG, so test that first.
• Persist the change. With an external ACL file, run ACL SAVE, because CONFIG REWRITE does not trigger it. With users defined in redis.conf, use CONFIG REWRITE.
• Give migration or backup tooling its own user that keeps RESTORE.

EVAL is the other command the chains share. Plenty of libraries use Lua for locks, rate limiting and job queues, so removing EVAL is rarely realistic. Removing RESTORE usually is.

The AI part, with the caveats attached#

Chaofan Shou said on X that Kimi K3 agents found 19 Redis zero-days in about 90 minutes, and that another run produced the 8.8.0 exploit in 27 minutes. The Hacker News is explicit that the counts, the timings and how independently the agents worked are all self-reported. Redis's public record confirms the flaws and the fixes, not the numbers. This disclosure also follows another AI-discovered Redis RCE that was patched in May.

I run coding agents daily and will stay skeptical of those figures until someone reproduces them. They do not need to be accurate to change how I triage. "Requires authentication and a specific command" used to mean "nobody will bother". This time working exploits were public before the fixed releases shipped.

What I'm doing about it#

Redis is part of the stacks I work with, so this is my Monday list:

1. Inventory every instance's running version, including dev and CI containers, and move each to its branch's fixed release.
2. Replace any application connection that uses default with a named user, and add -restore to that user.
3. Confirm Redis ports are reachable only from the hosts that need them.
4. Add a pipeline check that fails when an image pins a Redis version below its branch's fixed release.

What changed is the order: exploit first, patch second, and an agent claimed as the hunter.