Redis CVSS 10.0: How 13-year Lua bug lets attackers escape

Redis disclosed CVE-2025-49844 on October 3, 2025, a critical vulnerability affecting every version released over the past 13 years. Assigned the maximum severity score of 10.0, this flaw allows authenticated attackers to execute arbitrary code on Redis servers through malicious Lua scripts. With Redis deployed in 75% of cloud environments and over 330,000 instances exposed to the internet of which 60,000 without authentication, this represents one of 2025's most significant database security threats.

This vulnerability represents a material security risk requiring immediate executive attention and action. Organizations running Redis for caching, session management, or real-time analytics face immediate risk of complete system compromise if patches are not deployed urgently.

What happened

Wiz Research discovered the vulnerability and reported it to Redis on May 16, 2025, identifying a Use-After-Free (UAF) memory corruption bug embedded in source code for approximately 13 years. The flaw exists in Redis Lua scripting engine, a feature enabled by default that developers commonly use to extend database functionality.

Redis released security patches on October 3, 2025, fixing the issue in versions 6.2.20, 7.2.11, 7.4.6, 8.0.4, and 8.2.2. The company simultaneously published a security advisory detailing the vulnerability's mechanics and mitigation strategies. Redis Cloud customers were automatically patched and require no action, while self-hosted instances demand immediate administrator intervention.

Wiz researchers dubbed the vulnerability "RediShell" due to its capability to grant attackers complete shell access to underlying host systems. The flaw affects all Redis versions that include Lua scripting support or essentially every production deployment worldwide.

What attackers can achieve

CVE-2025-49844 allows authenticated attackers to craft malicious Lua scripts that manipulate Redis garbage collector, triggering memory corruption that leads to code execution outside the Lua sandbox. This sandbox escape grants native code execution privileges on the Redis host system with the same permissions as the Redis process.

Once attackers achieve code execution, they gain unrestricted access to steal credentials stored in memory or configuration files, deploy ransomware or cryptomining malware, exfiltrate sensitive data cached in Redis including session tokens and user information, wipe or encrypt database contents, and pivot laterally to other systems within cloud environments.

The vulnerability's technical mechanism exploits insufficient validation of object liveness during garbage collection. Crafted Lua scripts cause the garbage collector to free memory still referenced by active objects, creating a use-after-free condition that permits arbitrary code execution. Because Lua scripting is enabled by default and widely used, virtually all production deployments are vulnerable.

The maximum CVSS score reflects severe characteristics: network-based attack vector, low attack complexity, requirement for only low-level authentication privileges, no user interaction needed, changed scope allowing attacks beyond the vulnerable component, and high impact to confidentiality, integrity, and availability.

Which systems were protected

Redis Cloud managed service customers were automatically patched and do not require manual intervention. The core Redis data storage and retrieval functionality remains secure when Lua scripting is disabled or properly restricted through Access Control Lists.

Organizations that implemented strict network isolation, preventing external access to Redis instances, significantly reduced their exposure even before patches became available. Deployments configured with ACLs that already restricted EVAL and EVALSHA commands to trusted administrators were protected against exploitation.

How attacks like this unfold

Cybercriminals target Redis instances because they frequently cache high-value data including authentication tokens, session identifiers, payment information, and application secrets. Attackers systematically scan for internet-exposed Redis servers, identifying vulnerable instances globally.

The attack progression begins when attackers gain authenticated access through compromised credentials, exposed instances without authentication, or exploited application vulnerabilities that provide Redis access. Once authenticated, attackers submit specially crafted Lua scripts via the EVAL or EVALSHA commands.

These malicious scripts manipulate Redis garbage collector to create memory corruption conditions. The resulting use-after-free vulnerability allows code execution outside the Lua sandbox, granting native execution on the host operating system. From this foothold, attackers deploy additional malware, establish persistence mechanisms, exfiltrate cached credentials, access cloud metadata services to steal provider credentials, and move laterally to compromise additional infrastructure.

Redis instances represent particularly attractive targets for cryptojacking campaigns and botnet recruitment due to the database's high-performance nature and typical deployment on powerful servers.

Why leaders should care

