CVE-2025-49844

What it actually does

Redis versions 8.2.1 and earlier contain a use-after-free condition in Lua scripting support. An authenticated Redis user can submit a specially crafted Lua script through EVAL or EVALSHA that manipulates Lua garbage collection and corrupts memory inside the redis-server process. Because the vulnerable code executes in the Redis server context, successful exploitation can crash Redis or potentially achieve remote code execution with the privileges of the redis-server operating-system account. The issue is network exploitable after authentication, requires no user interaction, has low attack complexity, and affects confidentiality, integrity, and availability.

Why it matters to the business

A compromised Redis server can expose cached application data, session tokens, queues, feature flags, credentials, or other sensitive data stored in Redis, and may allow attackers to pivot to connected applications or infrastructure. Exploitation can also take Redis offline, corrupt data, or let an attacker run commands on the host as the Redis service account. The high CVSS score, high EPSS likelihood, weaponized exploit maturity, and reported exploitation activity associated with RediShell-style campaigns make this an urgent patching priority even though it is not currently listed in CISA KEV. Organizations with many Redis deployments, managed containers, downstream packages, or embedded Redis instances should assume broad operational exposure until inventory proves otherwise.

How an attack unfolds

An attacker first obtains valid Redis credentials or access to an account allowed to run Lua scripts. This access may come from exposed Redis services, leaked passwords, weak ACLs, compromised application credentials, or lateral movement from an application host. The attacker connects to Redis over the normal service port and submits a malicious Lua payload through EVAL or EVALSHA. The script manipulates Lua garbage collection behavior to trigger a use-after-free in the Redis process. If exploitation succeeds, the attacker may gain code execution as the redis-server user, crash the process, or use the compromised Redis instance to access data and modify application state. Post-exploitation activity may include dumping keys, changing Redis configuration, writing files where the Redis user has permission, loading malicious modules if allowed, creating persistence through operating-system mechanisms, or using the host as a foothold for lateral movement. Threat reporting references RediShell and RCE campaigns targeting Redis and Valkey-style deployments, so defenders should treat unusual authenticated Lua usage as a high-value signal.

How to fix it

Upgrade Redis to version 8.2.2 or later wherever Redis Lua scripting is present. For source-based deployments, apply the upstream fix at commit 9829bdbfd9e7eeb8fb6c79ce36bcc77a681824b1 or a vendor package that includes it. For listed Alpaquita packages, update linux-lts packages to 6.1.151-r0 for Alpaquita 23 and 6.12.46-r0 for Alpaquita stream where applicable. If immediate patching is not possible, mitigate by using Redis ACLs to deny Lua scripting commands for all users that do not strictly require them, especially EVAL and EVALSHA. Restrict Redis network exposure to trusted application networks only, enforce strong authentication, remove default or shared credentials, disable dangerous administrative commands where not needed, and run Redis under a dedicated low-privilege account with filesystem restrictions. Restart Redis after patching to ensure the fixed binary is running, and update container images, base images, bundled Redis instances, and replicas in addition to primary nodes.

How to confirm the fix worked

Confirm the running Redis version with INFO SERVER and verify redis_version is 8.2.2 or later, or confirm the vendor build includes commit 9829bdbfd9e7eeb8fb6c79ce36bcc77a681824b1. Validate package manager output and container image digests against approved fixed versions. Review ACLs with ACL LIST or ACL GETUSER to confirm untrusted and application users do not have permission to run EVAL or EVALSHA unless explicitly required. Where mitigation is used, test with a harmless Lua command such as a simple return statement and confirm unauthorized users receive a permission error. Ensure all primaries, replicas, failover nodes, development instances, CI services, and embedded Redis deployments are covered. After remediation, restart services if necessary and confirm the active redis-server process path and build match the patched package rather than an older binary left on disk.

Typical attack path

1. Identify an exposed or reachable Redis service running a vulnerable version with Lua scripting enabled.
2. Obtain Redis authentication material or compromise an application/service account that can issue Redis commands.
3. Confirm that the authenticated user is permitted to run EVAL or EVALSHA.
4. Submit a crafted Lua script that manipulates garbage collection and triggers the use-after-free condition.
5. Achieve redis-server crash, memory corruption, or remote code execution as the Redis service account.
6. Dump Redis data, alter keys, modify configuration, attempt persistence, or pivot to adjacent systems.
7. Cover tracks by flushing logs where possible, removing temporary artifacts, or blending activity into normal application Redis traffic.

