Security update: Redis response to the Kimi K3 vulnerability claims

Last week, researchers posted on X that they had used the Kimi K3 AI model to identify vulnerabilities in Redis, including a claim involving 19 zero day vulnerabilities.

We became aware of this research through the public posts and immediately reviewed the available technical information. The materials published to date demonstrate three distinct issues:

• A Redis Streams shared-NACK use-after-free
• A RedisBloom TDigest out-of-bounds write
• A RedisBloom TopK RDB loader wild-free

These issues had already been reported to Redis through our bug bounty program by researchers who do not appear to be affiliated with those behind the X posts. Redis did not receive a report from the researchers behind the posts, and the publicly disclosed issues were duplicates of findings already known to us.

We expedited open source fixes for two of the three issues, publishing Redis 8.8.1 and updates for six older maintained branches, along with corresponding RedisBloom security releases. The TopK issue, which is separate from the other two vulnerabilities, has been remediated in Redis Software and Redis Cloud. Deployment to other managed Redis environments is nearing completion, and an open source update will be published soon.

The public materials currently document three vulnerabilities. We have not seen a complete list or supporting technical information for the remaining claimed issues, but we will review any additional findings that become available.

We encourage open-source users to install the latest Redis and RedisBloom security releases and apply the forthcoming update when available. We remain committed to responding quickly to security research and communicating clearly with our customers and the Redis community.

More broadly, following established security practices significantly reduces exposure to many common attack paths. Redis instances should use strong authentication, have access tightly restricted, and be deployed within trusted networks rather than exposed directly to the public internet. Additional guidance is available in our recommended security practices. These measures complement, but do not replace, timely patching.