CVE-2025-49844 is a critical (CVSS 9.9) use-after-free in the Lua scripting engine of Redis. An authenticated user can run a crafted Lua script that manipulates the garbage collector and may reach remote code execution. Redis 8.2.2 fixes it. Where you cannot upgrade yet, use ACLs to block EVAL and EVALSHA.
What's affected
Per the record, Redis versions 8.2.1 and below, and the problem exists in all versions of Redis that have Lua scripting. The fixed release is Redis 8.2.2.
The record's product list also names Valkey, the Linux Foundation project that began as a fork of Redis. The description is written about Redis, and I could not confirm Valkey's affected or fixed versions from the sources I reviewed. If you run Valkey, check its own security advisory.
If you run an older Redis branch, such as a 7.x release, check the Redis security advisory GHSA-4789-qfc9-5f9q and the project's release notes for a patch on your branch. The record gives only 8.2.2 as a fixed version.
Managed Redis services from cloud providers patch on their own schedule. Ask the provider, or look for their security bulletin.
How to check if you're exposed
Check the server version:
redis-cli INFO server | grep -E "redis_version|valkey_version"
Check who can run scripts. List the configured ACL users, and see which ones are allowed to call EVAL, EVALSHA or functions:
redis-cli ACL LIST
Any user that can run Lua scripts on a server below 8.2.2 is in scope. Also check which clients and applications connect, and whether the server is reachable from networks beyond the ones that need it.
What to do now
- Upgrade Redis to 8.2.2 or later, or to the patched release for your branch once you have confirmed it in the advisory.
- Where you cannot upgrade right away, use ACLs to remove script commands from users that do not need them. The record's workaround is to restrict EVAL and EVALSHA. An example for one user:
redis-cli ACL SETUSER appuser -eval -evalsha
- Check the advisory for whether other script entry points, such as functions, need the same restriction on your version.
- Make sure Redis is not exposed to the internet, requires authentication, and uses a strong password or ACL users.
- Review which applications call Lua scripts, and test them after any ACL change.
- Look at logs for unusual script activity before you patched.
Why it matters
The weakness is CWE-416, use after free. Memory is released while something still points to it, and later code uses that stale pointer. In a database server that runs user supplied scripts, an attacker who can shape memory may turn that into code execution on the host.
The score of 9.9 reflects what is at stake. Redis often runs with broad network access and holds sessions, queues and cache data, and a compromise of the host reaches whatever else that machine can see. The required condition is that the attacker is authenticated, so exposed instances with no password or weak shared passwords are the most urgent.
Scripting is a common feature to leave open to every client. Reviewing which users really need it is a good control for the next flaw of this kind as well.
The record's KEV flag is false. The record's references include a public repository named for this CVE, but I did not review it and make no claim about exploitation in the wild.
Try it yourself
Click through it at your own pace, or open it full screen.
Quick check
What is the fixed version of Redis for CVE-2025-49844?
Redis 8.2.2, per the record. Check the advisory for patched releases on older branches.
Is there a workaround if I cannot upgrade?
The record says to prevent users from running Lua scripts by using ACLs to restrict EVAL and EVALSHA.
Does it affect Valkey?
The record lists Valkey as a product, but the description speaks only of Redis. Check Valkey's own advisory.
Sources
- Gold entry for CVE-2025-49844
- NVD record for CVE-2025-49844
- Redis advisory GHSA-4789-qfc9-5f9q
- Redis 8.2.2 release
Safeguard has a free in-browser dependency scan at gold.safeguard.sh/scan for the libraries in projects you manage.
Last reviewed: 18 October 2026.
