On October 3, 2025, Redis published a security advisory for a bug carrying the highest score a vulnerability can get: 10.0 on the CVSS scale, though Wiz notes a few databases list it as 9.9. Wiz researchers found it for Pwn2Own Berlin, reported it to Redis on May 16, and dubbed it RediShell. It is a use-after-free in the Lua interpreter that had been sitting in the Redis source code for roughly 13 years, and it was the first Redis vulnerability ever rated critical. An authenticated user sends a carefully crafted Lua script, manipulates the garbage collector, and breaks out of the sandbox into native code execution on the host. Every Redis version with Lua scripting carried it, and so did Valkey, the popular fork.
The number that stopped me was not the score. It was in Wiz's exposure analysis: about 330,000 Redis instances exposed to the internet, and about 60,000 of them running with no authentication at all. Redis's own advisory states the precondition in a single sentence: "Exploitation of this vulnerability requires an attacker to first gain authenticated access to your Redis instance." Sixty thousand operators had quietly removed the one thing the bug needed to hurt them.
Thirteen years is a long time for memory corruption to sit in software that, by Wiz's estimate, runs in about 75 percent of cloud environments. Redis said it had no evidence of exploitation in Redis Cloud or reported in customer environments, and I believe that. The bug was not patient and it was not well hidden. It was inert, because in every deployment that followed the first line of Redis's own security documentation - "Redis is designed to be accessed by trusted clients inside trusted environments" - a stranger could not reach it. Where that assumption held, thirteen years of exploitable code did nothing at all. Where it did not hold, the same code was a door.
The default nobody chose
Here is the part that changed how I read advisories. Not one of those 60,000 organizations decided to run without a lock. The official Redis container image does not require authentication by default, and Wiz found that 57 percent of cloud environments install Redis as a container image. A developer needed a cache before lunch, pulled the image, published a port, and every downstream choice - no password, all commands available, Lua scripting switched on - was made for them, silently, by defaults. The command that started the container is a security decision, usually made by whoever was in a hurry and never revisited. Redis has known this about its users for a decade. Protected mode, which answers only the loopback interface when Redis runs with the default configuration and no password, has existed since version 3.2.0 precisely because so many people leave the port open, and the documentation says outright that an administrator can ignore the warning and disable it.
So on patch day the reflex question across the industry is "what version are we on?" I start one question earlier: who can connect to this port? The version matters, but a patch only travels along a path. A 13-year-old bug cannot reach a port no stranger can dial, and no scanner walks your network asking which of your services answer to the whole internet. CVSS scores the code. It says nothing about reachability, and reachability was decided not by Redis but by whoever typed the command that started the container.
The queue on our own server
Bid Spotlight runs Redis for the job queue that builds promo videos, and checking ours has become a habit I would push on anyone who runs anything. Connection first: the container answers on exactly two paths, the host's loopback interface and the private network our own app containers share. There is no route from the internet to port 6379. Version second: Redis 7.4.11, inside the fixed line, since the advisory lists 7.4.6 and above among the patched releases.
And the part I would have left out a few years ago: it has no password. Same default as the 60,000. I used to find that embarrassing to admit in print. I do not anymore, because the lesson of RediShell is not "always set a password." That is good practice and Redis recommends it. The lesson is that the deployment around a service is a security control whether you chose it deliberately or inherited it from a default, and the only honest question is whether you know what yours permits. Ours permits two containers we built and nothing else. The 60,000 permitted anyone with a network connection. Same software, same default, opposite blast radius - and the difference was never in the code.
Ask who can connect before you ask what version. Then come see the sites paying to hold the top spot at bidspotlight.com.