Urgent Redis Update Fixes Critical RCE Vulnerability
▼ Summary
– Redis has patched a critical vulnerability (CVE-2025-49844) that allows attackers to execute arbitrary code on the host system via malicious Lua scripts.
– The vulnerability stems from a use-after-free memory corruption bug in Redis’s Lua scripting feature, affecting versions 8.2.1 and earlier.
– Official Redis container images have authentication disabled by default, and many internet-exposed instances lack authentication, increasing exploitation risk.
– Attackers can use this flaw to compromise the host, install malware, exfiltrate data, and access other cloud services if credentials are stolen.
– Administrators are advised to update Redis immediately, disable Lua scripting via ACLs, enable authentication, and implement network-level access controls.
A critical security flaw in Redis, identified as CVE-2025-49844, demands immediate attention from system administrators. This vulnerability enables attackers who gain access to execute arbitrary code on the host server, potentially leading to complete system compromise. The issue stems from a use-after-free memory corruption bug within the Lua scripting functionality, which is active by default in Redis installations.
Security researchers at Wiz have named this flaw RediShell. They explain that an authenticated attacker can send a malicious Lua script to break out of the Lua sandbox. Once this occurs, the attacker can run any native code on the Redis host. The situation is made more severe because the official Redis container images ship with authentication turned off by default.
Analysis indicates that a majority of cloud environments, roughly 57%, deploy Redis using container images. If these deployments are not properly secured, they might run without any authentication at all. When an instance lacking authentication is connected to the internet, it becomes an easy target. Attackers can directly query the Redis instance and submit Lua scripts, allowing them to exploit this vulnerability and achieve remote code execution within that environment.
This vulnerability affects a wide range of Redis versions. The problematic code was introduced back in 2012, meaning Redis server versions 8.2.1 and earlier that support Lua scripting are vulnerable. Patches are now available for both commercial and open-source editions.
For commercial Redis Software, the fixed versions are 7.22.2-12 and higher, 7.8.6-207 and higher, 7.4.6-272 and higher, 7.2.4-138 and higher, and 6.4.2-131 and higher. The open-source Redis Community Edition fixes are available in versions 8.2.2 and higher, 8.0.4 and higher, 7.4.6 and higher, and 7.2.11 and higher. Redis Stack users should update to 7.4.0-v7 and higher or 7.2.0-v19 and higher.
The scale of exposure is significant. Researchers estimate around 330,000 Redis instances are directly accessible from the internet. Alarmingly, about 60,000 of these have no authentication configured, leaving them wide open to attack. The German Federal Office for Information Security has also issued an alert, noting the presence of approximately 4,000 unauthenticated Redis servers within Germany.
Given the straightforward nature of the attack and Redis’s widespread adoption, exploitation attempts are anticipated imminently, particularly once technical specifics become publicly available. Wiz has currently withheld these details to allow time for systems to be patched.
System administrators are strongly urged to apply the available updates without delay. If immediate updating is not possible, a temporary mitigation is to disable Lua scripting. This can be done by using Redis Access Control Lists to block the EVAL and EVALSHA commands.
Beyond patching or disabling the feature, security best practices should be implemented to harden Redis installations. Enabling authentication is a fundamental and critical step. Additional measures include disabling any commands that are not essential for operation, running the Redis process under a dedicated non-root user account, and activating comprehensive logging to monitor for suspicious activity. Implementing strict network-level access controls to ensure Redis is only reachable from authorized networks is also highly recommended.
(Source: HelpNet Security)
