> ## Documentation Index
> Fetch the complete documentation index at: https://help.onetsolutions.net/llms.txt
> Use this file to discover all available pages before exploring further.

# RediShell (CVE-2025-49844): Redis Lua Sandbox Escape to RCE

> A malicious Lua script exploits a use-after-free in Redis's embedded engine to execute native code on the host. Public PoC.

*Published on October 21, 2025*

<Warning>
  **CVE-2025-49844 — "RediShell".** A Redis client with access to the `EVAL` command can escape the Lua sandbox and run native code on the host. On any Redis that is misconfigured (no `requirepass`, exposed to LAN or internet), the attack effectively becomes pre-authentication.
</Warning>

## The mechanics

Redis's embedded Lua engine theoretically isolates user scripts in a sandbox. The bug is a two-step affair:

1. **Memory corruption.** A specially-crafted Lua script manipulates Lua's garbage collector to free an object that is still referenced elsewhere.
2. **Escape.** The resulting use-after-free lets the attacker break out of the Lua interpreter and run code natively inside the `redis-server` process.

From there, the attacker owns the Redis process with its rights. On most deployments, those rights are enough to read data, reach the container or VM filesystem, and attempt lateral movement to other services reachable from the host.

## Why the "authenticated" qualifier is misleading

The advisory talks about an authenticated attacker — but in practice:

* Many Redis instances run with no `requirepass`, sitting on networks assumed to be "trusted".
* Others store credentials in plaintext inside backups, Docker images, or leaked environment variables.
* A plain SSRF in an application that talks to an internal Redis is enough to look "authenticated" from Redis's perspective.

Bottom line: the real exposure is broad.

## Patches

Upgrade Redis to (at least) the patched version for your branch:

| Redis branch | Minimum patched version |
| ------------ | ----------------------- |
| 6.2          | 6.2.20                  |
| 7.2          | 7.2.11                  |
| 7.4          | 7.4.6                   |
| 8.0          | 8.0.4                   |
| 8.2          | 8.2.2                   |

## Mitigation if you cannot patch right away

Disable the Lua commands through Redis ACLs. Not ideal (some apps depend on them) but it closes the attack path:

```redis theme={null}
# For the default user
ACL SETUSER default -eval -evalsha -fcall -fcall_ro -function

# Verify
ACL LIST
```

On the network side:

* Bind Redis to `127.0.0.1` or to a strictly internal network (`bind` in `redis.conf`).
* Enable `requirepass` or named ACLs.
* Block port `6379` at the firewall for everything except your application clients.

## Check your version

```bash theme={null}
redis-cli INFO server | grep redis_version
```

## Takeaways

* Patching is the right answer. If you defer: ACL `-eval` + network restriction, in the meantime.
* Use the restart to tighten configuration: binding, requirepass, renaming dangerous commands.
* A PoC is public, exploitation is trivial once `EVAL` is reachable — don't sit on it.

For help, open a ticket from your [OnetSolutions client area](https://onetsolutions.net).