Skip to main content

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.

Published on October 21, 2025
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.

​
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 branchMinimum patched version
6.26.2.20
7.27.2.11
7.47.4.6
8.08.0.4
8.28.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: 
# 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

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.