A post-auth memory corruption vulnerability scores a CVSS 10. Shellshock got like a 9.5. These scores don't mean anything.
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.
Agreed, adding to this, if a malicious actor already has the ability to execute arbitrary LUA scripts on your redis instance, then you are probably already pretty screwed.
I've got nothing bad to say about the vuln research here, I'm sure it's a great bug, just this CVSS stuff is a farce and everyone seriously working in the field seems to agree, but we're just completely path-dependently locked in to it.
I believe the context is that the CVE is that this bypasses the sandbox entirely; so in this specific case this is a real, full-blown RCE. Your comment makes it seem at a glance that you're saying it's a DOS at worse.
Thanks for replying, but my comment is not saying that at all -- it's pushing back on someone making the claim that the new CVE is no worse than what could already be done, by pointing out that what could already be done was (presumably) only a DoS, while the new CVE is full RCE.
I've reread my comment and the parent comment, and I don't understand how this is not clear?
The Lua interpreter in Redis doesn’t allow you to run regular code, you can’t event to “print”, not to talk about load libraries as in regular Lua interpreter.
It’s a sanboxed one with very minimal operations you can do
The number of redis setups out there which rely on user-uploaded lua scripts and the lua sandbox being sufficient for that has got to be... close to 0?
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.
IMO, this is rather poor reporting and feels a bit flashy for a security researcher to make a name for themselves.
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.
Basically guaranteed RCE for vulnerable configurations - a severity of 10 seems apt.
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.
Look, I'm not trying to tell you it's not a severe vulnerability. I'm telling you that it is not of a caliber to rank among the most severe vulnerabilities ever discovered, which is what a CVSS score of 10 means. Shellshock, which did not get scored as a "10", is in the top tier of vulnerabilities, far more severe than this one by all appearances, and it too doesn't deserve a 10.
The point isn't anything to do with the vulnerability. It's this stupid scale.
"From time to time I get security reports about Redis. It’s good to get reports, but it’s odd that what I get is usually about things like Lua sandbox escaping, insecure temporary file creation, and similar issues, in a software which is designed (as we explain in our security page here http://redis.io/topics/security) to be totally insecure if exposed to the outside world." -- antirez, 4 Nov 2015, https://antirez.com/news/96
Yep, however people don't configure things properly so many years ago I introduced a middle ground between not listening to * (which makes things harder for users in actual deployment systems) and leaving the server exposed, that is: protected mode. If Redis has the default configuration to bind all the addresses and no auth is configured, it refuses commands and informs you how to configure it properly. This avoided many security problems, and avoid also the feeling I always had as a user of other systems defaulting to binding to only local interfaces, where you need to understand what to do in order to make it reachable from other computers.
That is unfortunate there's so many Redis instances out there that not only are exposed to the public internet (330,000) and don't have authentication configured (60,000). I'm guessing those folks probably didn't even realize their Redis was public.
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.
In hindsight, making the default listening address for port forwards in docker(-compose) 0.0.0.0 instead of 127.0.0.1 was/is such a pain point for me. Every time I work with it for servers as almost always it should not be directly exposed (usually services are behind a host-side NGINX rev proxy).
It also likely has yielded far too many (unintentionally) open services, especially considering dockers known firewall woes with bypassing of existing rules.
Yes, that is also what I apply to compose manifests.
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.
Damn people really love redis, considering everyone running to defend it, just to clarify a few things: You need to configure auth explicitly there is no auth by default, Lua scripts are part of the protocol they aren't uploaded separately to the server or something, they are enabled by default.
Wonder if this effects the Sony PS5? could be a cool way to exploit the system? i remember you could somehow connect to the redis server its running and even execute lua scripts but that was it
Interesting. Curious if anyone has more details on the PS5 Redis server? I did not know there was one running on the PS5; I wonder what the console uses it for.
There's only three things that are acceptable when it comes exposing to public internet: a service load balancer, wireguard and ssh(well... for now).
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.
Why is this bad? Do you run user-authored lua scripts against your redis?
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.
> Do you have your redis exposed without any authentication on the public internet?
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.
A post-auth memory corruption vulnerability scores a CVSS 10. Shellshock got like a 9.5. These scores don't mean anything.
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.
Agreed, adding to this, if a malicious actor already has the ability to execute arbitrary LUA scripts on your redis instance, then you are probably already pretty screwed.
I've got nothing bad to say about the vuln research here, I'm sure it's a great bug, just this CVSS stuff is a farce and everyone seriously working in the field seems to agree, but we're just completely path-dependently locked in to it.
If the Lua "sandbox" is actually a decent sandbox, then the most you could do before was DoS the box. DoS <<<<< RCE
I see downvotes but no explanations why -- what is wrong with my claim?
I believe the context is that the CVE is that this bypasses the sandbox entirely; so in this specific case this is a real, full-blown RCE. Your comment makes it seem at a glance that you're saying it's a DOS at worse.
Thanks for replying, but my comment is not saying that at all -- it's pushing back on someone making the claim that the new CVE is no worse than what could already be done, by pointing out that what could already be done was (presumably) only a DoS, while the new CVE is full RCE.
I've reread my comment and the parent comment, and I don't understand how this is not clear?
The Lua interpreter in Redis doesn’t allow you to run regular code, you can’t event to “print”, not to talk about load libraries as in regular Lua interpreter. It’s a sanboxed one with very minimal operations you can do
The vulnerability appears to _be_ a Lua sandbox escape.
The number of redis setups out there which rely on user-uploaded lua scripts and the lua sandbox being sufficient for that has got to be... close to 0?
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.
Bugs get whatever CVSS the marketing team for the discovering research lab wants them to get. It's literally a Ouija board.
But it says the lua script feature is open by default, so any authenticated (or 60k without auth) can run lua scripts -> use this RCE
How about companies providing Redis as a service?
Someone will probably worm this eventually and we'll see if it has any true impact.
IMO, this is rather poor reporting and feels a bit flashy for a security researcher to make a name for themselves.
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.
The difference is meaningless. Both scores are high enough to warrant a significant response. For that, the score is fine.
fwiw, they're using CVSSv3. In CVSSv4, it's probably an 8.7: https://www.first.org/cvss/calculator/4-0#CVSS:4.0/AV:N/AC:L...
Basically guaranteed RCE for vulnerable configurations - a severity of 10 seems apt.
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.
Look, I'm not trying to tell you it's not a severe vulnerability. I'm telling you that it is not of a caliber to rank among the most severe vulnerabilities ever discovered, which is what a CVSS score of 10 means. Shellshock, which did not get scored as a "10", is in the top tier of vulnerabilities, far more severe than this one by all appearances, and it too doesn't deserve a 10.
The point isn't anything to do with the vulnerability. It's this stupid scale.
"From time to time I get security reports about Redis. It’s good to get reports, but it’s odd that what I get is usually about things like Lua sandbox escaping, insecure temporary file creation, and similar issues, in a software which is designed (as we explain in our security page here http://redis.io/topics/security) to be totally insecure if exposed to the outside world." -- antirez, 4 Nov 2015, https://antirez.com/news/96
Yep, however people don't configure things properly so many years ago I introduced a middle ground between not listening to * (which makes things harder for users in actual deployment systems) and leaving the server exposed, that is: protected mode. If Redis has the default configuration to bind all the addresses and no auth is configured, it refuses commands and informs you how to configure it properly. This avoided many security problems, and avoid also the feeling I always had as a user of other systems defaulting to binding to only local interfaces, where you need to understand what to do in order to make it reachable from other computers.
That is unfortunate there's so many Redis instances out there that not only are exposed to the public internet (330,000) and don't have authentication configured (60,000). I'm guessing those folks probably didn't even realize their Redis was public.
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.
In hindsight, making the default listening address for port forwards in docker(-compose) 0.0.0.0 instead of 127.0.0.1 was/is such a pain point for me. Every time I work with it for servers as almost always it should not be directly exposed (usually services are behind a host-side NGINX rev proxy).
It also likely has yielded far too many (unintentionally) open services, especially considering dockers known firewall woes with bypassing of existing rules.
I agree that it's a bad default. So is their iptables meddling when nftables exists.
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.
Yes, that is also what I apply to compose manifests.
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.
You can but the __default__ should be the safer option.
It's not only docker. ssh forward port forwarding also by default binds to 0.0.0.0, if `<local>` is missing.
``` ssh -L [<local>:]8000:remote:8000 hopping ```
ssh doesn't mess with your firewall though
That sounds like a bigger problem...
To make these numbers meaningful, we would need to compare them to a similar software installations in Internet, like SQL databases.
I believe this will be more detailed in the author following talk at HexaCon [0].
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...
Damn people really love redis, considering everyone running to defend it, just to clarify a few things: You need to configure auth explicitly there is no auth by default, Lua scripts are part of the protocol they aren't uploaded separately to the server or something, they are enabled by default.
Post-auth, so this shouldn't be CVSS 10 (highest possible score), because that implies pre-auth RCE would not be more critical..
Wonder if this effects the Sony PS5? could be a cool way to exploit the system? i remember you could somehow connect to the redis server its running and even execute lua scripts but that was it
Interesting. Curious if anyone has more details on the PS5 Redis server? I did not know there was one running on the PS5; I wonder what the console uses it for.
Feels a little overstated if it requires a malicious lua script.
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.
Exactly, also requires authentication. How can this be 10/10?
There's only three things that are acceptable when it comes exposing to public internet: a service load balancer, wireguard and ssh(well... for now).
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.
Good news that it was found and fixed, but 140 days response time seems rather slow for such a critical vulnerability
probably due to low exposure
"RediShell" is an absolutely horrible name that makes it extremely difficult to search for things.
Interestingly it also breaks into RedisHell too.
i assumed it was intentional
Seems similar in impact to https://nvd.nist.gov/vuln/detail/cve-2021-32626, I wonder why this has a CVE 10.
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.
Lua that isn't too old is not compatible with old Lua, unfortunately.
LuaJIT is mostly compatible with 5.1, our goal is to make it pluggable so you can run with either 5.4 or 5.1.
I'm assuming this is why Ubuntu's unattended-upgrades service uncerimoniously restarted the redis-server process on my machine late September?
Surprisingly high numbers of exposed instances to the internet and unauth
Has anyone started rewriting Redis in Rust yet?
If bugs like this can lay hidden for over a decade, maybe it's about time.
They've been too busy adding multi threading.
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.
I'm assuming this has also been addressed in Valkey and most prominent forks as well.
Looks like the fix was committed three days ago and they cut a release for version 8.1.4.
https://github.com/valkey-io/valkey/commit/6dd003e88feace83e...
https://github.com/valkey-io/valkey/releases/tag/8.1.4
Why would you assume that?
yikes, this is bad
Would think most forks would be affected as well (?)
Why is this bad? Do you run user-authored lua scripts against your redis?
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.
> Do you have your redis exposed without any authentication on the public internet?
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.