RediShell (CVE-2025-49844): the Redis Lua use-after-free

02Affected and fixed versions, and the companions

RediShell shipped alongside three companion Lua bugs disclosed the same day, all fixed in the same releases. Further memory-safety bugs with RCE potential followed from November 2025 into 2026, most of them reachable through scripting or the RESTORE command, and were fixed in the 8.x and back-ported lines. Get onto a current patch level for your line and keep moving as the follow-ups land.

03How an attack works, conceptually

The attacker needs a connection that can run a script. They send a Lua script engineered to drive the garbage collector into freeing an object that the engine still references, then act through that freed reference to corrupt memory and break out of the sandbox into the host process. The companion bugs and later follow-ups reach similar ends through an integer overflow, a user-context confusion, or malformed input to the RESTORE command.

The decisive factor is reachability. If your Redis is bound to localhost or a private network and requires strong credentials, an external attacker has no connection on which to send a script in the first place. If it is exposed to the internet — especially with the default container configuration, which does not require authentication — then the precondition is trivially met. Configuration, not the bug alone, is what determines whether you are exploitable.

04How to check if you are affected

Two questions matter: is the version below the fix for your line, and can anyone reach it without authentication? An instance that is unpatched but bound to localhost with a strong password is far less exposed than a patched instance listening on a public address with nopass. Check both, and fix exposure first if it is wrong.

# Version (compare against the fixed releases for your line)
redis-server --version
redis-cli INFO server | grep -E '^(redis_version|os):'

# Is it listening only on localhost / a private address?
ss -ltnp 'sport = :6379'
redis-cli CONFIG GET bind
redis-cli CONFIG GET protected-mode

# Does the default user require a password?
redis-cli ACL WHOAMI
redis-cli ACL LIST            # look for 'nopass' on the default user

05How to fix and harden Redis

Upgrade to the newest release of your line — 8.2.2, 8.0.4, 7.4.6, 7.2.11 and 6.2.20 are only the minimums for RediShell — and then harden, because Redis's own advisory notes that exploitation first requires authenticated access to the instance. The single most important control is network isolation: Redis should almost never be reachable from the public internet. Beyond that, require authentication, and use ACLs to deny scripting and dangerous commands to any user that does not need them.

• Never expose Redis directly to the internet; bind it to localhost or a private network and firewall port 6379, which belongs on the never-public list of ports
• Leave protected-mode on and set strong credentials with requirepass or, better, per-user ACLs
• Deny scripting to users that do not need it with -@scripting (covering EVAL, EVALSHA and FUNCTION), which closes the whole Lua family
• Restrict RESTORE, CONFIG, REPLICAOF and other -@dangerous commands to a dedicated admin user only
• Run Redis as a non-root user so a successful escape yields the least possible on the host

# redis.conf: keep Redis off the internet first (these are the upstream defaults)
bind 127.0.0.1 -::1
protected-mode yes

# At the redis-cli prompt, as an admin user, on one line. The app user can read and
# write its own keys but cannot run scripts or @dangerous commands (RESTORE, FLUSHALL, CONFIG ...).
# Rules apply left to right, so the deny rules must come last.
# ACL SETUSER appuser on >REPLACE_WITH_STRONG_SECRET ~app:* +@read +@write -@scripting -@dangerous

# Then give the default user a password or disable it (no nopass in production).

06What a WAF or reverse proxy can and cannot do

This is where honesty matters most. Redis speaks its own protocol (RESP), not HTTP, so a web application firewall and an HTTP reverse proxy have nothing to inspect — they sit in front of your website, not your datastore, and never see Redis traffic. No edge rule filters a Lua script or a RESTORE payload. Any claim that a web firewall "protects Redis" is misplaced.

The controls that work are network and identity controls: keep the datastore private, authenticate every client, and apply least-privilege ACLs. A proxy such as GuardX protects the public web tier in front of an application, and keeping your origin's real address hidden reduces the chance that an attacker maps your backend network at all. That is perimeter obscurity, though — it is not protection of the datastore itself. Patch it and lock it down directly.

07Disclosure timeline

A thirteen-year-old bug in default-reachable software is a reminder that exposure is the real risk multiplier. The fix is a quick upgrade, but the lasting protection is the posture: Redis on a private network, authenticated, with scripting and dangerous commands denied to everyone who does not need them. Treat the next disclosure as a given and keep that posture in place, the same way you keep attack protection always on.