CVE-2022-0543

What it actually does

CVE-2022-0543 is a Debian/Ubuntu packaging flaw in Redis where the embedded Lua interpreter can access Lua modules that should be unavailable inside Redis' sandbox. An attacker who can send Redis commands can use EVAL or EVALSHA to load native Lua libraries such as liblua5.1.so.0 and invoke operating-system functions, escaping the intended Lua sandbox and executing arbitrary commands with the privileges of the redis-server process. Because Redis is commonly deployed as an in-memory data store, successful exploitation can lead to full compromise of Redis data, command execution on the host, malware deployment, lateral movement, and service disruption.

Why it matters to the business

This vulnerability can turn an exposed or reachable Redis service into a direct remote-code-execution entry point. With a CVSS score of 10.0, very high EPSS probability, confirmed exploitation in the wild, and inclusion in CISA KEV with a remediation deadline that has long passed, unpatched Debian- or Ubuntu-packaged Redis instances should be treated as high-priority exposure. Business consequences include theft or manipulation of application data stored in Redis, outage of services depending on Redis, deployment of cryptominers or botnet malware, use of the server as a pivot point, and potential broader infrastructure compromise.

How an attack unfolds

An attacker first identifies a Redis service that is reachable over the network, commonly on TCP port 6379, and determines whether commands can be issued without authentication or with known, weak, or stolen credentials. The attacker then sends a crafted Redis EVAL command containing Lua code that calls package.loadlib to load the system Lua shared library included by the vulnerable Debian/Ubuntu Redis packaging. From that library, the attacker exposes functions such as luaopen_os or luaopen_io, which allow shell command execution or command output retrieval despite Redis' intended Lua sandbox restrictions. The attacker typically runs a simple reconnaissance command such as id, uname, or whoami, then follows with payload staging commands such as curl, wget, chmod, bash, sh, or python to download and execute malware, create persistence, read Redis data, or pivot to other systems. Exploitation requires network access to Redis and the ability to execute Lua scripts, but does not require a separate operating-system account on the server.

How to fix it

Upgrade Redis packages supplied by Debian, Ubuntu, Canonical, or other downstream Linux distributors to versions containing the vendor security fix for CVE-2022-0543. Because this was a Debian/Ubuntu packaging issue, prioritize operating-system package updates rather than only upstream Redis source version comparisons. If immediate patching is not possible, restrict Redis network exposure to trusted application hosts only, block public access to TCP/6379, require strong Redis authentication or ACLs where supported, disable or tightly control dangerous command access, and prevent untrusted users from issuing EVAL/EVALSHA. Run Redis under a dedicated low-privilege account, use systemd/AppArmor/SELinux confinement where available, and monitor for redis-server child processes. After upgrading, restart Redis so the patched package and libraries are loaded. Internet-exposed or unauthenticated Redis instances should be considered potentially compromised and investigated, not merely patched.

How to confirm the fix worked

Confirm the installed Redis package came from a patched Debian/Ubuntu/vendor security advisory by checking the package manager changelog, security tracker, or advisory metadata for CVE-2022-0543. Verify the redis-server service has been restarted after the package update. Confirm Redis is not exposed to the public internet and is bound only to expected interfaces by reviewing redis.conf, systemd unit overrides, firewall rules, cloud security groups, and listening sockets. Attempt a controlled validation from an authorized test host: unauthenticated connections should fail if authentication is required, and EVAL payloads attempting package.loadlib access should not execute operating-system commands. Review Redis ACLs and command restrictions to ensure untrusted clients cannot run Lua scripts. Also validate that host-based controls alert if redis-server spawns shell, downloader, or scripting processes.

Typical attack path

