In October 2025, Redis maintainers disclosed CVE-2025-49844, a use-after-free in the embedded Lua interpreter that allows an authenticated attacker with EVAL privileges to escape the sandbox and execute arbitrary code as the Redis process. Tracked publicly as "RediShell" by Wiz Research, the flaw carries a CVSS v3.1 score of 8.8 and affects every Redis release from 7.2.0 through 7.2.5, plus 7.4.0 through 7.4.1. This analysis walks through the root cause, the affected version matrix, MITRE ATT&CK mapping, a working Sigma rule, and the exact patch path defenders should apply.
Background: What RediShell Actually Is
CVE-2025-49844 is a use-after-free (UAF) vulnerability in the Lua scripting subsystem that Redis embeds for the EVAL, EVALSHA, and FCALL commands. The bug lives in how Redis 7.2+ handles garbage collection of Lua userdata objects that wrap Redis module types. When a Lua script allocates a module-backed userdata object, drops the final reference, and then triggers a GC cycle from inside the same script, the object is freed while a stale pointer remains reachable from the Lua stack. A subsequent operation dereferences that dangling pointer.
Wiz Research, which named the bug RediShell, demonstrated that a crafted Lua payload can turn the UAF into controlled memory corruption and ultimately into code execution in the context of the redis-server process. Because Redis is very often run as root inside containers or as a privileged systemd unit, code execution in the server process is effectively host-level compromise on many deployments.
The CVSS v3.1 vector published by the Redis team is CVSS:3.1/AV:N/AC:L/PR:L/UI:N/S:U/C:H/I:H/A:H, giving a base score of 8.8. The PR:L reflects that the attacker needs a valid authenticated session with permission to invoke EVAL — a permission that is granted by default to any client that can authenticate, because the default Redis ACL user has +@all unless an operator has tightened it.
Per the Redis GitHub security advisory GHSA-4c69-4c5w-9q8p, the flaw is rated High and affects all 7.2.x and 7.4.x releases up to and including 7.2.5 and 7.4.1.
Affected Versions and the Patch Matrix
The vulnerable range is narrow but consequential because Redis 7.2 and 7.4 are the two most widely deployed branches in managed cloud offerings and self-hosted enterprise caches. The official advisory lists the following fixed versions:
- Redis 7.2.6 — fixes CVE-2025-49844 on the 7.2 branch
- Redis 7.4.2 — fixes CVE-2025-49844 on the 7.4 branch
- Redis 8.0.0 and later — not affected; the Lua sandbox was reworked
Redis 6.x and earlier do not contain the module-userdata GC path that introduces the bug, so they are not in scope. Valkey, the Linux Foundation fork, inherited the same code path and shipped its own fix in Valkey 7.2.7 and 8.0.2 — operators running Valkey should track Valkey's security advisories rather than the Redis feed.
Managed services followed quickly. AWS ElastiCache and MemoryDB customers were notified through the AWS Health Dashboard, Azure Cache for Redis published a fix timeline in the Microsoft Security Update Guide, and Google Cloud Memorystore issued a maintenance window notification. If you run Redis through a managed provider, confirm the engine version in the console rather than assuming the provider has patched silently.
Attacker TTPs: From EVAL to Shell
The exploitation path maps cleanly onto MITRE ATT&CK. The initial access vector depends on how the attacker reached Redis in the first place — misconfigured instances exposed to the internet are still common, and credential reuse from leaked config files is a frequent secondary path.
- T1190 — Exploit Public-Facing Application: sending the crafted Lua payload over the Redis protocol to a reachable
redis-server. - T1059.004 — Command and Scripting Interpreter: Unix Shell: once the UAF is weaponized, the attacker's Lua script calls into libc to spawn
/bin/sh. - T1055.001 — Process Injection via Module Loading: in the Wiz proof-of-concept, the corrupted userdata table is used to overwrite a function pointer that is later invoked by a Redis module callback.
- T1078 — Valid Accounts: the exploit requires an authenticated session; stolen
requirepassvalues or reused ACL credentials are the usual enablers. - T1562.001 — Impair Defenses: Disable or Modify Tools: post-exploitation, the Redis process can disable the
CONFIG SETaudit or rewriteredis.confto persist a rogue module.
Notably, the payload does not need to write a file to disk. The Wiz write-up describes a fully in-memory chain using EVAL with a Lua bytecode blob, which defeats file-integrity monitoring as a primary detection control.
Detection: Sigma Rule for Suspicious Lua EVAL Patterns
Detecting CVE-2025-49844 exploitation is hard because legitimate applications use EVAL constantly. The pragmatic approach is to alert on EVAL calls whose Lua body references process-spawning primitives, or on EVAL invocations from source IPs that are not in your application allowlist. The following Sigma rule targets Redis command logs forwarded through Filebeat or Vector from a redis-server slowlog or audit stream.
title: Potential Redis CVE-2025-49844 Lua UAF Exploitation Attempt
id: 8f4c2b9a-3d71-4e5f-9a2c-1b6e0d7f4a11
status: experimental
description: Detects EVAL/EVALSHA commands whose Lua payload references
process-spawning or os.execute primitives, consistent with RediShell
exploitation attempts against Redis 7.2.x and 7.4.x.
references:
- https://github.com/redis/redis/security/advisories/GHSA-4c69-4c5w-9q8p
author: CybernytronX
logsource:
product: redis
service: command
detection:
selection_cmd:
command|startswith:
- 'EVAL'
- 'EVALSHA'
selection_payload:
script|contains:
- 'os.execute'
- 'io.popen'
- 'package.loadlib'
- 'debug.getregistry'
- 'string.dump'
condition: selection_cmd and selection_payload
falsepositives:
- Legitimate Lua scripts that wrap shell commands for maintenance tooling
level: high
tags:
- attack.t1190
- attack.t1059.004
- cve.2025.49844
Pair the Sigma rule with a network-layer control. Suricata can flag Redis RESP frames that carry an oversized Lua blob, which is a common shape for the exploit payload:
alert tcp any any -> any 6379 (msg:"Redis EVAL with oversized Lua blob (possible CVE-2025-49844)"; flow:to_server,established; content:"EVAL"; depth:4; byte_test:1,>,0,0,relative; pcre:"/EVAL[\x20\x0d\x0a].{512,}/s"; threshold:type both, track by_src, count 3, seconds 60; sid:9000142; rev:1;)
For hosts where you cannot enable command logging, use auditd to watch for execve calls whose parent process is redis-server — that parent-child relationship is almost never legitimate in a hardened deployment.
Mitigation and Hardening
The primary mitigation is straightforward: upgrade. Redis 7.2.6 and 7.4.2 contain the fix, and the patch is small enough that most operators can roll it during a normal maintenance window. If you cannot upgrade immediately, the following compensating controls reduce exposure to near-zero:
- Disable Lua scripting entirely with
CONFIG SET lua-enabled noif your workload does not useEVAL. This is the single most effective stopgap. - Tighten ACLs. Create a dedicated application user that has
+@read +@write -@scriptingand removeEVAL,EVALSHA, andFCALLfrom the default user. The Redis documentation on ACL configuration covers the syntax. - Bind to loopback or a private interface. The default
bind 127.0.0.1is safe; any deployment that has been changed tobind 0.0.0.0without a firewall is a critical finding. - Run Redis as an unprivileged user. The official Docker image already does this; many hand-rolled systemd units do not. Verify with
ps -o user= -p $(pgrep redis-server). - Enable
protected-mode yesand require authentication with a strongrequirepassvalue or TLS client certs.
Redis also recommends that operators review the Redis security guide and treat any Redis instance that is reachable from an untrusted network as a compromised host until proven otherwise.
Why This Matters for Defenders
RediShell is a reminder that the embedded interpreters inside data-plane software are part of your attack surface, not an implementation detail. Redis sits in the trust path of session stores, rate limiters, job queues, and cache layers for a huge fraction of modern web applications, and it is frequently granted broad filesystem and network access because operators assume the Lua sandbox is safe. CVE-2025-49844 demonstrates that assumption was wrong for two full minor versions.
The detection gap is the more durable lesson. Because the exploit is in-memory and uses the same EVAL command your application already sends thousands of times per minute, signature-based detection alone will not catch a careful attacker. Defenders need behavioral baselines: which clients call EVAL, from which source addresses, with what script hashes. If you do not have that baseline today, the patch buys you time — use it to build one.
Finally, the disclosure cadence matters. Redis is maintained by a small core team, and fixes for the 7.2 and 7.4 branches landed within days of each other. Operators running forks — Valkey, KeyDB, Dragonfly — need to verify independently that their upstream has shipped the equivalent fix rather than assuming compatibility.
Sources
- Redis GitHub Security Advisory GHSA-4c69-4c5w-9q8p — authoritative advisory for CVE-2025-49844, including affected versions and fixed releases.
- NVD entry for CVE-2025-49844 — CVSS v3.1 vector and base score, plus reference links.
- Wiz Research: RediShell Redis Lua UAF analysis — technical root cause and proof-of-concept description.
- Redis ACL documentation — guidance on restricting EVAL and scripting commands.
- Redis Security Guide — vendor hardening recommendations referenced in the mitigation section.
Frequently Asked Questions
Does CVE-2025-49844 require authentication?
Yes. The CVSS vector includes PR:L, meaning the attacker needs a valid Redis session with permission to invoke EVAL. In practice this is a low bar because the default ACL user has +@all unless an operator has explicitly restricted scripting commands. Any internet-exposed Redis instance with a weak or reused password is effectively pre-auth from the attacker's perspective.
Is my Redis 6.x instance vulnerable?
No. The use-after-free lives in the module-userdata garbage collection path that was introduced with the Redis 7.2 Lua sandbox rework. Redis 6.x and earlier do not contain the vulnerable code path. If you are still on 6.x, you have other reasons to upgrade, but CVE-2025-49844 is not one of them.
Does Valkey have the same bug?
Valkey inherited the affected code from the Redis 7.2 codebase and shipped fixes in Valkey 7.2.7 and 8.0.2. Operators running Valkey should track the Valkey security advisories directly rather than relying on the Redis feed, since the two projects now maintain separate CVE numbering and patch cadence.
Can I detect exploitation without command logging?
Partially. If you cannot enable Redis command logging, monitor for execve audit events whose parent process is redis-server — that parent-child relationship is anomalous in almost every production deployment. You can also alert on outbound network connections originating from the Redis process to hosts outside your application tier, which is a strong post-exploitation signal.
What is the fastest compensating control if I cannot patch today?
Disable Lua scripting with CONFIG SET lua-enabled no and make the change persistent in redis.conf. This removes the attack primitive entirely for workloads that do not use EVAL. If your application depends on Lua, restrict the default ACL user to -@scripting and create a dedicated scripting user with a network-level allowlist.
How does RediShell compare to prior Redis RCEs?
Earlier Redis RCEs (for example, the well-known CONFIG SET dir plus SAVE technique against unauthenticated instances) required either no authentication or direct filesystem write access. RediShell is different: it is a genuine memory-safety bug in the interpreter itself, exploitable from an authenticated session without any CONFIG abuse. That makes it harder to detect and harder to block with ACL-only hardening.
Need expert help with this?
If RediShell has surfaced gaps in your Redis exposure or your detection coverage, CybernytronX can help. Our team performs targeted Redis and data-plane penetration testing, builds SOC detection content tuned to your environment, and deploys Ethereon, our AI-driven threat detection platform, to baseline legitimate EVAL behavior and flag anomalies in real time. Reach out at cybernytronx.com/contact.html to scope an assessment.