Redis RediShell RCE: Authenticated Users Can Trigger Lua Use-After-Free for OS Command Execution
Redis is not just a cache sitting quietly behind applications. In many environments, it holds sessions, tokens, queues, transient business data, and cloud-adjacent secrets close enough to become a pivot point when compromised.
That is why CVE-2025-49844, also known as RediShell, deserves urgent attention. Redis has confirmed that an authenticated user can submit a specially crafted Lua script, manipulate garbage collection, trigger a use-after-free condition, and potentially achieve remote code execution on the Redis host.
What Happened
Redis disclosed CVE-2025-49844 on October 3, 2025, describing it as a Lua use-after-free vulnerability that may lead to remote code execution. The flaw carries a CVSS score of 10.0, placing it in the highest severity category.
The issue is tied to Redis Lua scripting. According to Redis, an authenticated attacker may use a specially crafted Lua script to manipulate the garbage collector, trigger a use-after-free, and potentially execute code remotely. Exploitation requires authenticated access to the Redis instance, but that requirement should not create a false sense of safety.
Wiz Research, which reported the vulnerability with Trend Micro Zero Day Initiative, said the bug had existed in Redis source code for approximately 13 years. Their analysis described the exploit path as a post-authentication Lua sandbox escape that can lead to arbitrary native code execution on the underlying host.
Affected and Fixed Versions
Redis says all Redis OSS, Community Edition, and Stack releases with Lua scripting are affected unless patched. Fixed Redis OSS and CE releases include 8.2.2 and above, 8.0.4 and above, 7.4.6 and above, and 7.2.11 and above. Redis Stack fixes are available in 7.4.0-v7 and above, and 7.2.0-v19 and above.
For Redis Software, Redis lists fixed releases as 7.22.2-20 and above, 7.8.6-207 and above, 7.4.6-272 and above, 7.2.4-138 and above, and 6.4.2-131 and above. Redis also noted that all at-risk Redis Cloud subscriptions had already been patched.
Why This Stands Out
The dangerous part is not simply that Redis has an RCE-class bug. It is where Redis usually sits.
Redis often lives inside application paths where developers optimize for speed, not hostile input. It may be reachable from workloads, containers, CI systems, internal services, and cloud networks where authentication is weaker than it should be. Once an attacker has valid Redis access, the database can become more than a data store. It can become a code execution surface.
Wiz estimated that Redis is used in 75% of cloud environments. Its exposure analysis found roughly 330,000 Redis instances reachable from the internet, including about 60,000 with no authentication configured. That makes the authenticated-access requirement less reassuring in real-world environments where exposed services, weak credentials, shared internal networks, and forgotten development deployments still exist.
Operational Impact
A successful exploit can move the attacker from Redis-level access to host-level execution. From there, the risk changes quickly: credential theft, Redis data extraction, persistence, malware deployment, cryptomining, destructive actions, and lateral movement into adjacent cloud services become realistic outcomes.
Redis advised defenders to look for signs such as unexpected Redis scripting command usage, unknown scripts, Redis crashes with Lua engine stack traces, anomalous network ingress or egress, unexpected command execution by the redis-server user, and unexplained file-system changes in Redis configuration or persistence directories.
What Defenders Should Do Now
Patch first. Self-managed Redis operators should upgrade to a fixed release immediately, with internet-exposed instances and systems with broad internal reach treated as priority one.
Where immediate patching is blocked, reduce the attack surface while the upgrade path is completed. Restrict Redis network access to trusted sources, enforce strong authentication, confirm protected mode is enabled where applicable, and review Redis ACLs so only trusted identities can run Lua scripting commands such as EVAL and EVALSHA.
Teams should also audit containerized Redis deployments. Wiz specifically called out container image usage as a major exposure path, noting that many Redis deployments are installed without proper hardening. Any Redis container running without authentication, with broad network reachability, or with unnecessary scripting permissions should be treated as a high-risk asset.
Bigger Picture
RediShell is a reminder that “internal” infrastructure is still attack surface. Redis is often assumed to be safely tucked behind applications, but modern cloud environments blur that boundary. Containers, service meshes, CI/CD runners, shared VPCs, and exposed development stacks can turn a supposedly internal datastore into an attacker-accessible execution point.
The deeper lesson is permission control. Redis authentication is not enough if every authenticated identity can run high-risk scripting features. For a datastore that frequently handles sensitive operational data, least privilege has to apply inside Redis, not just at the firewall.
NeuraCyb's Assessment
This is a patch-now vulnerability because it combines three uncomfortable realities: Redis is everywhere, Lua scripting is powerful, and authenticated access is often easier to obtain than security teams want to admit. Treat Redis like infrastructure capable of executing code, not just a fast key-value store. The organizations that move fastest here will not be the ones with the longest policy documents; they will be the ones that can find every Redis instance, verify its exposure, restrict scripting, and patch without debate.
References
Redis Security Advisory: CVE-2025-49844
Wiz Research: RediShell Critical Remote Code Execution Vulnerability in Redis
