Cybersecurity firm Wiz disclosed a critical-severity vulnerability on October 7, 2025, that had lurked in Redis for 13 years. Designated CVE-2025-49844 and named RediShell, the flaw carries a CVSS score of 10.0 — the maximum possible severity — and potentially exposes 60,000 unauthenticated Redis servers to remote code execution. With approximately 75% of cloud environments relying on Redis and the cryptocurrency industry heavily dependent on cloud infrastructure, this vulnerability demands immediate attention from every security team operating exchanges, wallet services, or DeFi protocols.
The Objective
The goal of this guide is to walk advanced users and security teams through the complete process of identifying vulnerable Redis instances, applying the necessary patches, and implementing defense-in-depth measures to prevent similar vulnerabilities from being exploited in the future. RediShell exploits a use-after-free issue in Redis’s Lua interpreter, allowing authenticated attackers to escape the Lua sandbox and execute arbitrary code. The attacker sends a malicious Lua script to trigger the bug, then deploys a reverse shell for persistent access, enabling credential harvesting, data exfiltration, and lateral movement through the network.
Prerequisites
Before beginning the remediation process, you will need administrative access to all Redis instances in your infrastructure, knowledge of your current Redis versions, network diagrams showing which Redis instances are exposed to the internet or internal networks, and a rollback plan in case patching causes compatibility issues. You should also have monitoring tools in place to detect any signs of compromise — unauthorized access to the database, anomalous traffic patterns, unknown scripting commands, unexpected crashes tracing to the Lua engine, or unusual file system changes.
Step-by-Step Walkthrough
Step 1: Inventory your Redis deployments. Use network scanning tools to identify all Redis instances across your infrastructure. Check for instances exposed to the internet — Wiz reports approximately 330,000 Redis servers are publicly accessible, far more than should ever be the case. Document the version and authentication status of each instance.
Step 2: Apply the patches. Redis has released patched versions for all supported branches: 7.22.2-12, 7.8.6-207, 7.4.6-272, 7.2.4-138, and 6.4.2-131 for managed services, plus OSS/CE versions 8.2.2, 8.0.4, 7.4.6, and 7.2.11 for self-managed deployments. Cloud-managed Redis instances have been automatically updated, but self-managed instances must be upgraded manually.
Step 3: Enforce authentication. Every Redis instance must require authentication, regardless of whether it is exposed to the internet. Configure strong passwords using the requirepass directive or Redis ACLs. The default configuration does not require authentication, which is a critical oversight for any production deployment.
Step 4: Enable protected mode. For OSS and CE deployments, ensure protected-mode is enabled. This configuration prevents external hosts from connecting to Redis unless authentication is explicitly configured, providing an additional safety net.
Step 5: Restrict network access. Use firewalls and network policies to limit Redis access to trusted sources only. Redis instances should never be directly accessible from the public internet. Implement network segmentation so that Redis servers communicate only with the application servers that need them.
Step 6: Audit Lua script usage. Since the vulnerability exploits the Lua sandbox, restrict which users and services can execute Lua scripts. If your application does not require Lua scripting, disable it entirely. If it does, implement strict allowlisting of approved scripts.
Troubleshooting
If you encounter compatibility issues after patching, check the Redis release notes for breaking changes between your previous version and the patched version. Common issues include changes to default configuration values, deprecated commands, and modified behavior in Lua script execution environments. For cloud-managed instances, verify that automatic updates have been applied by checking the instance version in your cloud provider’s console. If your application relies heavily on Lua scripts, test thoroughly in a staging environment before deploying patches to production.
Mastering the Skill
RediShell is a reminder that latent vulnerabilities can persist for over a decade in widely-used software. Building a robust security posture requires continuous vulnerability scanning, automated patch management, and regular security audits that go beyond surface-level checks. The intersection of cloud infrastructure and cryptocurrency creates unique risks — exchanges and DeFi platforms running on cloud infrastructure must treat foundational software like Redis as a critical attack surface. With the crypto market exceeding $3.8 trillion in value, the incentive for attackers to exploit infrastructure-level vulnerabilities will only grow. Security teams that master the discipline of infrastructure hardening will be best positioned to protect their platforms and users.
This article is for educational purposes only and does not constitute professional security advice. Consult with qualified security professionals for infrastructure-specific guidance.
The fundamental value proposition of crypto keeps getting stronger
60K unauthenticated Redis servers on the public internet in 2025. at some point this is just negligence not a vulnerability
13 years in production with a CVSS 10.0 and every static analysis tool missed the Lua sandbox escape. security scanners are theater sometimes
Anya Petrov the Lua sandbox pattern was in academic papers from 2015. nobody in production reads security research until its a CVE
Interesting perspective — I hadn’t considered that angle before
The gap between crypto and TradFi is narrowing fast
60K unauthenticated redis instances exposed to the internet in 2025. at this point you deserve to get popped
60K unauthenticated redis servers on the open internet in 2025 is negligence at this point. no sympathy
13 years in Redis core and the Lua sandbox escape was found by Wiz in 2025. the bug literally predates Bitcoin
60K unauthenticated Redis instances on the public internet in 2025. the CVE is bad but the ops practices are worse
crypto exchanges running unauthenticated redis on cloud infra should be a regulatory violation. thats where customer data lives
cron sweep_ it should be a regulatory violation. exchanges holding customer KYC running unauthenticated redis on cloud is a disaster waiting to happen
75% of cloud environments use Redis and crypto exchanges run heavily on cloud infra. the intersection of traditional infra vulns and crypto asset exposure is massively underestimated
Katya Smirnova crypto exchanges on cloud infra running unauthenticated Redis. the attack surface intersection is enormous and under researched
Ana-Maria Stoica nailed the real issue. crypto exchange security teams focus on smart contracts while their traditional infra is held together with duct tape
Katya Smirnova 60K unauthenticated Redis servers is a scanning script away from a mass compromise event. crypto exchanges better hope their network policies are tight
13 years in production means this bug predates most crypto exchanges. entire stacks were built on top of a vulnerable dependency nobody questioned
Lua sandbox escapes are old news in appsec. cloudflare documented almost the same pattern in 2019. redis running unauthenticated in 2025 though, thats on the ops team not the codebase
seung-min_cho Lua sandbox escapes were documented at defcon 2019. Redis shipping the interpreter enabled by default for 6 more years is negligence not oversight
seung-min_cho exactly. the CVE is serious but 60k unauthenticated instances is the actual headline. you can patch the bug but you cant patch lazy devops
deploy_key_rot_ 60k unauthenticated instances means the CVE is secondary. you can scan shodan and get shell access without exploiting anything