RediShell (CVE‑2025‑49844)

Overview

A critical remote‑code execution (RCE) vulnerability dubbed RediShell (CVE‑2025‑49844) recently sent
shockwaves through the cloud‑security community. Discovered by the Wiz research team and demonstrated at Pwn2Own Berlin, the bug has been lurking in the Redis in‑memory database for more than 13 years. It arises from a use‑after‑free flaw in Redis’s embedded Lua scripting engine. When an authenticated user sends a specially crafted Lua script, the garbage‑collection routine frees a still‑live object; an attacker can then reuse the dangling pointer to escape the Lua sandbox and run native code on the host. Because Redis does not enable authentication by default, this RCE becomes unauthenticated on misconfigured servers. Wiz estimates that ~330 000 Redis instances are exposed to the Internet and at
least 60 000 of them lack any authentication . With Redis powering about 75 % of cloud environments, the vulnerability’s reach is vast, earning it a CVSS score of 9.9/10

This blog post synthesizes the latest research, proof‑of‑concept (PoC) developments, expert opinions and
real‑world case studies. We provide clear mitigation guidance and position our company as a thought
leader in protecting critical cloud workloads.

What Is CVE‑2025‑49844?

The bug arises from a subtle interaction between Redis’s Lua garbage collector and the parser. When a malicious script manipulates the collector into freeing a TString object that is still being used, a dangling pointer remains and can be reused to inject shellcode. In practical terms this use‑after‑free memory corruption allows an attacker to break out of the Lua sandbox and run arbitrary native code on the host.
After escaping the Lua sandbox, a threat actor gains a powerful foothold. They could open a reverse shell, deploy malware, harvest credentials or pivot deeper into the cloud environment . Because Lua scripts are executed with the privileges of the Redis server, this chain of events can lead to complete compromise of the underlying system.
Every Redis build prior to 8.2.2, 8.0.4, 7.4.6 and 7.2.11 is susceptible to this bug, including all earlier enterprise releases . The maintainers issued security updates on 3 October 2025. Administrators should upgrade to 8.2.2+, 8.0.4+, 7.4.6+ or 7.2.11+ (or the equivalent enterprise versions 7.22.2‑12+, 7.8.6‑207+, 7.4.6‑272+, 7.2.4‑138+ and 6.4.2‑131+) to close the vulnerability.

Proof‑of‑Concept & Exploit Developments

Shortly after the disclosure, security researchers began publishing proof‑of‑concept exploits. One widely cited GitHub repository (“CVE‑2025‑49844”) demonstrates how to bypass common protections such as ASLR, DEP and StackGuard and maintain a persistent backdoor on unpatched versions prior to 7.2.11, 7.4.6, 8.0.4 and 8.2.2 . Another project, a honeypot called reditrap , emulates vulnerable Redis behaviour and logs suspicious EVAL and EVALSHA commands to help defenders spot exploitation attempts . The Hong Kong Computer Emergency Response Team took note of these public PoCs and rated the risk high.
Despite the flurry of PoC activity, there are no confirmed reports of mass exploitation as of this writing. Both SecurityWeek and SC Media confirm that the bug has not yet been weaponized at scale, though researchers warn that the availability of working exploits will accelerate attacker adoptio.

Risk Assessment & Case Studies

Internet‑exposed Redis instances – ~330 000 exposed; ~60 000 with no authentication
Cloud usage – Redis runs in ~75 % of cloud environments
Configuration issues – 57 % of Redis deployments use container images with authentication disabled by default
Risk categories (Wiz assessment) – Critical for internet‑exposed unauthenticated instances; High for internal
deployments with no authentication; Moderate for properly secured internal deployments
PoC availability – Multiple public PoCs and honeypots highlight exploit development
Prior Redis attacks – Previous botnet campaigns (P2PInfect, Redigo, HeadCrab, Migo) exploited misconfigured Redis servers for cryptomining and ransomware . These incidents show how quickly attackers weaponize Redis flaws, underscoring the urgency to patch RediShell.

Case study: In the 2024 P2PInfect campaign, threat actors exploited unpatched Redis servers to deploy Monero miners and even a ransomware module . This demonstrates that misconfigured Redis instances become prime targets for commodity malware. Although CVE‑2025‑49844 has not yet been widely exploited, the combination of a high‑impact RCE and public PoCs makes similar campaigns highly likely.

Expert Opinions & Industry Response

The teams that discovered and analysed RediShell have been unequivocal in their warnings. Wiz, the vulnerability’s discoverer, notes that the flaw grants “full access to the host system,” enabling attackers to exfiltrate data, hijack resources and move laterally . Wiz stresses that internet‑exposed instances without authentication are particularly at risk and should be patched immediately, while internal deployments with proper controls face a lower but still significant threat.

Analysts at Sysdig underline that the bug has been present for more than a decade, pointing out that Redis ships without authentication by default. They observe that proof‑of‑concept tools are progressing and recommend restricting EVAL and EVALSHA commands via ACLs, enabling authentication, running Redis as a non‑root user and disabling Lua scripts when not needed .

The vulnerability has also prompted responses from government agencies. The German Federal Office for Information Security (BSI) and Singapore’s Cyber Security Agency classify RediShell as critical and highlight that there are roughly 4 000 unauthenticated Redis servers in Germany . Hong Kong’s CERT warns that proof‑of‑concept code is publicly available and assigns the vulnerability a high risk rating .