1. Scan for exposed Redis services, commonly TCP/6379.
2. Connect to Redis and test whether commands are accepted without authentication or with guessed/stolen credentials.
3. Run INFO, CONFIG, or simple Redis commands to confirm service behavior and privileges.
4. Send a crafted EVAL or EVALSHA command using package.loadlib to load liblua5.1.so.0.
5. Invoke luaopen_os or luaopen_io from the loaded Lua library to execute operating-system commands.
6. Validate execution with commands such as id, whoami, uname -a, or hostname.
7. Stage a payload using curl, wget, bash, sh, python, perl, or similar tools.
8. Deploy malware, cryptomining tools, web shells, reverse shells, SSH keys, or persistence mechanisms under the redis-server process account.
9. Access or alter Redis data and attempt lateral movement using discovered secrets, cached credentials, application tokens, or network reachability.

How to detect it

Investigate both Redis-layer activity and host-level execution. Redis does not log every command by default, so use available sources such as Redis MONITOR captures, SLOWLOG output, command audit logs from proxies, network packet captures, managed-service audit logs, and application gateway logs if present. Look for EVAL or EVALSHA commands containing package.loadlib, liblua5.1.so.0, luaopen_os, or luaopen_io. On the host, review systemd journal, syslog, EDR process creation telemetry, auditd, shell history where applicable, cron/systemd persistence locations, and outbound network connections from the Redis server. A strong exploitation signal is redis-server spawning child processes such as sh, bash, curl, wget, chmod, python, perl, nc, or miner binaries. Review file creation and execution in /tmp, /var/tmp, /dev/shm, Redis working directories, and user home directories for payloads dropped around the suspected exploitation time. Check for follow-on activity such as new SSH authorized_keys entries, suspicious cron jobs, unexpected systemd services, outbound connections to unknown IPs, high CPU utilization from mining processes, and Redis data access anomalies. Because the vulnerability has been exploited in the wild and the KEV remediation date has passed, absence of Redis command logs should not be treated as proof of non-exploitation; rely on endpoint, network, and persistence hunting as well.

• package.loadlib
• liblua5.1.so.0
• luaopen_os
• luaopen_io
• EVAL package.loadlib
• EVALSHA package.loadlib
• /usr/lib/x86_64-linux-gnu/liblua5.1.so.0
• /usr/lib/aarch64-linux-gnu/liblua5.1.so.0
• /usr/lib/arm-linux-gnueabihf/liblua5.1.so.0
• redis-server -> /bin/sh
• redis-server -> /bin/bash
• redis-server -> /usr/bin/curl
• redis-server -> /usr/bin/wget
• redis-server -> /usr/bin/chmod
• redis-server -> /usr/bin/python
• redis-server -> /usr/bin/perl
• redis-server -> /usr/bin/nc
• redis-server -> /usr/bin/ncat
• redis-server -> /usr/bin/socat
• /tmp/redis*
• /var/tmp/redis*
• /dev/shm/redis*
• CONFIG SET dir
• CONFIG SET dbfilename
• SLAVEOF
• REPLICAOF

What your security team should do

• Immediately identify all Debian- and Ubuntu-packaged Redis deployments, especially internet-facing or broadly reachable instances on TCP/6379.
• Patch affected Redis packages using vendor security updates and restart redis-server services.
• Treat any unpatched, exposed, or unauthenticated Redis instance as potentially compromised and perform forensic review before returning it to service.
• Block public access to Redis and restrict inbound access to approved application hosts using host firewalls, network ACLs, security groups, or segmentation.
• Require strong authentication and Redis ACLs; remove anonymous or shared administrative access.
• Review whether EVAL/EVALSHA are required and restrict their use where operationally feasible.
• Hunt for Redis Lua sandbox escape activity using command telemetry, Redis SLOWLOG/MONITOR data if available, process creation logs, EDR telemetry, and outbound network connections from Redis hosts.
• Search for redis-server spawning shell, downloader, interpreter, or miner processes, including sh, bash, curl, wget, python, perl, chmod, nc, and cryptomining binaries.
• Rotate secrets that may have been stored in Redis or accessible from the Redis host, including application tokens, session data, credentials, and deployment keys.
• Add continuous exposure monitoring for Redis services and alert on new internet-facing Redis listeners.