CVE-2022-0543: Redis Lua Sandbox Escape RCE Vulnerability

CVE-2022-0543 Overview

CVE-2022-0543 is a critical Lua sandbox escape vulnerability affecting Redis installations on Debian-based Linux distributions. Due to a packaging issue specific to Debian and its derivatives (including Ubuntu), the Lua interpreter bundled with Redis does not properly isolate the sandbox environment. This allows an attacker to escape the Lua sandbox and execute arbitrary code on the underlying system with the privileges of the Redis server process.

The vulnerability stems from how Debian packages Redis with a dynamically linked Lua library instead of the statically linked version used in upstream Redis. This packaging decision inadvertently exposes the package library within Lua, which attackers can leverage to load arbitrary shared libraries and execute system commands.

Critical Impact

This vulnerability enables unauthenticated remote code execution on Debian-based Redis servers. It is actively exploited in the wild and is listed in CISA's Known Exploited Vulnerabilities catalog.

Affected Products

• Redis (all versions on Debian-based systems)
• Canonical Ubuntu Linux 20.04 LTS and 21.10
• Debian Linux 9.0 (Stretch), 10.0 (Buster), and 11.0 (Bullseye)

Discovery Timeline

• 2022-02-18 - CVE-2022-0543 published to NVD
• 2025-11-10 - Last updated in NVD database

Technical Details for CVE-2022-0543

Vulnerability Analysis

This vulnerability represents a Lua sandbox escape that leads to remote code execution. The core issue lies in how Debian packaged Redis with a dynamically linked Lua library rather than using a statically linked version. In upstream Redis, the Lua interpreter is carefully sandboxed to prevent access to dangerous functionality. However, the Debian packaging exposes the package library, which provides mechanisms for loading shared libraries and accessing the underlying system.

When Redis executes Lua scripts (via the EVAL or EVALSHA commands), the sandboxing is supposed to restrict what operations the Lua code can perform. With the exposed package library, an attacker can use package.loadlib() to load the standard C library (liblua5.1.so.0) and then execute arbitrary system commands through the luaopen_os function. This completely bypasses the intended security model of Redis Lua scripting.

The vulnerability is particularly dangerous because Redis servers are often exposed to the network, and many deployments lack authentication. Even authenticated Redis instances are at risk if an attacker can send commands to the server.

Root Cause

The root cause is a Debian-specific packaging decision to dynamically link Lua instead of statically linking it as intended by the upstream Redis project. This exposes the Lua package library within the Redis Lua sandbox, which was supposed to be disabled. The package library provides the loadlib function that allows loading arbitrary shared libraries, effectively defeating the sandbox isolation.

Attack Vector

The attack is conducted over the network by sending specially crafted Lua scripts to a Redis server using the EVAL command. The attack flow involves:

1. Connecting to an exposed Redis server (either unauthenticated or with compromised credentials)
2. Using the EVAL command to execute a malicious Lua script
3. The Lua script accesses the exposed package.loadlib() function to load the Lua shared library
4. The script then uses luaopen_os to gain access to the os library
5. Finally, os.execute() is called to run arbitrary system commands

The attacker achieves command execution with the same privileges as the Redis server process. On many systems, this provides sufficient access to further compromise the host or pivot to other systems on the network.

Detection Methods for CVE-2022-0543

Indicators of Compromise

• Unusual EVAL or EVALSHA commands in Redis logs containing references to package.loadlib or luaopen_os
• Unexpected outbound network connections from the Redis server process
• New processes spawned as children of the Redis server process
• Presence of cryptocurrency miners or other malware installed via Redis exploitation
• Modified system files or new user accounts created by the Redis user

Detection Strategies

• Monitor Redis command logs for EVAL commands containing suspicious Lua code patterns such as package.loadlib, luaopen, or os.execute
• Implement network detection rules for Redis protocol traffic containing exploit-related strings
• Deploy endpoint detection and response (EDR) solutions to monitor for suspicious process spawning from Redis
• Use file integrity monitoring on critical system files accessible by the Redis user

Monitoring Recommendations

• Enable Redis command logging and forward logs to a SIEM platform for analysis
• Configure network monitoring to detect unexpected traffic patterns from Redis servers
• Set up alerting for any child processes spawned by the Redis server process
• Monitor for changes in Redis configuration files that could indicate compromise

How to Mitigate CVE-2022-0543

Immediate Actions Required

• Update Redis packages immediately using your distribution's package manager (apt update && apt upgrade redis-server)
• If updates are not immediately available, disable remote access to Redis by binding to localhost only
• Enable Redis authentication using the requirepass configuration directive
• Review Redis logs for evidence of exploitation attempts
• Isolate affected systems from the network until patching is complete

Patch Information

Security updates addressing CVE-2022-0543 have been released for affected Debian-based distributions. Debian has issued DSA-5081 with patched Redis packages. Ubuntu users should apply updates from Canonical's security repositories. The fixes modify how Lua is packaged to properly isolate the sandbox and prevent access to the package library.

For additional technical details, refer to the Debian Bug Report and the original vulnerability disclosure.

Workarounds

• Bind Redis to 127.0.0.1 or a Unix socket to prevent remote access until patching is possible
• Enable authentication with a strong password using the requirepass directive
• Use firewall rules to restrict access to the Redis port (default 6379) to trusted IP addresses only
• Rename or disable dangerous commands using Redis rename-command configuration
• Consider running Redis in a container or with restricted system capabilities to limit exploitation impact

# Restrict Redis to localhost only
echo "bind 127.0.0.1" >> /etc/redis/redis.conf
echo "requirepass YOUR_STRONG_PASSWORD_HERE" >> /etc/redis/redis.conf
systemctl restart redis-server