RediShell (CVE-2025-49844) — The Redis Lua Sandbox Escape Vulnerability

Understanding the Issue: RediShell (CVE-2025-49844)

In October 2025, Wiz Research disclosed a critical remote code execution (RCE) vulnerability in Redis, which they named RediShell (CVE-2025-49844). The vulnerability stems from a use-after-free (UAF) memory corruption bug in the Lua scripting component of Redis, present for over a decade in the codebase.

Here’s how it works, at a high level:

• Redis supports running Lua scripts via commands like EVAL and EVALSHA.
• An attacker who already has some access (post-auth) can submit a specially crafted Lua script that manipulates the garbage collector or memory management internals. (The Hacker News)
• Because of a UAF bug, the script can trick Redis into freeing memory and then reusing it in a way that escapes the sandbox, leading to arbitrary native code execution on the host. (wiz.io)
• Once code execution is achieved, an attacker can fully compromise the host: exfiltrate data, wipe disks, install malware, pivot laterally to other systems, etc. (wiz.io)

Because Redis is heavily used in cloud and caching architectures, and because many deployments are misconfigured (e.g. exposed to the internet, lacking authentication), the impact is broad. Wiz estimates some 330,000 Redis instances are exposed publicly, with ~60,000 lacking authentication altogether. (wiz.io)

It’s also noteworthy that this is the first Redis vulnerability to receive a CVSS 10.0 (maximum severity) rating, underlining its severity. (wiz.io)

Which Versions Are Vulnerable?

According to the Hacker News summary of the Redis advisory, all versions of Redis with Lua scripting enabled are impacted. (The Hacker News)
However, patched versions have been released to address the vulnerability. The versions that fix the issue include:

• 6.2.20
• 7.2.11
• 7.4.6
• 8.0.4
• 8.2.2

Therefore, any Redis version older than these (in the respective major line) is considered vulnerable if Lua scripting is enabled. Also, even in newer versions, misconfiguration (e.g. allowing scripting or not applying the patch) may still leave you exposed.

How to Determine Your Redis Version & Assess Vulnerability

Here’s a practical checklist you can use to find out whether your Redis instance is vulnerable:

1. Connect to the Redis instance (locally or via CLI)

For example, using redis-cli:

redis-cli -h <host> -p <port> INFO server | grep redis_version

This outputs something like:

redis_version:7.0.15

Alternatively, you can run:

redis-cli -h <host> -p <port> INFO

and parse the redis_version field under the [Server] section.

2. Compare version to patched ones

If your reported version is less than the patched versions listed above in the same major branch (e.g. less than 7.2.11 if in the 7.x series), then your instance is likely vulnerable—assuming scripting is enabled.

If it’s equal or greater than the patched version (for that branch), you’re already on the safe side with regard to this specific bug (if patch is correctly applied).

3. Check whether Lua scripting is allowed / EVAL commands usable

Even a patched version might be misconfigured. You can test whether scripting commands are allowed:

redis-cli -h <host> -p <port> AUTH <password-if-enabled>
redis-cli -h <host> -p <port> EVAL "return 1" 0

If the EVAL command succeeds (returns 1), then scripting is enabled. If you get an error like NOPERM or “unknown command,” scripting is disabled or controlled by ACLs.

Alternatively, examine your redis.conf or ACL policies to see whether commands like EVAL, EVALSHA, SCRIPT, etc., are allowed for your user roles.

How to Check Whether Your Redis Is Internet-Accessible

Because the vulnerability requires network connectivity (i.e. attacker must reach the Redis service), one key risk is internet exposure. Below are ways you can assess whether your instance is accessible from the internet.

1. Port scanning (external)

From an external system (not within your internal network or cloud VPC), run a basic port check. For example:

nmap -p <redis_port> <public_ip>

If port 6379 (default) or your custom Redis port is open and responding, then your Redis is reachable.

2. Check cloud firewall / security group rules

If your Redis instance is deployed in a cloud environment (AWS, Azure, GCP, etc.), check the associated security group, network ACL, or firewall settings and inbound rules. If the Redis port (6379 or custom) is allowed from 0.0.0.0/0 (i.e. anywhere), it’s exposed. Ensure that inbound access is limited to known IPs or internal subnets.

3. Try connecting externally via redis-cli (from outside)

From a remote host:

redis-cli -h <public_ip> -p <port>

If you get a prompt or a connection (even an authentication prompt), the instance is reachable. If connection times out or is blocked, it’s likely firewalled.

Mitigations & Remediation Steps (brief)

(Though your request didn’t ask explicitly, it’s useful to include.)

1. Upgrade immediately to the patched versions listed above.
2. Disable or restrict Lua scripting: If you don’t need scripting, disable it or restrict via ACLs.
3. Require authentication: Use requirepass or ACL-based authentication so that anonymous access is prevented.
4. Disable unnecessary commands via ACLs (e.g. block EVAL, EVALSHA).
5. Run Redis under least privilege (non-root, minimal permissions).
6. Add network-level controls / firewall restrictions so only trusted addresses or internal networks can talk to Redis.

Let’s test this with xCloud hosted servers

Step 01: Check Redis version

We can run the following command and find out the Redis version on our xCloud server:

redis-cli --version

❌ The Redis version running on our xCloud server is vulnerable.

Step 02: Check if Redis is exploitable or not

Let’s first check if Redis allows connections from the internet or not on our xCloud servers using the following command:

grep "^bind" /etc/redis/redis.conf

❌ This means Redis listens on every available IPv4 address on our system — including public IPs

However, xCloud’s built-in firewall feature does not allow connections to port 6379 by default. So xCloud servers & users are safe from this vulnerability. ✅

But for testing purposes, let’s allow the port 6379 for a brief period to exploit it.

We intentionally opened the port to the internet to make the vulnerability exploitable. DO NOT DO THIS AT HOME.

Step 03: Let’s try to exploit the vulnerability

We will try to connect to our Redis server from another machine. We will run the following command to try to exploit the vulnerability:

redis-cli -h 15x.xx.xx.x5  -p 6379  EVAL "return 1" 0

✅ This means xCloud server’s Redis requires authentication. So even if port 6379 is open, the attacker must have access to a Redis account credentials to exploit this.

Let’s go even further, and say that one of our sites got hacked and the attacker received the Redis credentials for that site.

Now using the provided Redis credentials we can use the following command to actually exploit the vulnerability:

redis-cli -u redis://username:Passwordu@1xx.xx.xx.x5:6379 EVAL "return 1" 0

Finally, we have been able to successfully exploit our xCloud server using the latest Redis vulnerability.

Summary (TL;DR)

❌ The Redis version running on xCloud servers is vulnerable to CVE-2025-49844

✅ But, xCloud users are safe and protected by xCloud’s firewall and ACL.