CVE-2025-49844 – Immediate actions for Redis administrators

What breaks and who should care

If you run Redis (or its fork Valkey) in production, you are at risk of a remote code execution flaw that can be triggered by an authenticated user who can run Lua scripts. The vulnerability, identified as CVE-2025-49844, carries a CVSS score of 9.9 – essentially a critical rating. Any service that allows a client to execute EVAL or EVALSHA commands could be compromised.

For the wider picture, our Known Exploited Vulnerabilities tracker lists every flaw CISA has confirmed under active attack.

This is not a theoretical issue. The flaw lives in the core garbage‑collector handling of Lua scripts. By crafting a script that manipulates the collector, an attacker can cause a use‑after‑free condition and, under the right circumstances, execute arbitrary code on the host.

Why the vulnerability is severe

Redis is an in‑memory data store that often runs with high privileges and direct access to the underlying filesystem. A successful exploit could let an attacker escape the sandbox of the Redis process, write files, or even spawn a reverse shell. Because the vulnerability is triggered from within a normal client session, it bypasses many network‑level protections.

The underlying class of the bug is a use‑after‑free in the Lua scripting engine. When the script finishes, the garbage collector frees memory that the engine still believes is valid. A malicious script can then reference that freed memory, corrupting internal structures. The corruption can be shaped into a jump to attacker‑controlled data – classic remote code execution.

The NVD description confirms the issue exists in all Redis releases that support Lua scripting. The fix has been back‑ported to every supported branch, but you must be running the patched release to be safe.

How to tell if you’re exposed

First, determine which Redis version you are running. The quickest way is to ask the server itself:

• redis-cli INFO server – look for the redis_version line.
• On systems with systemd you can also run systemctl status redis and read the version from the service description.

Next, check whether Lua scripting is enabled and whether any ACL rules allow EVAL or EVALSHA for non‑admin users.

• Run redis-cli ACL LIST and scan for entries that contain +EVAL or +EVALSHA.
• If you see those permissions granted to a user that is not the default admin, you have a potential attack surface.

If your version appears in the table below and you have any user able to run Lua scripts, you are vulnerable.

Remediation – upgrade to the patched release

The cleanest fix is to upgrade Redis to the patched release for the branch you are on. In plain terms:

• If you are on the long‑term stable line, upgrade to the latest stable package for that line.
• If you are on a newer feature branch, upgrade to the most recent release in that branch.

Do not try to guess a specific version number – the table below shows exactly which releases are safe. Use your package manager to pull the newest version:

• On Debian/Ubuntu: apt-get update && apt-get install redis-server
• On RHEL/CentOS/Fedora: yum update redis or dnf upgrade redis
• On Alpine: apk upgrade redis

After upgrading, restart the service and verify the version again with redis-cli INFO server. Confirm that the version displayed no longer appears in the vulnerable range of the table.

Mitigation if you cannot upgrade immediately

Sometimes you cannot take a node down for a full upgrade – perhaps you are on a strict maintenance window or the upgrade path is blocked by downstream dependencies. In those cases, you can mitigate the risk by disabling Lua script execution for all non‑admin users.

Redis ACLs give you fine‑grained control over which commands each user may run. To strip Lua capabilities, edit the ACL file or use ACL SETUSER commands. For example:

redis-cli ACL SETUSER username -EVAL -EVALSHA

Replace username with the actual account name. If you have many users, you can create a role that lacks those permissions and assign it en masse.

Another blunt‑force option is to disable Lua entirely in the configuration file. Add or modify the line:

lua-time-limit 0

Setting the time limit to zero tells Redis to reject any attempt to run a Lua script. After editing redis.conf, reload the configuration with redis-cli CONFIG REWRITE or restart the service.

Both mitigations stop the exploit vector, but they also remove legitimate uses of Lua – a feature many applications rely on for atomic operations. Weigh the loss of functionality against the urgency of the threat.

Verification after remediation

Once you have either upgraded or applied a mitigation, run the same checks as before:

• redis-cli INFO server – confirm the version is now in the safe range.
• redis-cli ACL LIST – ensure no non‑admin user has +EVAL or +EVALSHA unless you deliberately need them.

If you chose the configuration‑file route, you can also test that Lua is blocked by trying a harmless script:

redis-cli EVAL "return 1" 0

The server should respond with an error indicating that the command is disabled.

What to do if you discover an exploit in the wild

At the time of writing, there is no public evidence of active exploitation. Nevertheless, the severity warrants a proactive stance. If you spot suspicious activity – for example, unexpected process launches, files appearing in /tmp, or network connections to unknown hosts – treat it as a potential compromise.

Steps to take:

• Isolate the affected host from the network.
• Collect logs: redis-cli MONITOR (if still possible), system audit logs, and any core dumps.
• Perform a forensic snapshot of the filesystem and memory for later analysis.
• Apply the upgrade or mitigation immediately, even if you were planning to do it later.
• Rotate all Redis passwords and ACL secrets, because an attacker who gained code execution could have harvested them.

After containment, conduct a full post‑mortem and consider hardening your deployment: run Redis behind a firewall, bind it to localhost or a private network, and enforce TLS for client connections.

Summary checklist

• Run redis-cli INFO server – note the version.
• Check the table below – if your version is listed as vulnerable, you must act.
• If you can upgrade, do so using your OS package manager and verify the new version.
• If you cannot upgrade, remove EVAL and EVALSHA from all non‑admin ACLs.
• Optionally, set lua-time-limit 0 in redis.conf to block all scripts.
• Confirm the fix by re‑checking version and ACLs, and by testing that a simple Lua script is rejected.

Act now. A critical flaw like CVE-2025-49844 does not wait for a convenient maintenance window.

Version table

The table below lists the affected and fixed releases for Redis and Valkey. Use it as your definitive reference.

Affected versions

Straight from the NVD record for CVE-2025-49844. If your build is inside one of these ranges, treat it as vulnerable.

Product	Affected range	Fixed in
redis	* up to 6.2.20	6.2.20
redis	7.0 up to 7.2.11	7.2.11
redis	7.4.0 up to 7.4.6	7.4.6
redis	8.0.0 up to 8.0.4	8.0.4
redis	8.2.0 up to 8.2.2	8.2.2
valkey	* up to 7.2.11	7.2.11
valkey	8.0.0 up to 8.0.6	8.0.6
valkey	8.1.0 up to 8.1.4	8.1.4