[HN Gopher] RediShell: Critical remote code execution vulnerabil...
___________________________________________________________________
RediShell: Critical remote code execution vulnerability in Redis
Author : mihau
Score : 124 points
Date : 2025-10-06 22:30 UTC (1 days ago)
(HTM) web link (www.wiz.io)
(TXT) w3m dump (www.wiz.io)
| gizzlon wrote:
| yikes, this is bad
|
| Would think most forks would be affected as well (?)
| TheDong wrote:
| 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.
| bigiain wrote:
| > 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.
| tracker1 wrote:
| I'm assuming this has also been addressed in Valkey and most
| prominent forks as well.
| biglyburrito wrote:
| Why would you assume that?
| rpdillon wrote:
| 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
| secondcoming wrote:
| I'm assuming this is why Ubuntu's unattended-upgrades service
| uncerimoniously restarted the redis-server process on my machine
| late September?
| champtar wrote:
| Good news that it was found and fixed, but 140 days response time
| seems rather slow for such a critical vulnerability
| m00x wrote:
| probably due to low exposure
| reconditerose wrote:
| 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.
| antirez wrote:
| Lua that isn't too old is not compatible with old Lua,
| unfortunately.
| reconditerose wrote:
| 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.
| fletchowns wrote:
| 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.
| cozzyd wrote:
| That sounds like a bigger problem...
| c0balt wrote:
| 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.
| sureglymop wrote:
| 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.
| mkesper wrote:
| You can but the __default__ should be the safer option.
| c0balt wrote:
| 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.
| vindex10 wrote:
| 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 ```
| cozzyd wrote:
| ssh doesn't mess with your firewall though
| notnmeyer wrote:
| "RediShell" is an absolutely horrible name that makes it
| extremely difficult to search for things.
| koolba wrote:
| Interestingly it also breaks into RedisHell too.
| notnmeyer wrote:
| i assumed it was intentional
| tptacek wrote:
| 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.
| WatchDog wrote:
| 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.
| tptacek wrote:
| 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.
| akoboldfrying wrote:
| If the Lua "sandbox" is actually a decent sandbox, then the
| most you could do before was DoS the box. DoS <<<<< RCE
| akoboldfrying wrote:
| I see downvotes but no explanations why -- what is wrong
| with my claim?
| chucky_z wrote:
| 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.
| akoboldfrying wrote:
| 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?
| wwsX0r wrote:
| 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
| jamesgeck0 wrote:
| The vulnerability appears to _be_ a Lua sandbox escape.
| TheDong wrote:
| 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.
| tptacek wrote:
| Bugs get whatever CVSS the marketing team for the discovering
| research lab wants them to get. It's literally a Ouija board.
| mrbluecoat wrote:
| Someone will probably worm this eventually and we'll see if
| it has any true impact.
| wwsX0r wrote:
| 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
| baobun wrote:
| 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.
| tptacek wrote:
| 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.
| ylk wrote:
| 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...
| SkyPuncher wrote:
| The difference is meaningless. Both scores are high enough to
| warrant a significant response. For that, the score is fine.
| zb3 wrote:
| Post-auth, so this shouldn't be CVSS 10 (highest possible score),
| because that implies pre-auth RCE would not be more critical..
| bigiain wrote:
| "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
| antirez wrote:
| 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.
| emkoemko wrote:
| 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
| kaladin-jasnah wrote:
| 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.
| wwsX0r wrote:
| Surprisingly high numbers of exposed instances to the internet
| and unauth
| darkamaul wrote:
| 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...
| kachapopopow wrote:
| 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.
| bawolff wrote:
| 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.
| rickette wrote:
| Exactly, also requires authentication. How can this be 10/10?
| ockside wrote:
| Has anyone started rewriting Redis in Rust yet?
|
| If bugs like this can lay hidden for over a decade, maybe it's
| about time.
| VWWHFSfQ wrote:
| 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.
| lyu07282 wrote:
| 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.
___________________________________________________________________
(page generated 2025-10-07 23:01 UTC)