Redis powers critical infrastructure across industries, serving as the caching layer for e-commerce platforms, session storage for financial applications, real-time analytics for healthcare systems, and message queues for enterprise microservices. A vulnerability affecting all Redis versions creates organization-wide exposure.

Unlike vulnerabilities requiring complex attack chains or extensive privileges, CVE-2025-49844 requires only basic authenticated access, which is a threshold attackers routinely overcome through credential stuffing, phishing, or application-level exploits. Data breach costs continue escalating, with regulatory frameworks like GDPR, HIPAA, and PCI-DSS imposing severe penalties for organizations demonstrating negligence in applying critical security updates.

Public disclosure of technical details and proof-of-concept code increases exploitation likelihood. While no active exploitation has been observed as of mid-October 2025, the vulnerability's severity and Redis ubiquity make attacks inevitable once exploit code circulates widely.

What to do now

1. Inventory and assess your Redis footprint

   Start by identifying all Redis instances across infrastructure, including development, staging, and production environments. Document Redis versions, network exposure status, authentication configurations, and applications depending on each instance. Map which systems cache sensitive data in Redis to prioritize patching efforts.

2. Apply security patches immediately

   Upgrade all Redis instances to patched versions: 6.2.20, 7.2.11, 7.4.6, 8.0.4, or 8.2.2. Prioritize internet-facing instances and those caching sensitive data for immediate patching. Test patches in staging environments before production deployment, but recognize that the vulnerability's severity demands rapid rollout.

3. Implement emergency mitigations

   For instances where immediate patching is impossible, configure Access Control Lists (ACLs) to restrict EVAL and EVALSHA commands to only trusted administrator accounts. Remove these commands entirely from application-level Redis access. Implement network segmentation to eliminate direct internet exposure, requiring access through application layers or VPNs.

4. Enforce authentication and access controls

   Ensure all Redis instances require strong authentication credentials. Enable protected-mode in Redis Community Edition to prevent accidental exposure. Review user permissions to ensure identities accessing Redis have minimum necessary privileges, restricting Lua script execution to only trusted administrators.

5. Conduct security assessments

   Partner with cybersecurity consultancies to perform penetration testing specifically targeting Redis infrastructure. Verify that network policies effectively isolate Redis instances from unauthorized access. Test whether application-level vulnerabilities could provide attackers with Redis authentication.

6. Monitor for compromise indicators

   Review Redis logs for suspicious Lua script execution, particularly EVAL and EVALSHA commands from unexpected sources. Monitor system logs on Redis hosts for unusual process spawning or network connections. Implement runtime monitoring to detect sandbox escape attempts and unauthorized code execution.

Pressing questions

• How severe is this vulnerability compared to other database flaws?

  CVE-2025-49844 received the maximum CVSS score of 10.0, indicating the highest possible severity. The combination of widespread deployment, presence in all Redis versions for 13 years, and complete system compromise capability makes this one of the most critical database vulnerabilities in recent history.

• Can attackers exploit this vulnerability remotely?

  Yes. Authenticated attackers can exploit CVE-2025-49844 remotely over network connections. Internet-exposed instances face immediate risk, especially those lacking authentication. Even properly authenticated instances remain vulnerable if attackers compromise credentials through other means.

• What should organizations do if immediate patching is impossible?

  Implement ACLs to completely restrict EVAL and EVALSHA commands from all non-administrator accounts. Remove direct internet exposure through network segmentation and firewall rules. However, these mitigations represent temporary measures and patching remains the only complete solution.

• Do Redis Cloud customers need to take action?

  No. Redis Cloud managed service customers were automatically patched and require no manual intervention. Organizations running self-hosted Redis instances must apply patches immediately regardless of deployment environment.

Key takeaways

CVE-2025-49844 represents a maximum-severity vulnerability granting authenticated attackers complete control over Redis hosts through malicious Lua scripts. Organizations must prioritize immediate patching, beginning with internet-facing instances and those caching sensitive data.

Temporary mitigations through Access Control Lists restricting Lua script execution provide partial protection but cannot substitute for patching. Business leaders should ensure Redis deployments receive immediate attention, recognizing that successful exploitation enables data theft, ransomware deployment, and lateral movement.