Redis published a security advisory in 2026 covering five vulnerabilities, several rated High (CVSS 7.7). The set includes a use-after-free in the client-unblock flow (CVE-2026-23479), invalid-memory-access issues in the RESTORE command — one in core (CVE-2026-25243) and two in the RedisTimeSeries and RedisBloom modules (CVE-2026-25588, CVE-2026-25589) — and a Lua use-after-free (CVE-2026-23631). The most severe can lead to remote code execution.
There's an important qualifier that changes how you should react: according to the Redis advisory, these are post-authentication issues. An attacker needs authenticated access to the Redis instance before they can trigger them. That's not a reason to relax — it's a reason to think clearly about who and what can reach your Redis in the first place.
Why "Post-Authentication" Is Not Reassuring
The instinct on reading "requires authentication" is to downgrade the risk. In many real deployments, that instinct is wrong, for three reasons.
First, Redis is frequently deployed with no password at all, or a weak shared one, on the assumption that network isolation is enough. If the instance is reachable and unauthenticated, "post-authentication" effectively means "post-connection."
Second, Redis credentials leak the same way every other credential leaks — a committed .env, an over-broad IAM role, a compromised application container. The application that legitimately holds the Redis password is exactly the blast radius an attacker inherits when they compromise it.
Third, the RESTORE command is the vector for three of these CVEs, and RESTORE accepts a serialized payload. Any code path that lets a user influence what gets restored — a poorly scoped admin tool, a migration script that replays external data — widens the attack surface beyond "someone who typed the password."
The Non-Negotiable First Step: Patch
Everything below is defense in depth. It does not replace upgrading. Confirm your running version, then move to a patched build:
# Check what you're actually running (not what the Dockerfile claims)
redis-cli INFO server | grep redis_version
# In a typical container setup, pin to a patched tag and redeploy
# rather than mutating a running instance.
docker pull redis:8.2-bookworm
docker compose up -d --force-recreate redisIf you run managed Redis (ElastiCache, Memorystore, Upstash, Redis Cloud), check your provider's advisory feed — most apply engine patches on a maintenance schedule, but the timing and whether it's automatic varies by provider and version.
Reduce Who Can Authenticate At All
The cheapest risk reduction is shrinking the set of clients that can reach Redis. Redis should almost never be exposed to a public interface.
# redis.conf — bind to private interfaces only, never 0.0.0.0
bind 127.0.0.1 10.0.1.15
protected-mode yes
port 6379
# Require a strong password. Better: use ACL users below.
requirepass <long-random-secret>At the network layer, the Redis port should be reachable only from the specific application subnets that need it. On AWS, that's a security group that references the app's security group rather than a CIDR range:
# Terraform: allow Redis only from the app tier, nothing else
resource "aws_security_group_rule" "redis_from_app" {
type = "ingress"
from_port = 6379
to_port = 6379
protocol = "tcp"
security_group_id = aws_security_group.redis.id
source_security_group_id = aws_security_group.app.id
}Use ACLs to Constrain What an Authenticated Client Can Do
Since these CVEs are triggered by specific commands, Redis 6+ ACLs are directly useful: a client that never needs RESTORE or Lua scripting should not be able to call them. This is least privilege applied to the command surface.
# Application user: data operations only, no dangerous commands
user app_service on >app-strong-password ~app:* \
+@read +@write -@dangerous -restore -eval -evalsha -function -debug
# Disable the default user entirely so it can't be a fallback
user default offThe -restore and -eval exclusions directly remove the command paths behind three of the five CVEs for that user. Most application workloads — GET, SET, HSET, EXPIRE, pub/sub — need none of the flagged commands. Auditing your codebase for actual command usage before writing the ACL is worth the hour it takes.
If you cannot use ACLs yet, rename-command is a blunter tool with a similar effect:
rename-command RESTORE ""
rename-command DEBUG ""Renaming to an empty string disables the command process-wide. Only do this after confirming nothing legitimate depends on it — some backup and migration tooling uses RESTORE.
Verify, Don't Assume
After changes, confirm the constraints actually hold from the perspective of an application client:
# As the constrained user, dangerous commands should be refused
redis-cli -u redis://app_service:app-strong-password@10.0.1.15:6379 \
RESTORE probe 0 "\x00..."
# Expected: (error) NOPERM ... has no permissions to run the 'restore' command
# From outside the allowed subnet, the port should not answer at all
nc -vz redis.internal 6379 # expect a timeout / refused, not a bannerA configuration you haven't tested from the attacker's vantage point is a hypothesis, not a control.
Our Take
The 2026 Redis advisories are a useful forcing function, but the deeper lesson is not specific to these CVEs. Redis has historically been deployed as a trusted internal component, and "trusted internal" quietly became "unauthenticated and reachable" in a lot of environments. Post-authentication RCE bugs are only comforting if your authentication boundary is real.
Our recommended sequence is: patch first, because nothing else substitutes for it; then verify that Redis is bound to private interfaces and firewalled to the app tier; then apply ACLs so a compromised application can't reach RESTORE, EVAL, or DEBUG at all; and finally test each control from outside. Do that, and a future Redis command-surface CVE becomes a routine patch rather than an incident.