RediShell in Redis

TL;DR

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

Phase 1. What is the issue in this CVE

What is RediShell

The issue is a use-after-free vulnerability 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 spawning from the redis-server process, paving the way for key exfiltration and lateral movement. Critical classification, CVSS 10.0.

Why it is special

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

Recent History

Over the last 12 months, Redis has already received other relevant advisories that reinforce the need for continuous discipline in patching and hardening, especially for everything touching Lua. The message is simple: failures in scripting and service exposure are predictable; you just need to minimize the attack 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 it affects and exploitation scenarios

Affected versions and fixes

Affects all versions with Lua support. Fixed in:

• 8.x Series: 8.2.2 and 8.0.4;

• 7.x Series: 7.4.6 and 7.2.11;

• Maintained 6.x Series: 6.2.20

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

Prerequisites and attack surface

• Requires authenticated access to Redis;

• Risk spikes when there is network exposure without a control layer, when protected-mode is disabled, or when authentication is weak;

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

Practical attack scenarios in Kubernetes

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

2. Redis exposed via a LoadBalancer Service without an IP allowlist. Weak or leaked credentials. The attacker authenticates and runs the exploit,

3. A CI pipeline with a job that has direct network access to Redis in an internal network, with credentials stored in pipeline secrets,

4. Compromising the runner acts as a pivot to Redis and then to the node host where Redis is running.
   
   

Tactics that actually appear

• Reverse shell from the redis-server process;

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

• Lateral movement within the VPC and scanning nearby targets;

• Deploying crypto-miners on less-monitored nodes.
  
  

Risk Matrix Summary

Phase 3. How to fix?

Update now

• 8.x Series: 8.2.2, 8.0.4;

• 7.x Series: 7.4.6, 7.2.11;

• Maintained 6.x Series: 6.2.20;

• Redis Stack and enterprise editions depending on your provider.

If you use Docker, prefer an exact tag or digest of the fixed version. Subscribe to the CVE-free Redis image at quor.dev.

Other options if updating cannot be done as an emergency.

Harden access within Redis using ACL

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

ACL SETUSER app reset
ACL SETUSER app on >senha_super_forte ~* +@all -@scripting -eval -evalsha
ACL SAVE
ACL LIST

NetworkPolicy for Redis in Kubernetes

Allows only authorized client pods. Adjust selectors according to your labels.

apiVersion: networking.k8s.io/v1
kind: NetworkPolicy
metadata:
  name: redis-allow-only-apps
  namespace: data
spec:
  podSelector:
    matchLabels:
      app: redis
  policyTypes:
    - Ingress
    - Egress
  ingress:
    - from:
        - namespaceSelector:
            matchLabels:
              name: apps
          podSelector:
            matchLabels:
              role: api
      ports:
        - protocol: TCP
          port: 6379
  egress:
    - to:
        - ipBlock:
            cidr: 10.0.0.0/8
      ports:
        - protocol: TCP
          port: 53
    - to:
        - namespaceSelector:
            matchLabels:
              name: observability
      ports:
        - protocol: TCP
          port: 3100

Admission Policies with CEL

Native validation with ValidatingAdmissionPolicy in CEL allows enforcing requirements directly on the API server, without external dependencies. With CEL, you can declare objective conditions to reject objects that do not meet minimum security standards, such as requiring every image to be pinned by digest, forcing runAsNonRoot to be true, denying privileged and allowPrivilegeEscalation, and ensuring that all capabilities are dropped. This approach standardizes controls across clusters, reduces the operational surface, and integrates naturally with GitOps workflows.

Native ValidatingAdmissionPolicy in Kubernetes with CEL

apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicy
metadata:
  name: require-digest-and-min-privs
spec:
  matchConstraints:
    resourceRules:
      - apiGroups: [""]
        apiVersions: ["v1"]
        operations: ["CREATE", "UPDATE"]
        resources: ["pods"]
  validations:
    - expression: "has(object.spec.containers) && object.spec.containers.all(c, c.image.matches('.*@sha256:.*'))"
      message: "imagem deve usar digest"
    - expression: "has(object.spec.securityContext) && object.spec.securityContext.runAsNonRoot == true"
      message: "pods devem rodar como não root"
    - expression: |
        object.spec.containers.all(c,
          has(c.securityContext) &&
          c.securityContext.privileged != true &&
          c.securityContext.allowPrivilegeEscalation != true &&
          ((has(c.securityContext.capabilities) && has(c.securityContext.capabilities.drop) &&
            c.securityContext.capabilities.drop.exists(cap, cap == 'ALL')) ||
           !has(c.securityContext.capabilities)))
      message: "containers não podem ser privilegiados, devem negar escalada e derrubar todas as capabilities"
---
apiVersion: admissionregistration.k8s.io/v1
kind: ValidatingAdmissionPolicyBinding
metadata:
  name: require-digest-and-min-privs-binding
spec:
  policyName: require-digest-and-min-privs
  matchResources:
    namespaceSelector: {}
  validationActions: ["Deny"]

The direct solution with Quor.dev

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

The Near-Zero CVE images from Quor.dev reduce the attack surface and offer SBOM and verified provenance, facilitating continuous auditing. This does not replace patching the application, but it eliminates background noise and accelerates incident response.

The point is: security is not only about the framework your team chooses. The entire tool stack deserves attention, and Redis is high on that list. Quor.dev delivers this with just a simple 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 depending on the family;

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

• Apply ACLs denying @scripting and removing EVAL and EVALSHA for all users who do not need them;

• Create or harden NetworkPolicies. Allow only authorized pods;

• Apply admission policies. Require digests and enforce least privilege;

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

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

Compliance & Controls

• CIS Kubernetes Benchmark. Controls for NetworkPolicy, admission policies, and least privilege in Pods;

• NIST SSDF and NIST 800-53. Practices for continuous updates, software inventory, SBOM, and hardening;

• PCI DSS. Surface reduction and network segmentation. SBOM and Zero-CVE images facilitate evidence gathering 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 exploit chain and timeline;

• Public pages of official images for verifying tags and digests;

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

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