Industry experts such as Piyush Sharma of Tuskira argue that RediShell illustrates the need for proactive exposure management. He advocates for continuous asset discovery to identify misconfigured Redis builds, safe exploitation simulations to validate defences and the removal of Lua privileges for untrusted users. Sharma also urges Redis maintainers to adopt safer defaults and firewall protections.

From the perspective of the Valkey project, lead developer Martin Visser points to flawed memory handling in the Lua interpreter as the root cause, recommending that administrators remove Lua script privileges and enable authentication to mitigate risk.

Security strategist Anders Askasen at Radiant Logic draws a broader lesson: RediShell shows how lapses in configuration management and accrued technical debt can produce severe vulnerabilities. He encourages organizations to deploy identity observability tools to detect misconfigurations before they become catastrophic.

Immediate Actions for Defenders

Defensive posture starts with timely patching. Administrators should upgrade Redis to the latest secure releases—8.2.2 or newer for the 8.x branch, 8.0.4 or newer for 8.0.x, 7.4.6 or newer for 7.4.x, 7.2.11 for 7.2.x and the corresponding enterprise builds. Use your package manager or vendor’s tooling to deploy updates across clusters.

Where immediate upgrades are impossible, temporarily disable the EVAL and EVALSHA commands using Access Control Lists. Limiting script execution to trusted identities reduces the attack surface and prevents untrusted users from triggering the bug.

Enforcing authentication is equally important. Enable the requirepass directive and avoid default “noauth” deployments. For containerized environments, set environment variables to enforce strong passwords. Wiz’s analysis found that 57 % of Redis container images run without any authentication.

Do not expose Redis directly to the Internet. Deploy it behind firewalls or within Virtual Private Clouds (VPCs) and restrict inbound connections to trusted IP ranges. Running Redis under a dedicated, non‑root user and granting only minimal file‑system permissions further reduces the blast radius of a compromise.

If your application does not require Lua or other optional modules, disable them. The RediShell vulnerability is confined to the Lua engine; removing unnecessary functionality eliminates the exploitation vector.

Operational monitoring should be enhanced. Enable verbose logging and watch for anomalies such as unknown scripts appearing in the cache, repeated EVAL or EVALSHA commands, unexpected server crashes with Lua stack traces or file‑system changes. Deploy honeypots like reditrap to capture exploitation attempts and feed alerts to your SIEM.

Network segmentation and zero‑trust architectures offer additional protection. Isolate Redis in dedicated subnets, and use identity‑aware proxies or service meshes to authenticate and authorize every request.

Maintaining an accurate inventory is critical. Use continuous asset discovery tools to scan for all Redis instances—both on‑premises and in containers—and flag misconfigurations. Conduct safe exploitation simulations to validate that patches and configuration changes are effective.

Finally, educate your teams and update your incident‑response playbooks. Teach developers and administrators about secure deployment practices, and ensure your response plans include steps to detect and contain a Redis compromise. If you observe suspicious activity, isolate the affected instance, collect forensic evidence and rotate any exposed credentials immediately.

Our Perspective: Beyond Patching – Building Resilient Redis Deployments

RediShell is a wake‑up call for anyone running Redis. The exploit’s simplicity and the platform’s ubiquity mean attackers will weaponize it quickly. However, the root causes go beyond a single CVE. Redis intentionally ships with no authentication for developer convenience, which means default deployments are insecure and should be treated as vulnerabilities. Organizations need to enforce secure baselines rather than relying on permissive defaults.

Another systemic issue is the lack of visibility. Many DevOps teams spin up containerized Redis instances without central oversight; analysis shows that 57 % of cloud environments run Redis containers without proper hardening . Without asset discovery and central governance, misconfigurations proliferate.

The bug’s presence for more than 13 years illustrates how technical debt accumulates in embedded interpreters. Regular code audits, dependency updates and vulnerability scanning are essential to catch such issues before they become crises.

Finally, identity observability must be part of the defence strategy. As Anders Askasen observes, understanding who and what accesses your data layer is critical . Observability platforms that track user actions and data flows can detect suspicious script execution or lateral movement at an early stage.

How We Can Help

Our company specializes in holistic cloud‑security solutions, and we can assist organizations at every stage of the defence lifecycle. Our continuous vulnerability‑management service automatically identifies and assesses CVEs like RediShell across your entire environment, while our attack‑surface mapping reveals misconfigurations, exposed ports and unauthenticated instances across Redis and other data stores.

We also offer managed detection and response (MDR) capabilities that integrate honeypots to capture exploitation attempts in real time. Our secure configuration baselines provide one‑click deployment templates for Redis with authentication, least‑privilege settings and network segmentation baked in. Should an incident occur, our incident‑response experts can help contain the breach, perform forensic analysis and guide your recovery.

By partnering with us, you ensure that vulnerabilities are addressed promptly, misconfigurations are eliminated and your teams have expert guidance to maintain security hygiene.

Conclusion & Call to Action

CVE‑2025‑49844 (RediShell) underscores a broader truth: configuration matters as much as code. Redis is an indispensable component of modern architectures, and a single misconfigured instance can expose your entire cloud to remote compromise. With public PoCs available and more than 60 000 unauthenticated servers online , time is of the essence.

Don’t wait for attackers to weaponize RediShell in the wild. Upgrade your Redis deployments, harden configurations and implement continuous monitoring today. If you need assistance assessing your exposure or implementing the mitigations outlined above, contact our team. Our experts are ready to help you secure your data layer, strengthen your cloud posture and stay ahead of emerging threats.

Stay safe, stay informed – and let us know how we can help protect your infrastructure.