TL;DR

CVE-2025-49844, nicknamed RediShell. CVSS 10.0. A use-after-free bug in the Lua binding of Redis that allows escaping the sandbox and reaching remote code execution on the host. Exploitation requires authenticated access to Redis. Many environments still expose Redis or use weak credentials. Minimal updates to stay secure: 8.2.2, 8.0.4, 7.4.6, 7.2.11, and 6.2.20 as per the family. If you cannot update now, block scripting via ACL and restrict the network.

Phase 1. What is the issue with this CVE

What is RediShell

The issue is a use-after-free in the integration of Redis with Lua. An attacker with authenticated access sends a specially crafted Lua script, manipulates the garbage collector, escapes the sandbox, and executes arbitrary code. In practice, this becomes a reverse shell originating from the redis-server process and opens the way for key exfiltration and lateral movement. Critical classification, CVSS 10.0.

Why is it special

This bug has existed for about 13 years in the code that supports scripting in Lua. The impact is broad because Lua is present in modern versions of Redis and scripting is widely used for atomic operations on the server side. Exploitation requires authentication, but exposure of Redis is a known and dangerous phenomenon. Recurring estimates mention hundreds of thousands of accessible instances on the internet and tens of thousands without authentication. The combination of misconfiguration and late patching turns what would be a technical detail into a real incident.

Recent history

In the last 12 months, Redis has received other relevant notices reinforcing the need for continuous discipline in patching and hardening, especially for everything that touches Lua. The message is simple: failures in scripting and service exposure are predictable, just minimize the surface and keep versions up to date.

Simple root cause diagram

See more details of the diagram here: https://www.mermaidchart.com/d/331349a9-e715-4a86-afc4-6dbec832bfca

Phase 2. What does it affect and exploitation scenarios

Affected versions and fixes

Affects all versions supporting Lua. Fixed in:

• Series 8. 8.2.2 and 8.0.4;

• Series 7. 7.4.6 and 7.2.11;

• Maintained Series 6. 6.2.20

Recommendation: Update to at least the above versions and perform a controlled rollout. Subscribe to the Redis image without CVEs at quor.dev.

Pre-requisites and attack surface

• Requires authenticated access to Redis;

• The risk increases when there is exposure in the network without a control layer, when protected-mode is disabled, or when authentication is weak;

• In Kubernetes, Redis accessible without NetworkPolicy or without egress and ingress controls can be exploited from compromised workloads in the same VPC or cluster.

Practical attack scenarios in Kubernetes

1. Compromised application in the cluster with environment variables containing Redis credentials. The attacker uses the app's account to send EVAL and triggers the bug. Expected result: remote execution on the host, reading volumes, and escaping the pod's scope.

2. Redis exposed via LoadBalancer type Service without an authorized IP list. Weak or leaked credentials. The attacker authenticates and executes the exploit.

3. CI pipeline with a job that has direct access to Redis in an internal network. Credentials in the pipeline's secrets.

4. Compromise of the runner becomes a pivot to Redis and then to the host of the node where Redis runs.
   
   
   

Tactics that really show up

• Reverse shell from the redis-server process;

• Exfiltration of secrets stored on the host, SSH keys, IAM tokens, and certificates;

• Lateral movement in the VPC and scanning of nearby targets;

• Deployment of crypto-miners on less monitored nodes.

Summary risk matrix

Phase 3. How to fix?

Update now

• Series 8. 8.2.2, 8.0.4;

• Series 7. 7.4.6, 7.2.11;

• Maintained Series 6. 6.2.20;

• Redis Stack and enterprise editions as per your vendor.

If you use Docker, prefer exact tag or digest of the fixed version. Subscribe to the Redis image without CVEs at quor.dev.

Other options, if the update cannot be made urgently.

Harden access on Redis itself with ACL

Block scripting for all users who do not need this permission. Simple example of creating an app user without scripting.

NetworkPolicy for Redis in Kubernetes

Only allows authorized client pods. Adjust selectors according to your labels.

Admission Policies with CEL

The native validation with ValidatingAdmissionPolicy in CEL allows imposing requirements directly on the API server, without external dependencies. With CEL, it is possible to declare objective conditions to deny objects that do not meet minimum security standards, such as requiring that each image is pinned by digest, enforcing runAsNonRoot true, denying privileged and allowPrivilegeEscalation, and ensuring that all capabilities are removed. This approach standardizes controls across clusters, reduces the operational surface, and integrates naturally with GitOps flows.

Native ValidatingAdmissionPolicy in Kubernetes with CEL

The direct solution with Quor.dev

Framework and application images attract attention, but the entire ecosystem needs the same level of care. Redis is critical infrastructure, and each of these layers accumulates CVEs quickly.

The Near-Zero CVE images from Quor.dev reduce the attack surface, offer SBOM and verified provenance that facilitates continuous auditing. This does not replace the patch for the application but eliminates base noise and accelerates incident response.

The point is: security is not just about the framework your team chooses. The entire stack of tools deserves attention, and Redis is on that list with priority. Quor.dev provides this with just one redeploy.

Final checklist for your team

• Confirm Redis version in all environments and update to at least 8.2.2, 8.0.4, 7.4.6, 7.2.11 or 6.2.20 as per the family;

• Pin images by digest. Avoid aliases like 8.2-alpine. Prefer exact tags;

• Apply ACL denying @scripting and removing EVAL and EVALSHA from any user that does not need it;

• Create or harden NetworkPolicies. Allow only authorized pods;

• Apply admission policies. Mandatory digest and minimum privileges;

• Enable alerts in Loki for EVAL, EVALSHA, SCRIPT LOAD, and Lua crashes;

• Strengthen authentication, enable protected-mode, and limit network surfaces.

Compliance & controls

• CIS Kubernetes Benchmark. NetworkPolicy controls, admission policies, and minimum privileges in Pods;

• NIST SSDF and NIST 800-53. Continuous update practices, software inventory, SBOM, and hardening;

• PCI DSS. Reduction of surface and network segmentation. Images with SBOM and Zero-CVE facilitate evidence and response.

References

• Official vendor advisory with fixed versions, IoCs, and mitigations;

• Release notes with fixed series, including 6.2.20;

• Independent technical analyses of the exploitation chain and the timeline;

• Public pages of official images for tag and digest verification;

• DarkReading - https://www.darkreading.com/cloud-security/patch-now-redishell-redis-rce.
  
  
  

Want to understand how to build a container ecosystem without CVEs? Discover at quor.dev