https://github.com/valkey-io/valkey/commit/6dd003e88feace83e...
This code also looks generally fixed in Lua5.4, https://github.com/lua/lua/blame/9ea06e61f20ae34974226074fc6.... Valkey and Redis really need to move to Lua that isn't so old.
There are so many tutorials out there for things like Docker Compose that cause people to bind a service to 0.0.0.0 with a port open to the public internet.
It also likely has yielded far too many (unintentionally) open services, especially considering dockers known firewall woes with bypassing of existing rules.
However, can't you just use e.g. `-p 127.0.0.1:8000:80` since you're aware of the issue? Pretty sure both the CLI and compose support this.
What I do is to only use rootless docker/podman and then forward the ports with nftables rules.
The problem is rather that it is always a deviation from defaults and ime can be easily forgotten/ overlooked.
It also was at the beginning a bit surprising (listening on 0.0.0.0 and inserting an iptables rule that bypassed my ufw ruleset). Many services listen on on 0.0.0.0 by default but they rarely do it while bypassing the normal host firewall mechanisms.
``` ssh -L [<local>:]8000:remote:8000 hopping ```
You can imagine a post-auth Redis vulnerability being deceptively well-exposed, because web apps often give partial control of the Redis key space to attackers, and don't care how long you make your strings. But this one is a UAF that requires attackers to send a malicious Lua script.
I've reread my comment and the parent comment, and I don't understand how this is not clear?
Like, the lua scripting feature is there for developers to write static trusted lua, check it in, and run transactional stuff etc, and so anyone uploading arbitrary user code as a script is already wildly outside of a normal use of redis.
Seems wild that something which requires using the thing wrong, and also which impacts close to 0 real deployments of the thing, gets a CVSS 10.
The aspect that it's only impacting a small percentage of installations in practice does not factor into the severity calculation.
OTOH I'd question the "Privileges required: low" part of the CVSS table. While out-of-box redis is vulnerable, typical deployments are secured by at least a password. Exploitation would need authentication or a separate auth bypass.
Most in-house redis deployments are probably safu if deployed according to best practices but Redis-as-a-service operators want to be on top of this.
The point isn't anything to do with the vulnerability. It's this stupid scale.
While Redis seems vulnerable to this by default, most companies aren't deploying directly to the internet with terribly unsafe default configurations. Like, if you're vulnerable to this, you were already at major risk anyways.
They used this bug in Pwn2Own Berlin 2025, earning a 40,000 bounty in the process [1].
[0] https://www.hexacon.fr/conference/speakers/#rce_in_redis [1] https://www.zerodayinitiative.com/blog/2025/5/16/pwn2own-ber...
There is also an exception with mtls authentication behind a load balancer where the load balancer tanks any kind of malicious / malformed traffic instead of compromising the backend service.
Yes that's bad, but its not critical the way the article implies. For the average website, your average stored XSS is probably more impactful.
If bugs like this can lay hidden for over a decade, maybe it's about time.
If a trivial UAF existed for more than a decade, then I can't wait to see what smorgasbord of memory bugs they introduced with threads.
gizzlon•4mo ago
Would think most forks would be affected as well (?)
TheDong•4mo ago
Do you have your redis exposed without any authentication on the public internet?
If you do either of those, sure, this is bad for you.
I've worked with quite a few redis setups and know the details of even more, I do not know a single redis setup which would be vulnerable to this.
I've never heard a single instance of someone deciding that redis's lua sandbox is secure enough that they'll let their users upload arbitrary lua code and run it, and trust the lua sandbox to keep that redis box safe.
Like, because it's a use-after-free in the lua environment which requires a malicious lua script, this is just such a giant nothing-burger to me and every redis setup I've ever used, all of which only run trusted lua scripts.
bigiain•4mo ago
I will somewhat ashamedly admit to having had a test/development Redis server running on EC2 exploited because I did that. In my defence, it was purely a development/learning exercise and had no real data on it. And it was about 10 years ago. It was an important learning opportunity for me.