A critical remote code execution vulnerability (CVE-2026-23479) in Redis, introduced in version 7.2.0 over two years ago, has been patched following discovery by an autonomous AI-powered bug-hunting tool. The flaw is a use-after-free bug in Redis’s blocking-client handling code, allowing any authenticated user to execute arbitrary operating system commands on the host server. This is significant because Redis is widely deployed across cloud environments as a caching and data store layer, meaning exposure could lead to full host compromise.

Architect’s Take: Prioritise patching all Redis instances to the May 5 fixed release immediately, paying particular attention to managed Redis services (AWS ElastiCache, Azure Cache for Redis, GCP Memorystore) and self-hosted deployments — check with your vendors for patch availability. In the interim, enforce network segmentation and strict authentication controls to limit which services and users can reach Redis endpoints, reducing the authenticated-user attack surface.

Original advisory: Autonomous AI Tool Finds 2-Year-Old RCE Flaw in Redis (CVE-2026-23479)

A use-after-free vulnerability in Redis (CVE-2026-23479) allows an authenticated user to execute arbitrary operating system commands on the host machine. Present in every stable Redis branch since version 7.2.0, the flaw went undetected for over two years before being discovered by an autonomous AI-powered code analysis tool. Because Redis is widely deployed as a caching and session layer in cloud environments, successful exploitation could lead to full host compromise.

Architect’s Take: Patch Redis to the May 5 release immediately across all environments — prioritise internet-adjacent or multi-tenant deployments. In the interim, enforce strict network segmentation so that only authorised application services can reach Redis, and audit whether any Redis instances permit external or untrusted client authentication.

Original advisory: Autonomous AI Tool Finds 2-Year-Old RCE Flaw in Redis (CVE-2026-23479)

CVE-2025-29923 affects go-redis, a popular Go client library for Redis, where a timeout during the CLIENT SETINFO command at connection establishment can cause responses to be returned out of order. This race condition can result in a client receiving incorrect data, potentially leading to data corruption or unintended application behaviour. Applications using go-redis in Azure or other cloud environments that rely on connection pooling may be silently affected.

Architect’s Take: Audit any workloads using the go-redis library and upgrade to the patched version as soon as possible. Pay particular attention to services with high connection churn or aggressive connection timeouts, as these are most likely to trigger the out-of-order response condition.

Original advisory: CVE-2025-29923 go-redis allows potential out of order responses when CLIENT SETINFO times out during connection establishment