Redishell: The Critical 13-Year-Old Redis Vulnerability Need to be Patched

Redishell: The Critical 13-Year-Old Redis Vulnerability Need to be Patched

In early October 2025, a devastating remote code execution (RCE) vulnerability in Redis—known as Redishell (CVE-2025-49844)—shook the cybersecurity community. Marked with a perfect CVSS score of 10.0, this flaw has quietly existed since 2012, placing approximately 60,000 publicly accessible Redis servers without authentication at severe risk of exploitation.

What is Redishell?

Redishell is a use-after-free (UAF) memory corruption vulnerability in Redis’s Lua scripting engine. By exploiting this flaw, attackers can break out of the Lua sandbox environment and execute arbitrary native code on the underlying host machine. This goes far beyond data theft—it gives attackers complete take-over capability of the Redis server and potentially the broader network it resides in.

Why Does This Vulnerability Matter?

Redis is widely used as an in-memory data store and cache, including in cloud environments that power critical applications. According to recent research, about 330,000 Redis instances are internet-exposed globally, out of which roughly 60,000 lack password authentication or other effective access controls. These vulnerable Redis servers are an easy target for attackers armed with this exploit.

How Does Redishell Work?

The root cause is a Lua garbage collector-related bug, introduced in Redis’s codebase in 2012. Attackers sending maliciously crafted Lua scripts to a vulnerable Redis server can trigger use-after-free conditions. This carefully orchestrated memory corruption allows the attacker to escape the sandbox restrictions and run code with the same privileges as the Redis process.

Remote code execution requires attacker access to send commands to the Redis instance—meaning unsecured or poorly secured Redis servers are those most at risk. Exploiting this flaw enables scenarios like:

  • Implanting backdoors or malware
  • Exfiltrating sensitive data
  • Pivoting to inner networks within compromised cloud environments

What Should Organizations Do? Urgent Mitigation Steps

The Redis project has responded swiftly with patches released in versions 6.2.20, 7.2.11, 7.4.6, 8.0.4, and 8.2.2. The following actions are critical for risk mitigation:

  • Patch Immediately: Upgrade vulnerable Redis instances to the latest patched versions without delay.
  • Enforce Authentication: Require strong passwords and authentication mechanisms for all Redis access.
  • Restrict Network Access: Block or limit Redis traffic from untrusted networks, especially the public internet.
  • Disable Lua Scripts: If Lua scripting is not required, disable it to reduce attack surfaces.
  • Least Privilege: Run Redis instances with minimal permissions and isolate them in secure environments.
  • Monitor and Audit: Implement monitoring to detect suspicious Lua script executions or unusual network activity.

Final Thoughts

Redishell exposes a glaring blind spot for many organizations relying on Redis. Given the ease of exploitation and the potential impact, it is imperative for administrators to evaluate their Redis deployments immediately and apply patches as a top priority. Proper security hygiene around authentication, network controls, and monitoring can dramatically reduce exposure to this critical vulnerability.

Previous Article

Critical Flaw Exposes 60,000 Redis Servers to Remote Exploitation

Next Article

Google's New AI Doesn't Just Find Vulnerabilities — It Rewrites Code to Patch Them