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; the Streams chains also need EVAL and XGROUP, while the 8.8.0 chain needs EVAL plus RedisBloom.
- 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 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, covering the stock builds that most companies pull from official channels: 6.2.22, 7.4.9, 8.6.4 and 8.8.0.
The method matters as much as the result. Researchers pointed Kimi K3, an AI agent system from Chinese lab Moonshot, at the Redis codebase. It came back with 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.
As an adjacent data point: our report on an AI scanner that turned up eight serious bugs in NodeBB Forum Software published the very next day, July 24, suggesting this is no longer a one-off research trick.
What actually breaks?
These are memory-corruption bugs, meaning flaws in how Redis handles chunks of data in memory. Get the input wrong and an attacker can trick the server into running commands of their choosing. Redis confirms the flaws "may lead to remote code execution", which is the careful way of saying someone can take over the box.
Every attack chain needs the RESTORE command, normally used to reload data from a backup. The two chains targeting the Streams feature additionally require EVAL (which runs small scripts inside Redis) and XGROUP (which manages stream consumer groups). The chain against 8.8.0 needs EVAL alongside RedisBloom, an official add-on for probabilistic data structures.
Who is at risk?
An attacker must be authenticated first, meaning they need valid Redis credentials before any of this works. That's cold comfort given how often Redis instances end up on the public internet with weak or default passwords. If a criminal already has a foothold inside a network, an unpatched Redis server is 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. Can't patch immediately? Redis's access control lists let you strip RESTORE from any account that doesn't need it. Removing RESTORE breaks all four published exploit chains. Removing EVAL limits two of them further.
Confirm your Redis instances aren't reachable from the open internet. Rotate credentials that have been shared widely or checked into code repositories.
Should you worry about AI-assisted vulnerability hunting?
Kimi K3 didn't just flag suspicious code patterns. It built working exploits against four separate software versions. Defenders should assume attackers are running the same approach, quietly, against every popular server product they depend on. That shift is already underway, and Redis won't be the last mature project to find out this way.
