CVE-2025-49844 is a CVSS 10.0 vulnerability in Redis, the popular in-memory database provider.  It exists in all versions of Redis with Lua scripting.

The vulnerability allows an authenticated user to craft a Lua script to trigger a use-after-free and potentially launch a remote code execution attack. This can lead to stolen credentials, complete host takeover, and other larger attacks.

How can I protect my team from CVE-2025-49844 and similar attacks?

Because exploitation of this vulnerability requires an attacker to obtain authenticated access to your Redis instance, you can mitigate the risk of an attack by following network security hygiene best practices.

In addition to upgrading, Redis recommends setting up safeguards that keep threat actors away from your Redis instance, such as enforcing strict authentication protocols,  restricting access just to trusted sources and users, and limiting users’ permissions to only the necessary minimum.

How can I fix CVE-2025-49844 in Redis?

The fix for CVE-2025-49844 was introduced in Redis commit d5728cb, authored by user minchopaskal. It ensures safer handling of Lua script names in the parser, which prevents memory misuse that could otherwise lead to remote code execution.

diff --git a/deps/lua/src/lparser.c b/deps/lua/src/lparser.c
index dda7488dcad..ee7d90c90d7 100644
--- a/deps/lua/src/lparser.c
+++ b/deps/lua/src/lparser.c
@@ -384,13 +384,17 @@ Proto *luaY_parser (lua_State *L, ZIO *z, Mbuffer *buff, const char *name) {
   struct LexState lexstate;
   struct FuncState funcstate;
   lexstate.buff = buff;
-  luaX_setinput(L, &lexstate, z, luaS_new(L, name));
+  TString *tname = luaS_new(L, name);
+  setsvalue2s(L, L->top, tname);
+  incr_top(L);
+  luaX_setinput(L, &lexstate, z, tname);
   open_func(&lexstate, &funcstate);
   funcstate.f->is_vararg = VARARG_ISVARARG;  /* main func. is always vararg */
   luaX_next(&lexstate);  /* read first token */
   chunk(&lexstate);
   check(&lexstate, TK_EOS);
   close_func(&lexstate);
+  --L->top;
   lua_assert(funcstate.prev == NULL);
   lua_assert(funcstate.f->nups == 0);
   lua_assert(lexstate.fs == NULL);

If you are a Redis Cloud user, the service was upgraded with fixes on October 3rd.

If you self-manage your Redis instance, you must upgrade to the latest version or find an alternative means of remediation, such as backporting a patch. This means if you use Redis Software or Redis Open Source, you must take action as soon as possible to remediate.

For Redis Software, an official fix is only available for the following versions:

• 7.22.2-12 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

For Redis OSS/CE, an official fix is only available for the following versions:

• 8.2.2 and above
• 8.0.4 and above
• 7.4.6 and above
• 7.2.11 and above

If you are reliant on a version of Redis that cannot be upgraded to one of these releases with breaking changes or a months-long migration process, then this CVE puts you at serious risk of an attack or compliance fines.

Seal Security can help you manage this process with our one-click patches for open source software that give you the security fixes you need, compatible with the code you rely on. In the case of CVE-2025-49844, Seal Security can help you apply the fixes shared in the latest versions of Redis to older versions such as Redis 4 and 5.

This allows you to get the protection you need without any forced upgrades or migrations.

Why Seal Security Is The Answer For Your AppSec Team

It’s no secret: this Redis vulnerability is just another in a long line of critical CVEs that will go on forever. This means that without a strong open source remediation workflow, your team’s security backlog will continue to grow.

Some teams will turn to updates, but an always update approach is imperfect. Not only are these migrations time consuming as your team works to avoid breaking existing code, but in some cases, more vulnerabilities will arrive down the line.

It’s also possible to implement your own manual patching process, trying to create your own backported open source fixes; however, this is a tedious process and can introduce unnecessary risk to your open source stack.

That’s why it’s time for a new approach to open source security. Seal gives you the ability to patch critical vulnerabilities like CVE-2025-49844 at the OS package and base image level, even in legacy or unsupported environments where upstream fixes are no longer available.

The result is countless hours of work saved, dollars in compliance fines avoided, and reduced friction between AppSec and developer teams that now have a solution that works for both of their goals.

Reach out to our team to see how we do it in action today, and stand tall against attacks with CVE-free versions of the libraries, containers, and operating systems.