Redis (Remote Dictionary Server) and its open source fork Valkey share a scary flaw that can give an attacker full remote code execution. It’s been assigned a maximum CVSS score of 10.0—which is something you don’t often see.
Redis shouldn’t normally be exposed to the internet, but it often is. In today’s SB Blogwatch, we descend a layer.
Your humble blogwatcher curated these bloggy bits for your entertainment. Not to mention: Best of.
What’s the craic? Sergiu Gatlan reports: Redis warns of critical flaw impacting thousands of instances
“Significant threat”
Redis … is an open-source data structure store used in approximately 75% of cloud environments, functioning like a database, cache, and message broker, and storing data in RAM for ultra-fast access. … CVE-2025-49844 is caused by a 13-year-old use-after-free weakness … and can be exploited by authenticated threat actors using a specially crafted Lua script (a feature enabled by default).
…
[It] enables them to escape the Lua sandbox, trigger a use-after-free, establish a reverse shell for persistent access, and achieve remote code execution. … Wiz researchers … dubbed it RediShell, [warning] “This vulnerability poses a significant threat to organizations across all industries.”
And not just Redis. As Dev Kundaliya explains: Tens of thousands at risk of remote code execution attacks
“Immediately”
The issue is … also present in Valkey, an open source fork of Redis. … Experts fear a fresh wave of Redis-targeted attacks leveraging this new exploit.
…
Both Redis and Valkey released patches on Friday, … addressing the flaw in all affected versions. They urge all Redis users, especially those running internet-facing instances, to apply the updates immediately.
Horse’s mouth? Benny Isaacs, Nir Brakha and Sagi Tzadik: Critical Remote Code Execution Vulnerability
“Lateral movement”
A CVSS score of 10.0 [is] a rating rarely seen, with only around 300 vulnerabilities receiving it in the past year. It’s also the first Redis vulnerability to be rated as critical. The score reflects not just the technical severity of remote code execution, but also how Redis is commonly used and deployed.
…
The official Redis container … does not require authentication. Our analysis shows that 57% of cloud environments install Redis as an image. If not installed carefully, these instances may lack authentication entirely, … allowing anyone to query the Redis instance and … send Lua scripts (which are enabled by default). This enables attackers to exploit the vulnerability and achieve RCE.
…
More Redis instances are exposed to internal networks where authentication may not be prioritized, allowing any host in the local network to connect to the database server. An attacker [could] exploit the vulnerability … for lateral movement into sensitive networks.
Really? Yes, really, says fletchowns:
That is unfortunate there’s so many Redis instances out there that not only are exposed to the public internet … and don’t have authentication configured. … 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.
What kind of “folks” are those? VoiceOfTruth thinks it’s the “stupid” ones:
Idiots do this. I cannot think why Redis needs to be exposed to anywhere other than a limited list of permitted hosts. This is not exactly a new concept. Back in the good old days, tcp wrappers blocked access to anywhere but a list of permitted hosts. Firewalls went further. If these people get hacked they need to look in the mirror.
But what of Redis Ltd? EmperorOfCanada ain’t impressed:
I have gone to more than one Redis presentation. They were arrogant *****s. Usually, when I go to presentations given by many tech companies, they are jovial, friendly, and have great handouts. … The Redis people left me with a real sour taste in my mouth. They just bragged about service uptimes, which made me very nervous as they have no safety net underneath if something goes wrong. Then, they tried to sell us ****.
…
I’ve seen warmer Oracle presentations, which were more useful. After seeing their presentations, I stopped using [Redis]. What I discovered is that between basic caching, and Postgres, I end up with better performance, a cleaner codebase, a cleaner architecture, and way faster development. I will never go back.
Did someone say “use after free”? ockside steals an atom or two:
Has anyone started rewriting Redis in Rust yet? … Maybe it’s about time.
The exploit relies on “tricking” Lua’s memory management garbage collector. At which Mike Pellatt eyerolls furiously:
Oh look. Another vuln [in] garbage collection. I’ve got a novel idea: Keep track of the memory you’re allocating, free it when you don’t need it any more. Relying on some underlying runtime monitoring isn’t the way to do that.
Meanwhile, after the toxic open-source licensing volte-face a few months ago, this Anonymous Coward has given up:
Sorry. They’re completely dead to me.
This month, we’re reprising the best of And Finally (because reasons).
You have been reading SB Blogwatch by Richi Jennings. Richi curates the best bloggy bits, finest forums, and weirdest websites—so you don’t have to. Hate mail may be directed to @RiCHi, @richij, @[email protected], @richi.bsky.social or [email protected]. Ask your doctor before reading. Your mileage may vary. Past performance is no guarantee of future results. Do not stare into laser with remaining eye. E&OE. 30.
Image sauce: Georgi Kalaydzhiev (via Unsplash; leveled and cropped)
Recent Articles By Author