Redis's August 2026 CVEs: A Practical Patching and Hardening Checklist

What shipped

Redis published a security advisory this week covering five CVEs — CVE-2026-23479, CVE-2026-25243, CVE-2026-25588, CVE-2026-25589, and CVE-2026-23631. Several carry a critical severity rating, and the common thread across the writeups is the same warning: internet-facing Redis instances are at meaningful risk of remote code execution if left unpatched.

Redis sits behind cache layers, session stores, and job queues in most of the stacks we run for clients. An RCE-class vulnerability in that position isn't a "patch it next sprint" item — it's a "patch it this week" item. This is what we actually did.

Step 1: Find every Redis instance and its version

Before patching anything, we build an inventory. It's common for a Redis instance running as a sidecar in a lesser-used environment to be forgotten.

# Check the running version on a given host
redis-cli -h <host> -p 6379 INFO server | grep redis_version
 
# For containerized instances, check the image tag directly
docker ps --filter "ancestor=redis" --format "{{.Names}}: {{.Image}}"

For anything managed through infrastructure-as-code, grep the version pin across the repo rather than relying on memory:

grep -rn "redis:" --include="*.yml" --include="*.yaml" --include="Dockerfile" .

Step 2: Patch to a fixed version

Redis's advisory names the patched release lines. Bump the version pin and roll it out through your normal deployment path — this isn't a case for a manual hotfix on a running container.

# Before
FROM redis:7.4.1
 
# After — pin to the patched line named in the advisory
FROM redis:7.4.6

For managed Redis (ElastiCache, MemoryDB, Upstash, and similar), the patch usually ships as a maintenance-window update rather than something you build yourself. Check your provider's changelog for the equivalent minor version bump and schedule the maintenance window explicitly rather than waiting for the default auto-patch cycle — auto-patch windows can lag a critical advisory by weeks.

Step 3: Confirm the instance isn't exposed to begin with

Patching closes the hole, but the advisories are a good prompt to re-verify Redis was never meant to be reachable from the open internet in the first place. A few checks we run on every client Redis instance:

# Should bind to internal interfaces only, never 0.0.0.0 on a public NIC
redis-cli CONFIG GET bind
 
# Protected mode should be yes unless bind + requirepass are both explicitly set
redis-cli CONFIG GET protected-mode
 
# Auth should be required
redis-cli CONFIG GET requirepass

If any of these come back showing an open bind address with no password, that instance needs isolation behind a security group or VPC boundary today, independent of whether it's on a patched version.

Step 4: Restrict dangerous commands with ACLs

Even authenticated, a compromised application credential shouldn't be able to run FLUSHALL, CONFIG SET, or DEBUG. Redis ACLs let you scope what a given user can do:

# Create an application user that can read/write keys but not touch admin commands
ACL SETUSER app_user on >strong-password-here ~app:* +@read +@write -@admin -@dangerous

We apply this pattern by default now — not just in response to this advisory, but as standing practice for any new Redis deployment.

Step 5: Check exposure, don't assume

If you run Redis anywhere with a public IP — even temporarily, even in a dev environment — treat this advisory as a signal to check exposure now rather than later:

# From an external host, confirm the port isn't reachable
nc -zv <public-ip> 6379

A closed connection is what you want to see. If it connects, that's an instance that needs to be pulled behind a firewall immediately, patched version or not.

Patch first, on every environment, including staging and dev — attackers don't check environment names
Re-verify bind, protected-mode, and requirepass on every instance regardless of patch status; a patched-but-exposed instance is still exposed
Move toward ACL-scoped application users as the default, not just for the credential involved in an incident
If you're on a managed Redis offering, don't assume auto-patching covers you on the advisory's timeline — check explicitly

Takeaway

None of the individual fixes here are exotic — version bumps, bind checks, and ACL scoping are all standard database hygiene. What this advisory is really testing is whether that hygiene is actually in place across every Redis instance you run, not just the ones you remember. We're using this week's advisory as the trigger to re-audit every client Redis deployment, not just the ones directly implicated.

Source: Redis security advisory (redis.io/blog)