How to detect it

To determine whether exploitation already occurred, review Redis logs, system journal logs, container logs, Redis SLOWLOG, AOF files, command audit logs from Redis proxies, network telemetry, and EDR process telemetry from Redis hosts. Look for EVAL or EVALSHA activity from unusual users, source IPs, service accounts, times of day, or clients that normally do not use Lua scripting. Correlate Lua command activity with redis-server crashes, segmentation faults, core dumps, restarts, memory corruption messages, or unexplained failovers. Inspect Redis host telemetry for redis-server spawning shells, interpreters, download utilities, or outbound network connections, which are not normal for Redis. Review Redis configuration history and command traces for CONFIG SET, MODULE LOAD, SLAVEOF, REPLICAOF, SAVE, BGSAVE, FLUSHALL, or suspicious writes to filesystem paths, as these may indicate post-exploitation. Examine persistence locations such as cron directories, systemd units, SSH authorized_keys files, temporary directories, and Redis working directories for files owned by the Redis service account or created near suspicious command activity. If AOF is enabled, search historical appendonly files for Lua script bodies and dangerous follow-on commands. If SLOWLOG is enabled, inspect entries containing EVAL or EVALSHA, especially long-running or high-entropy script payloads. In containerized environments, review pod restarts, OOM or crash-loop events, exec activity, image changes, and unexpected network egress from Redis workloads. Because Redis command logging is often limited by default, absence of EVAL/EVALSHA records is not proof of non-exploitation; combine Redis telemetry with host, network, and authentication evidence.

• EVAL
• EVALSHA
• ACL SETUSER
• -EVAL
• -EVALSHA
• NOPERM this user has no permissions to run the 'eval' command
• NOPERM this user has no permissions to run the 'evalsha' command
• SLOWLOG GET
• appendonly.aof
• appendonly.aof.*
• redis-server
• redis-server:6379
• Segmentation fault
• SIGSEGV
• core dumped
• /var/lib/redis/core
• /var/lib/redis/dump.rdb
• /var/lib/redis/appendonly.aof
• CONFIG SET dir
• CONFIG SET dbfilename
• MODULE LOAD
• SLAVEOF
• REPLICAOF
• SAVE
• BGSAVE
• FLUSHALL
• /root/.ssh/authorized_keys
• /var/lib/redis/.ssh/authorized_keys
• /etc/cron.d/
• /var/spool/cron/
• /tmp/redis
• /tmp/redis.so
• redis-server spawned /bin/sh
• redis-server spawned /bin/bash
• redis-server spawned sh
• redis-server spawned bash
• curl http
• wget http
• nc -e
• bash -c

What your security team should do

• Patch or upgrade all Redis deployments to 8.2.2 or later as the top priority because exploit maturity is weaponized and EPSS is high.
• Immediately deny EVAL and EVALSHA through Redis ACLs for users that do not have a documented business requirement for Lua scripting.
• Inventory Redis exposure across hosts, containers, Kubernetes workloads, appliances, development systems, and bundled application components.
• Prioritize internet-facing, partner-facing, shared, multi-tenant, and highly privileged Redis instances for emergency remediation or isolation.
• Rotate Redis credentials if logs show unusual Lua usage, unexpected authenticated access, or evidence of compromise.
• Review Redis ACL design so application users have only the commands and key patterns they require.
• Restrict Redis network access with firewalls, security groups, Kubernetes network policies, or service mesh policy so only approved clients can connect.
• Enable or temporarily collect Redis SLOWLOG, command auditing via proxies, AOF review, packet capture, or MONITOR in controlled short windows to identify suspicious EVAL/EVALSHA activity.
• Hunt for post-exploitation behavior on Redis hosts, including redis-server spawning child shells, unexpected outbound network connections, modified authorized_keys files, suspicious cron entries, or unauthorized Redis configuration changes.
• Treat any Redis crash, segmentation fault, or core dump following authenticated Lua execution as a potential exploitation event and preserve forensic artifacts before rebuilding.