There’s a serious Redis vulnerability making the rounds: CVE-2025-49844, a use-after-free flaw that allows authenticated attackers to escape the Lua sandbox and achieve remote code execution. We’ve been getting pinged about it since it was announced. Yes, you are impacted even if you migrated from Redis to Valkey.

This vulnerability allows an attacker to break out of their Lua script and maintain control of the host. If the process is running as root, then the individual may even have root access to the machine and do more damage. Potential exploits include deleting data, corrupting / overwriting data, or encrypting data for ransom. This is very scary and very serious.

We have some good news and bad news. The good news is that this 13-year-old bug in the source code is usually not exposed to the internet. People typically have web servers that front their cache deployments. Most of these deployments sit inside a VPC – and random people from the internet cannot inject Lua scripts to exploit this. Generally speaking, if someone can access your cache node and execute a Lua script, they are probably inside your network. Nevertheless, this presents a privilege escalation risk from insider threats.

The bad news is that in our anecdotal experience, we often see customers with deployments inside a VPC do not have authentication configured. The VPC security gives a false sense of safety. Unfortunately, the much bigger security risk is that people / microservices inside a VPC can already do most of the damage without this vulnerability. And if that’s your setup, this bug is really just a wake-up call for a bigger problem.

Even after you patch (and please patch soon), anyone or anything inside your network can connect to Redis/Valkey, run Lua scripts, and do real damage. They can manipulate data continuously. Erase it. Snoop on it. The CVE matters. But the real vulnerability is that an unauthenticated cache node has always been an insider threat.

So if you take one thing from this – put a password on your Redis and Valkey nodes. Right now.

Do that first. Everything else can wait.

About Lua

I’ve never been a fan of embedding scripting engines in infrastructure software. When you start executing user logic in the same process that’s managing your data, you blur the lines between application and system.

Lua inside your cache process was originally meant for good reasons – atomicity, lower latency for multi-command operations, and building custom workflows without client-side coordination. And it worked… until it didn’t with developers getting carried away.

If you’ve ever operated large cache clusters, you know what I mean. Lua scripts can hang on the main thread, hog CPU, or blow through memory limits. They’re hard to monitor, hard to deploy / update safely, harder to debug, and easy to abuse. You end up running unvetted code right next to your critical data, hoping it behaves. That’s a bold bet – if you are wrong, it can crash your server!

And this isn’t the first time Lua in Redis has caused security issues. We’ve seen sandbox escapes before in CVE-2022-0543 and CVE-2015-4335, the pattern isn’t new.

Lua gave Redis incredible flexibility, but it also gave attackers a scripting environment inside your cache. Once you cross that line, every new feature becomes a potential exploit surface. Unfortunately, most “attackers,” in my experience with countless caching outages, end up being well-meaning developers writing a bug in their Lua scripts.

The bigger point

This vulnerability is a reminder that security isn’t just about patching CVEs – it’s about defaults. It’s about asking “what happens when something goes wrong?” and building for that reality.

Wiz found around 330,000 Redis instances exposed online, with at least 60,000 requiring no authentication. That’s the real problem.

So, patch your instances. But also take a hard look at your threat model. Who has access to your internal network? What can they do once they’re in?

And if you’re tired of thinking about this class of problem – authentication, Lua sandboxes, zero-day response cycles – that’s exactly why we built Momento the way we did. We designed for reliability by removing entire categories of failure.

We’re here if you want to talk through it.

P.S. If you need help locking down your cache deployments, reach out to one of us (Khawaja or Allen). We’re happy to help.

Khawaja Shams

Author

Khawaja is the CEO and Co-Founder of Momento. He is passionate about investing in people, setting a bold vision, and team execution. Khawaja has experience at AWS where he owned DynamoDB, and subsequently owned product and engineering for all 7 of the AWS Media Services. He was awarded the prestigious NASA Early Career Medal for his contributions to the Mars Rovers.

Allen Helton

Author

Allen is an Ecosystem Engineer at Momento. He comes from over a decade of experience working in the public sector tech industry where he played a key role in advancing the adoption of modern technology in the space. Allen drives API-first development and pushes for best-in-class developer experience for customers. When he’s not talking about serverless, you can find Allen tending to his homestead. Between feeding the chickens, working in the garden, or building fences, Allen is always outside learning something new and teaching his kids some lessons along the way.