A critical sandbox escape vulnerability in Redis, tracked as CVE-2022-0543, has been identified as actively exploited, with threat actors using it to achieve remote code execution on exposed instances. The activity was documented by AlienVault OTX, which published associated malware hashes and artefacts tied to exploitation attempts. The vulnerability stems from a Lua scripting engine flaw that allows attackers to break out of the Redis sandbox entirely and execute arbitrary commands on the underlying host.
Redis is everywhere. It's deployed as a caching layer, session store, and message broker across financial services, government infrastructure, and enterprise environments, often with minimal scrutiny because it's treated as internal plumbing rather than an exposed service. That assumption is exactly what attackers are exploiting here. If your Redis instance is reachable, either directly from the internet or from a compromised internal host, CVE-2022-0543 gives an attacker a clean path to the underlying operating system without needing credentials.
The Lua sandbox in Redis is meant to constrain what scripts can do. This vulnerability breaks that constraint. An attacker can send a crafted Lua script through the EVAL command, escape the sandbox, and run arbitrary OS-level code as whatever user Redis is running under. In a lot of deployments, that's root or a highly privileged service account. From there, lateral movement, data exfiltration, and persistence are all on the table.
What makes this particularly pressing is that Redis instances are frequently left unauthenticated or minimally hardened on internal networks, because teams assume network segmentation is sufficient. Once an attacker has a foothold anywhere inside your perimeter (through phishing, a vulnerable web application, or a compromised endpoint) an unauthenticated Redis instance running a vulnerable version becomes an immediate privilege escalation opportunity. Your attack surface almost certainly includes more Redis exposure than you think.
This vulnerability affects Redis instances where the Lua scripting functionality is available and the package has been installed in a way that exposes certain Lua libraries, specifically, this has been tied to Debian-based and Ubuntu-based distributions, where the Redis package is built with a dynamically linked Lua library. The flaw exists because of how those distributions package Redis rather than a flaw in upstream Redis itself, which means version checking alone won't tell you the whole story.
Any organisation running Redis on Debian or Ubuntu-derived systems that hasn't patched the system-level package is potentially exposed. This includes containerised Redis deployments built on those base images. Sectors with large-scale internal Redis deployments — banking, government, cloud-native enterprises — carry the most risk given the privilege escalation potential and the sensitivity of adjacent systems.
FileHash-SHA256: a8d79f40ddb79de569d778f1c0b832f9cc266b32274b702cff4ba2b8a0dd1549
FileHash-SHA256: 976e3772ffea7499f7c119e956a5a71806f8f054caf174978fa888b254dd22a0
FileHash-SHA256: bae21a944b639ed2c7b70964288131274916a1d52ac906725b39a3e15d243cf0
FileHash-MD5: 65a4a8a24fbd9cd7585d3f843be9210d
FileHash-MD5: a1a35afebb585917675534de3d610c93
FileHash-SHA1: b5c5268ad6b270a446a19387b9813696f6ebc9b6
Run these hashes against your endpoint detection tooling and any file integrity monitoring covering hosts where Redis is deployed. These indicators of compromise are associated with malware artefacts observed in conjunction with exploitation of CVE-2022-0543.
Patch your Redis packages immediately. On Debian and Ubuntu systems, update via your package manager rather than just checking the Redis application version. Run apt-get update && apt-get upgrade redis-server and confirm the patched package version is installed. The vulnerability is in how these distributions package Redis, so upstream version numbers won't be your reliable indicator here.
Audit every Redis instance across your environment. Scan internally for open port 6379 across all network segments, including cloud VPCs, container clusters, and development environments. You may find instances you didn't know were running. Any instance reachable from an untrusted network segment without authentication is a critical finding regardless of patching status.
Restrict access to the EVAL command where Lua scripting isn't required. Redis allows you to disable or rename commands in the configuration file. If your application doesn't use Lua scripting, add rename-command EVAL "" to your redis.conf to remove the attack vector entirely. This is a meaningful mitigation if patching can't happen immediately.
Enforce authentication and network-level controls. Redis should require a strong password via the requirepass directive in redis.conf, and access should be restricted using bind directives to limit which interfaces Redis listens on. Combine this with firewall rules so only authorised application servers can reach port 6379. Neither control alone is sufficient, but together they significantly reduce exposure.
Hunt for the listed file hashes in your environment now. Check endpoint detection and response tooling, SIEM logs, and any file integrity monitoring on Redis host systems for the SHA256, MD5, and SHA1 hashes listed above. If you find matches, treat the host as compromised, isolate it, and begin forensic investigation before attempting remediation in place.
CVE-2022-0543 specifically affects Redis packages on Debian-based and Ubuntu-based Linux distributions, where Redis is built with a dynamically linked Lua library. It's a packaging issue rather than a flaw in upstream Redis, so Windows deployments or installations built from source without that dynamic linking aren't affected in the same way.
If your Redis instance has no authentication configured (which is a common default state) then yes, an attacker who can reach port 6379 can send the malicious EVAL command without credentials. Authentication via requirepass adds a barrier, but it's not a substitute for patching or disabling the EVAL command.
Once outside the Lua sandbox, the attacker can execute arbitrary operating system commands as the Redis process user. Depending on how Redis is deployed, that could mean reading sensitive files, writing new files to disk, establishing persistence mechanisms, or pivoting to other systems accessible from that host.
Yes, if those containers are built on Debian or Ubuntu base images and the Redis package was installed via apt without subsequent patching. Container images don't update themselves. Check your base image versions, rebuild from a patched base, and don't assume that container isolation fully compensates for a remote code execution vulnerability inside the container.
