Redis Critical RCE Vulnerability Puts Thousands of Instances at Risk

The Redis security team has issued patches for a critical, maximum-severity vulnerability that enables authenticated attackers to execute code remotely on affected systems. This flaw, a use-after-free bug in the Lua scripting engine that has existed for approximately 13 years, was discovered and exploited during the Pwn2Own Berlin competition¹. With hundreds of thousands of Redis instances exposed online, a significant portion of which lack authentication, this vulnerability presents a substantial risk for full system compromise.

This security advisory provides a detailed analysis of the critical Remote Code Execution (RCE) vulnerability, designated CVE-2025-49844, alongside other recent Redis security issues. The report includes technical specifics, patching guidance, and mitigation strategies to assist security and operations teams in securing their infrastructure. The information is consolidated from recent security advisories and performance analyses to offer a complete operational picture.

Critical Remote Code Execution Vulnerability (CVE-2025-49844)

Discovered by Wiz researchers at Pwn2Own Berlin, CVE-2025-49844 is a use-after-free vulnerability within Redis’s Lua scripting engine, which is enabled by default. The flaw has been assigned the maximum CVSS score of 10.0. Attackers with authenticated access can craft a specialized Lua script to break out of the Lua sandbox, trigger the use-after-free condition, and establish a reverse shell on the host system, a technique researchers have dubbed “RediShell”¹. The primary risk factor is that successful exploitation requires only authenticated access, and researchers identified approximately 330,000 Redis instances online, with at least 60,000 not requiring any authentication, making them immediately vulnerable to attack.

The impact of a successful exploit is severe, leading to complete host compromise. This enables threat actors to steal sensitive data, deploy malware or cryptominers, move laterally through the network, and potentially deploy ransomware. The vulnerability affects a wide range of Redis versions, and the maintainers have released patches for multiple active branches. The patched versions include Redis OSS/CE 8.2.2+, 8.0.4+, 7.4.6+, and 7.2.11+, as well as Redis Stack 7.4.0-v7+ and 7.2.0-v19+¹. System administrators are urged to prioritize patching any internet-exposed instances immediately.

Additional Redis Security Advisories

Beyond the critical RCE flaw, Redis users must contend with several other vulnerabilities that impact service availability and security. CVE-2025-21605 is a high-severity Denial-of-Service (DoS) vulnerability that allows unauthenticated attackers to crash Redis servers or exhaust system memory by exploiting improperly limited client output buffers². Even servers with password authentication enabled are vulnerable because unauthenticated clients still trigger “NOAUTH” error responses that consume memory. This issue affects Redis versions 2.6 and newer and has been patched in OSS/CE versions 6.2.18, 7.2.8, and 7.4.3.

Another notable issue is CVE-2025-48367, an authenticated DoS flaw. The U.S. Cybersecurity and Infrastructure Security Agency (CISA) has formally acknowledged this vulnerability in its “Known Exploited Vulnerabilities” catalog⁴, ⁵. The Redis team has taken the unusual stance of not issuing a direct code fix. They provided a statement explaining their rationale:

“Our assessment is that implementing an application change to prevent this possibility would negatively impact legitimate functionality and performance of Redis,” the team stated. “As a result, we do not have a fix planned for this issue and are instead opting to publish this Security Advisory.”

This positions the issue as a violation of the trust model for authenticated users rather than a code flaw, shifting the mitigation burden to access control.

Vulnerability in the Go Client Library

The Redis security surface extends beyond the server to its client ecosystem. A vulnerability, CVE-2025-29923, was discovered in the official Redis client library for Go, `go-redis`⁶. Under specific conditions involving a timeout of the `CLIENT SETINFO` command during connection setup, the client can return responses out of order. This can lead to application logic errors and data consistency issues, as a response for one command could be incorrectly applied to a subsequent command. The vulnerability affects `go-redis` versions prior to 9.5.5, 9.6.3, and 9.7.3. Developers are advised to upgrade the library or, as a temporary workaround, set the `DisableIndentity` flag to `true` when constructing the client.

Historical Context and Ongoing Threats

Redis instances have long been a favorite target for malicious botnets due to frequent misconfigurations and the value of the data they often hold. Historical campaigns provide context for the current threat level. The Redigo malware, which exploited a previous Lua sandbox escape (CVE-2022-0543), used a sophisticated attack chain to hide a backdoor by mimicking Redis server communication¹, ⁸. More recently, the P2PInfect botnet targeted unpatched Redis servers to install cryptominers and a ransomware module. Other campaigns like HeadCrab and Migo have also successfully backdoored Redis servers for cryptomining, demonstrating a consistent and evolving threat.

Performance and Security Interactions

A detailed performance engineering case study from GitLab⁶ highlights a critical operational pathology with direct security implications: chronic, eviction-driven latency spikes. The investigation found that when memory usage reaches the eviction threshold (`maxmemory`), the eviction process can saturate the single-threaded Redis main CPU. This CPU saturation causes the server’s response rate to fall below the incoming request rate, creating a backlog of requests that themselves consume memory, perpetuating a cycle of evictions and high latency.

This performance issue is relevant to security because it underscores the importance of stable system operation for maintaining security controls and monitoring. A system under resource exhaustion is more difficult to monitor and may be more susceptible to other attacks. The solution involved breaking the cycle by avoiding memory saturation through measures like reducing cache TTL, implementing client-side caching, and partitioning the cache. This case study serves as a reminder that performance tuning and resource management are integral components of a secure Redis deployment.

Relevance and Remediation

For security and operations teams, the immediate priority is to patch all Redis instances against CVE-2025-49844. Internet-facing systems should be considered high-priority targets. Beyond patching, a defense-in-depth approach is necessary. Enabling authentication is a fundamental step, as it is a prerequisite for exploiting the critical RCE flaw. If Lua scripting is not required for an application’s functionality, it should be disabled. Running the Redis process with a non-root user account and implementing strict network-level access controls, such as firewalls, can limit the blast radius of a potential compromise.

For the DoS vulnerabilities, configuration changes are key. Administrators should configure the `client-output-buffer-limit` parameter to restrict buffer sizes and mitigate CVE-2025-21605. The most effective mitigation for all network-based attacks is to avoid exposing Redis instances to the public internet entirely. For the client library vulnerability in Go, developers must ensure they are using patched versions of the `go-redis` library. Continuous monitoring of memory usage, CPU utilization, and latency is also recommended to detect and respond to potential abuse or performance-related security issues.

Conclusion

The disclosure of CVE-2025-49844 serves as a critical reminder of the persistent risks associated with widely deployed data storage systems. The combination of a severe RCE flaw, additional DoS vulnerabilities, and active targeting by malware campaigns necessitates prompt and comprehensive action from the security community. Patching remains the most effective immediate response, but long-term security requires a holistic strategy involving strict access controls, network segmentation, and robust monitoring. The Redis team’s response, including their transparent rationale for not patching CVE-2025-48367, provides clear guidance for administrators to harden their systems against these specific threats.