Redis Patches Four Code-Execution Bugs After AI Agent Finds Zero-Days
Seven security releases went out on July 23 after researchers used Moonshot AI's Kimi K3 agents to uncover authenticated remote code execution chains in stock Redis builds.
Key points
- Redis shipped seven security updates on July 23 covering versions 6.2.22, 7.4.9, 8.6.4 and 8.8.0.
- Researchers used AI agents to find the flaws and build working authenticated remote code execution chains.
- All four attack chains rely on the RESTORE command; some also need EVAL, XGROUP or the RedisBloom module.
- Fixed versions are Redis 6.2.23, 7.2.15 and 7.4.10.
- The bugs are memory-corruption flaws that Redis says can lead to remote code execution.
Redis, the widely used in-memory database that sits behind countless websites and apps, has patched a set of serious flaws that let a logged-in attacker run their own code on the server.
The fixes landed on July 23 in seven separate security releases. They cover Redis 6.2.22, 7.4.9, 8.6.4 and 8.8.0, which are the stock builds most companies pull from the official channels.
The interesting part is how the bugs were found. Researchers pointed Kimi K3, an AI agent system from Chinese lab Moonshot, at the Redis codebase and asked it to hunt. It produced working proof-of-concept exploits, small test programs that demonstrate an attack really works, for all four versions.
The story was first reported by The Hacker News.
What actually breaks?
These are memory-corruption bugs, meaning flaws in how Redis handles chunks of data in memory. Get the input just wrong enough and the attacker can trick the server into running commands of their choosing. Redis confirms the flaws "may lead to remote code execution", which is the industry's careful way of saying: yes, someone can take over the box.
Every one of the four attack chains needs the RESTORE command, which is normally used to load data back into Redis from a backup. Two of them, targeting the Streams feature, also need EVAL (which runs small scripts inside Redis) and XGROUP (which manages stream consumer groups). The chain against Redis 8.8.0 needs EVAL plus RedisBloom, an official add-on module for probabilistic data structures.
Who is at risk?
An attacker must already be authenticated, meaning they need valid Redis credentials before any of this works. That sounds reassuring until you remember how often Redis instances end up on the public internet with weak passwords, shared credentials, or none at all.
If a criminal already has a foothold inside a company's network, an unpatched Redis server is now a straight route to running code on the underlying host.
Which versions fix it?
| Branch | Vulnerable | Patched |
|---|---|---|
| 6.2.x | 6.2.22 | 6.2.23 |
| 7.2.x | prior releases | 7.2.15 |
| 7.4.x | 7.4.9 | 7.4.10 |
| 8.x | 8.6.4, 8.8.0 | see Redis advisory |
What should administrators do?
Upgrade to the patched versions above as soon as reasonable. If you cannot patch immediately, Redis's access control lists let you strip the RESTORE, EVAL and XGROUP commands from any user account that does not genuinely need them. Removing RESTORE alone breaks all four published exploit chains.
Check that your Redis instances are not reachable from the open internet. Rotate any credentials that have been shared widely or checked into code repositories. Audit which users hold the dangerous commands in their permission set.
Why this one matters beyond Redis
AI agents finding real, exploitable flaws in mature open-source software is not a hypothetical anymore. Kimi K3 did not just flag suspicious code. It wrote working exploits against four separate versions. Defenders should assume attackers are running the same playbook, quietly, against every popular server product they depend on.
