Redis is a popular open-source, in-memory database that is used everywhere — from caching layers to real-time analytics. But, in early 2024, a critical vulnerability called CVE-2024-46981 was discovered — putting many Redis users at risk of remote code execution (RCE).

In this post, I'll explain in plain English how this vulnerability works, show real exploit code, share ways to protect yourself, and provide references for deeper reading.

What is CVE-2024-46981?

In short:
A bug in Redis Lua scripting allows any authenticated user to craft a special script that tricks the Lua garbage collector and results in arbitrary code execution on the Redis server.

6.2.17

Official advisory:
https://github.com/redis/redis/security/advisories/GHSA-56ff-5m9c-4hgq

How the Exploit Works

Redis lets you run Lua scripts on the server (for atomic operations). But until recently, there was a bug in how Redis handled memory cleanup (the "garbage collector") when running Lua scripts.

If a user submits a specially crafted Lua script, it's possible to confuse the memory handler, freeing objects incorrectly, and ultimately running code of your choosing — as the Redis server user.

In other words: An attacker who can authenticate to Redis can potentially get a shell on your Redis server.

Example Exploit (Simplified)

Below is a stripped-down version of what an exploit might look like. (The real exploit is more complex, but this demonstrates the idea.)

> Note: Never run untrusted code on your server!

-- This is a concept, not an actual working RCE

-- Create a Lua object that triggers use-after-free on garbage collection
local obj = {}
setmetatable(obj, {
    __gc = function(self)
        -- Malicious payload here, in a real exploit
        -- This could trigger arbitrary memory operations
        redis.call("set", "owned", "by attacker")
    end
})

-- Force garbage collection to run
obj = nil
collectgarbage()

The actual public exploit (once released) would use the bug to perform low-level memory tricks — eventually writing a ROP chain or similar payload to run arbitrary code.

The important takeaway: If an attacker can run Lua scripts via the EVAL or EVALSHA commands, they can potentially control your server.

Protecting Yourself

1. Patch Redis!

7.4.2

2. Restrict Lua script execution
If you can't patch right away, stop users from running Lua scripts by blocking EVAL and EVALSHA commands with Redis Access Control Lists (ACLs).

Here’s how to do it

# Connect to redis-cli as an admin user

# For the "default" user, remove access to EVAL and EVALSHA:
ACL SETUSER default -eval -evalsha

# Or for a specific user:
ACL SETUSER alice -eval -evalsha

Check your ACLs

ACL LIST

3. Don’t expose Redis to the internet!
This bug is only exploitable after authentication, but there are tons of Redis servers out there with weak or no passwords. Always use strong, unique passwords, and bind Redis to internal addresses only (e.g., 127...1). If you must expose Redis, use a VPN or firewall.

Key References

- Redis Security Advisory GHSA-56ff-5m9c-4hgq (Official)
- Redis release notes
- CVE Details for CVE-2024-46981
- Upgrading Redis

Summary

CVE-2024-46981 is a dangerous bug in Redis's Lua scripting. Any authenticated user could exploit it to run code of their choice — effectively taking over your server. The best defense is to upgrade to a fixed Redis version ASAP. Until then, restrict access to Lua scripts using ACLs.

If your Redis instance is directly connected to the internet, act even faster.

Stay safe and keep your systems up-to-date!

Did you find this useful?
Follow the official Redis GitHub for security alerts and always keep an eye on your server’s network exposure.


*Note: This writing is original and exclusive for this prompt. Always refer to official security advisories for the most up-to-date information.*

Timeline

Published on: 01/06/2025 22:15:09 UTC