You are affected if you self-manage Redis OSS, Community Edition, Stack or Software with Lua scripting and run a release older than the fixed ones, which include 8.2.2, 8.0.4, 7.4.6 and 7.2.11. The flaw needs authenticated access, so upgrade and also limit who can run scripts.
What the vulnerability is
CVE-2025-49844 is a use-after-free in Redis's Lua scripting. Redis rates it CVSS 10.0 (Critical). In its advisory, Redis says an authenticated user can run a specially crafted Lua script that manipulates the garbage collector, triggers the use-after-free and can potentially lead to remote code execution. The advisory was published on 3 October 2025.
Two words matter in that description: "authenticated" and "Lua". An attacker first needs to get a connection that is allowed to run scripts. That is why exposure and permissions decide your real risk, even though the score is the maximum.
Which releases are fixed
The advisory lists the fixed releases. Check your exact build against the table below, and read the live advisory because Redis corrected some Software version numbers after first publishing.
| Product | Fixed releases listed by Redis |
|---|---|
| Redis OSS and Community Edition | 8.2.2 and above, 8.0.4 and above, 7.4.6 and above, 7.2.11 and above |
| Redis Stack | 7.4.0-v7 and above, 7.2.0-v19 and above |
| Redis Software | 7.22.2-20 and above, 7.8.6-207 and above, 7.4.6-272 and above, 7.2.4-138 and above, 6.4.2-131 and above |
| Redis Cloud | Already patched by Redis, no action needed |
If you run Redis Software 7.22.2-12 or 7.22.2-14, Redis states those are not fixed and you need 7.22.2-20.
Steps to check and fix
- Find every Redis instance. Include caches inside containers, sidecars, local dev stacks and instances an application team started without telling anyone.
- Record the version of each with the INFO server command or your image tag.
- Compare against the table. Anything below a fixed release on its branch needs an upgrade.
- Upgrade, then restart or roll the instance as your platform requires.
- While you plan the upgrade, reduce exposure: firewall the port, require credentials, and remove script access from identities that do not need it.
Redis's own guidance lists the same three controls: restrict network access, enforce strong authentication, and limit permissions so only trusted identities run Lua scripts or other risky commands. The Redis ACL documentation shows a command category named scripting, so you can deny those commands to an application user that only reads and writes keys.
What to look for if you were exposed
Redis says it has no evidence of exploitation in Redis Cloud or reported in customer environments. It suggests searching your own environment for access from unauthorized or unknown sources, unusual inbound network traffic, unexpected use of the scripting commands, and scripts in the database that nobody recognises.
Try it yourself
Click through it at your own pace, or open it full screen. Notice how a critical score and real exploitability are different questions, and think about which of your Redis instances an attacker could actually reach.
Safeguard's dependency scanning and asset discovery can help you list the software you run, and reachability analysis helps you separate packages that are present from code that actually runs. You can try the free scan on a repository.
Quick check
Does a CVSS 10.0 score mean anyone on the internet can take over my Redis?
No. Redis says exploitation requires authenticated access first. Score and exposure are separate, but an instance reachable from untrusted networks with weak or missing credentials is the case to fix first.
Is upgrading enough, or should I change permissions too?
Do both. Upgrading removes this flaw. Limiting network access and script permissions reduces the damage from the next one.
Sources
Last reviewed: 19 October 2026.
