Redis patches critical remote code execution bug after 13 years (CVE-2025-49844) — what to do now, and how to harden for the future

What happened. Redis has disclosed and fixed CVE-2025-49844, a critical (CVSS 10.0) vulnerability in the Lua scripting engine that can lead to remote code execution (RCE). An authenticated user can craft a Lua script that manipulates the garbage collector, triggers a use-after-free, and potentially executes arbitrary code.

Redis Cloud customers are already patched. If you self-manage Redis, you must upgrade.

---

Who’s affected and what versions fix it

• Redis OSS / Community / Stack (with Lua scripting):
  8.2.2+, 8.0.4+, 7.4.6+, 7.2.11+ (Stack: 7.4.0-v7+, 7.2.0-v19+)
• Redis Software (commercial, self-managed):
  7.22.2-20+, 7.8.6-207+, 7.4.6-272+, 7.2.4-138+, 6.4.2-131+

Note: Redis corrected earlier guidance; if you upgraded to 7.22.2-12 or 7.22.2-14, you must move to 7.22.2-20 or later.

---

10-minute action plan (self-managed)

1) Identify your version

redis-server --version           # or:
redis-cli INFO server | grep redis_version
Code language: PHP (php)

2) Patch

• Linux packages: install from the official Redis repo or your vendor once fixed builds land.
• Containers/Kubernetes: pull the updated image tag, roll the Deployment/StatefulSet.
• Redis Software: apply the listed fixed build.

3) If you cannot patch today — apply temporary mitigations

• Block Lua scripting for default users (Redis ≥6, ACLs): ACL SETUSER default -@scripting (Removes EVAL/EVALSHA; review whether your workloads need scripting and grant it only to a dedicated, least-privileged user.)
• Legacy configs (where ACLs aren’t feasible): rename script commands to disable them: rename-command EVAL "" rename-command EVALSHA ""
• Reduce exposure immediately:
  • Ensure protected-mode yes and a bind to trusted interfaces only: protected-mode yes bind 127.0.0.1 ::1 10.0.0.0/24
  • Enforce AUTH/ACL and TLS where available.
  • Firewall Redis to app subnets only (e.g., security groups, iptables/ufw, or Kubernetes NetworkPolicies).

These mitigations don’t remove the bug; they reduce the blast radius until you can upgrade.

---

How to check for signs of exploitation

Redis reports no evidence of exploitation in Redis Cloud, but you should still look for anomalies:

• Unexpected access paths: new/unknown clients, ingress from unusual IPs/VPCs.
• Script usage out of pattern: spikes in EVAL, EVALSHA, or unexpected stored functions/scripts.
• Crashes from Lua: Redis server crashes with backtraces pointing at the Lua engine.
• Weird child processes or file changes by the redis user; unexplained egress traffic from the Redis host/pod.
• Configuration/data tampering: surprising edits under the directories that host RDB/AOF/configs.

Quick telemetry to review

• SLOWLOG for unusual heavy script calls: SLOWLOG GET 128
• Keyspace/command auditing (if you emit logs/metrics) for EVAL*, FUNCTION, or large outbound payloads.
• In K8s, check pod logs, ebpf/XDR detections, and egress deny-list hits.

If you suspect compromise: isolate, forensic-image the host/pod, rotate secrets, and rebuild from known-good images after patching.

---

Strengthen your Redis security posture (beyond this CVE)

Think in layers. RCE bugs are rare but impactful—good defenses assume a future bug and limit damage.

1) Identity & least privilege

• Use ACLs. Create dedicated users for apps with only the commands they require (e.g., disallow @scripting unless strictly needed). ACL SETUSER app on >strongpass ~* +GET +SET -@scripting
• Avoid sharing the default user beyond maintenance.

2) Network containment

• Never expose Redis directly to the internet. Bind to loopback/VPC addresses; restrict with firewalls/security groups.
• In Kubernetes: apply NetworkPolicies so only the app namespace/service account can reach the Redis Service/Pod.

3) Configuration hygiene

• protected-mode yes, strong AUTH/ACL, TLS (stunnel or built-in TLS).
• Consider renaming dangerous commands you never use (e.g., FLUSHALL, CONFIG, EVAL where applicable).
• Run Redis as a non-root user; apply read-only FS and seccomp/AppArmor profiles in containers.

4) Observability & response

• Centralize Redis logs, auth failures, ACL denials, and command metrics.
• Alert on EVAL, EVALSHA, FUNCTION, or sudden latency spikes that could indicate misuse.
• Keep SLOWLOG and RDB/AOF snapshots monitored for unexpected changes.

5) Patch discipline

• Track upstream advisories and subscribe to vendor notifications.
• Run a pre-prod Redis cluster for canary upgrades; automate drift checks (image digests, package versions).

---

FAQ

Is this exploitable without credentials?
By design, the bug requires authenticated access. In practice, many incidents arise because Redis is exposed without auth, uses default configs, or grants users @scripting unnecessarily—turning an “authenticated” bug into a trivial one. Fix exposure and ACLs now.

Can I just disable Lua and be done?
Disabling/renaming EVAL/EVALSHA (or removing @scripting) is a temporary mitigation. Some workloads depend on scripting (or Redis Functions). Upgrade to a fixed version and then re-enable only if needed—under tight ACLs.

Which branches are actually fixed?
OSS/CE/Stack: 8.2.2+, 8.0.4+, 7.4.6+, 7.2.11+.
Redis Software: 7.22.2-20+, 7.8.6-207+, 7.4.6-272+, 7.2.4-138+, 6.4.2-131+.
If you’re on 7.22.2-12 or -14, update again to -20 or newer.

What should I do on Kubernetes?
Update the image tag to a fixed build, roll your StatefulSet, enforce NetworkPolicies, set a PodSecurityContext (no root), and mount configs as read-only. Consider an admission policy that blocks images without fixed CVEs.

---

Bottom line

1. Patch to a fixed release.
2. If you can’t yet, disable scripting, lock down network access, and enforce ACL/TLS.
3. Add monitoring for script usage and Lua-related crashes.
4. Keep these controls—because the best defense against the next bug is least privilege + no exposure + fast patching.