Redis: the patch had been out for 164 days

On 16 and 17 October, a set of decoys recorded repeated attempts against a Redis flaw. The patch for that flaw was published on 5 May. Between those two dates there are 164 days. We all know plenty about the delay; what is worth looking at is the information in front of whoever decided, during those 164 days, that it could wait. It was two severity scores and one official record. The two scores cannot be compared with each other, and the record still reads today exactly as it did on 6 May.

What exactly breaks

The flaw is CVE-2026-25243 and it lives in the RESTORE command, the one that rebuilds a key from a serialised value. The NVD description, verbatim: "the RESTORE command does not properly validate serialized values. An authenticated attacker with permission to execute RESTORE can supply a crafted serialized payload that triggers invalid memory access and may lead to remote code execution." It is classed as CWE-122, heap-based buffer overflow. The same May batch carried four more: two use-after-free bugs — one in the client unblock flow, one in Lua — and two variants of that same RESTORE when the RedisTimeSeries and RedisBloom modules are in play.

The official mitigation, also verbatim, fits on one line: "restrict access to the RESTORE command with ACL rules." Red Hat puts it more sharply: restrict RESTORE "exclusively to highly trusted and administrative users". That is the useful part of the advisory, and we will come back to it.

A note before moving on, because we found it while cross-checking sources and have not seen it written anywhere: the CVE record describes this flaw as invalid memory access in RESTORE, but the credits in Redis's own advisory attribute the same identifier to something else — a double-free found by Emil Lerner and, on top of that, an integer overflow and an out-of-bounds read in VectorSets, from Joseph Surin. It is the same number for findings that are not the same finding. It does not change what you have to do, but it is worth knowing if you ever try to match an identifier to a line of code.

Two scores that cannot be subtracted

The same CVE carries two different scores depending on who signs them:

The temptation is to read that as a disagreement: one side saying it is hard to exploit, the other saying it is easy. It is not, and the difference matters. The 7.7 is calculated in CVSS 4.0 and the 8.8 in CVSS 3.1, two different rulebooks in which the AC box does not mean the same thing. In 3.1, attack complexity mixed two things together: the defences you have to get around and the deployment conditions that have to hold. 4.0 split them: it left only the first in AC — "evade or circumvent existing built-in security-enhancing conditions", the ASLR and DEP sort of thing — and moved the second out to a new metric, AT.

Now look at the full vector behind the 7.7: AV:N/AC:H/AT:N/PR:L/UI:N/VC:H/VI:H/VA:H. That AT:N means "the attack succeeds under most instances". In other words: whoever assigned the 7.7 said the same thing as the NVD about the only part that affects you — that no unusual conditions are needed for this to work at your place — and marked AC:H because, this being a heap overflow, you have to fight memory protections. For a flaw of that kind, under the 4.0 rulebook, that is the correct answer. There are not two opinions about the world: there are two scales.

And here is the real problem, which belongs to neither Redis nor the NVD but to you and to us: those two numbers end up in the same column of the same spreadsheet, and somebody sorts it high to low. In most places we walk into, the written rule says something like "anything above 9.0 gets patched within 15 days". A 7.7 does not qualify. Nor does an 8.8, in plenty of them. Nobody checks which version of the standard each figure comes from, not least because the tool aggregating them does not say either. A point and a decimal decide the maintenance window, and it turns out that point and that decimal are, in large part, a 2023 change of rulebook.

If what you were after was the box that does predict whether you will be attacked, CVSS 4.0 has one and it is called E, exploit maturity. On this CVE it is undefined, E:X. Nobody filled it in.

The record nobody went back to

There is a third document, and it is the one that has aged worst. On 6 May — one day after the patch came out — CISA logged its SSVC assessment of this CVE with three boxes: exploitation: none, automatable: no and technicalImpact: total. Translated: no exploitation seen, we do not expect it to be automated at scale, but if they get in they take everything.

All three boxes were defensible on 6 May. The one that no longer holds is the first, because what the decoys logged in October is precisely attempted exploitation. And here is what strikes us as important: that record still carries the date 6 May. It is not a live indicator, it is a snapshot — a five-month-old snapshot, taken one day after the patch existed, which is the moment in a CVE's life when least is known about it. If your process consults that box and trusts somebody to update it, your process has a dependency nobody has promised to honour. We gave a whole post to how fast these labels expire: in that vCenter case, "no known exploitation" lasted five days.

"Authenticated" does less work than you think

"Authenticated" is the word that reassures everybody reading the advisory, and in a real Redis it does far less work than it suggests. Start with what is not opinion: the official page for the RESTORE command files it under the ACL categories @keyspace, @write, @slow and @dangerous. Its presence in @write means that any identity you have granted +@write can run RESTORE by definition, not by oversight. If your application writes to Redis, your application can call RESTORE.

Add to that what real installations look like. In most we come across, "authentication" means a single password in requirepass, the same one for everybody who connects, on the default user, which ships with permissions over everything. ACLs with separate users have existed since Redis 6 and they are excellent, but they were still in their wrapper in a fair number of the places we have looked, because nobody asked for them and because the service already worked. So "requires authentication" ends up describing anyone who reaches that port with the password sitting in your application's config file, in a container environment variable, or in a repository from three years ago.

The good news is in the fourth category on that list. If you once applied the idiom Redis's own manual gives as an example — +@all -@dangerous — you are already mitigated against this without ever finding out, because RESTORE falls inside @dangerous. It is the kind of decision taken on an ordinary Tuesday, costs ten minutes, and pays off five months later.

No, you do not have to jump to 8.6.3

Almost all the coverage we have read sums the fix up like this: "affects everything before 8.6.3, upgrade to 8.6.3". If you run a 7.x branch and believe it, you have just turned a maintenance patch into a major version jump, with its window, its testing and its risk.

In fairness, that coverage did not invent it: it copied it from the CVE record. The GitHub advisory that sources the identifier says, verbatim, "this is patched in version 8.6.3", and the NVD captures it with a range marking everything below 8.6.3 as vulnerable. By that range, a 7.2.14 — which is patched — shows up as vulnerable. Anyone repeating "go to 8.6.3" is faithfully quoting a source that falls short. The six fixed branches live somewhere else: in the table in the Redis blog advisory, the document almost nobody opens because the identifier already took them to a different one.

Here are the six. All you have to do is stay on yours:

That is an enormous practical difference. "Upgrade to 8.6.3" is a project; "go from 7.2.13 to 7.2.14" is a Tuesday afternoon. And when the advice going round turns the second into the first, the predictable outcome is not that people do the project: it is that they do nothing.

Your patch is not published by Redis: it is published by your distro

There is a second step that the question "what version am I running?" skips entirely. Almost nobody compiles Redis: they install it from their system's repository. And there the numbers look nothing like the ones above. For this single CVE, Red Hat has published fifteen separate errata (RHSA), because each product line goes its own way: the fixed package on Red Hat Enterprise Linux 9 is redis-6.2.22-1.el9_8, and alongside it live redis:6 and redis:7 modules with their own dates and their own extended support windows.

And a detail almost all the coverage misses: in those same records, Red Hat also tracks this CVE against the valkey package. If you moved to the fork back then to get out of the licence change, the code you inherited came with this inside. It is not a dig at anyone — a fork inherits the entire codebase, the good and the rest — but it is a reminder that the inventory cannot just say "Redis" and leave it there. It has to say which package, from which repository, at which version, and who updates it.

This is not a rare case. When we count where the flaws that actually get exploited really live, the answer is uncomfortable: only one in eight exploited flaws sits in an appliance. The rest are pieces of your application stack — content managers, repositories, document servers, in-memory databases — that nobody feels ownership of because they do not have a vendor sticker on the front of a rack.

If your trigger is the KEV, you are still waiting

Plenty of sensible people have it written down that they act when a flaw enters CISA's KEV catalogue, the one for known exploited vulnerabilities. It is a defensible rule and we think it is a thousand times better than having none. But it is worth knowing what it leaves out: we downloaded the catalogue while writing this — version 2026.10.16, 1,748 entries — and CVE-2026-25243 is not in it, with the decoys already logging attempts.

There is something else in that catalogue worth noting. If you search "Redis" as a vendor, you get a single entry in nearly four years: CVE-2022-0543, added on 28 March 2022, and the product it is filed under is "Debian-specific Redis Servers". That flaw was not introduced by Redis; it was introduced by a distribution's packaging.

And there is a second Redis in the catalogue you will not find by searching for Redis, because it sits inside a Cisco: CVE-2022-20821, added on 23 May 2022, whose description says the IOS XR health check "opens TCP port 6379 by default" and that an attacker can connect to the Redis instance running in that container. Nobody there bought a Redis or wrote it down on any sheet. It came inside. Both times this has reached the known-exploited catalogue, the problem lay not in Redis's code but in the layer that packages it, deploys it, or switches it on without asking — which is precisely the layer the inventory skips.

Per the report: it wiped the database and wiped its tracks

One detail from the decoy report remains, and it is the one that makes this a continuity matter as well as a security one. It is worth being precise about what is reported: attempts, not confirmed code execution. Within those attempts, each pass ended by wiping the keyspace, taking the data with it and, incidentally, its own tracks. If your Redis is genuinely a cache, that is a bad afternoon and a request storm against the database behind it. If it also holds sessions, queues or state — and it holds more than people think — that is an outage with people staring at a screen.

An attacker who takes their tracks with them leaves you with your logs as the only way to reconstruct events. How long they last and where they are tends to get asked on the worst day; the advisory came 47 days late and your logs last 30 is about exactly that countdown.

The five checks

This is what we run to close the matter. It takes under half an hour and it is worth doing even if your branch is already patched, because four of the five are not about this CVE: they are about the next one.

1. What you are actually running. redis-server --version and, from inside, INFO server. Write both down: the version Redis reports and the version of your distribution's package. They are not the same, and the second one is what patches you.
2. How many identities exist. ACL LIST and ACL WHOAMI. If the answer is a single default user with permissions over everything, you now know what the word "authenticated" is worth at your place.
3. Take RESTORE away from whoever does not use it. It is the mitigation the vendor itself publishes, and it is one line: ACL SETUSER myapp -restore for the specific case, or ACL SETUSER myapp on >key ~app:* +@all -@dangerous if you would rather cut the whole category off at the root. Business applications rarely call RESTORE at all: it is used by migration and backup tooling, which is not your API. Before applying it, check your logs to see whether anybody is using it.
4. Who can reach the port. CONFIG GET bind and CONFIG GET protected-mode, and then check it from outside, not on paper. A Redis listening only where it should turns this flaw into an internal problem, which is a very different category.
5. Who owns it. A name next to the word "Redis" on a sheet, with the date it was last updated. If that box is empty, the four checks above will be undone again six months from now.

Who is to blame for the 164 days

Almost nobody, and that is the point. Redis published the fix on the day of the advisory and for six branches. CISA filled in a reasonable record with what was known on 6 May. The NVD did its job and scored in the standard it uses. Nobody lied, nobody was late, and the result was still 164 days. The parts were all fine; what does not work is how they fit together: two scales read as if they were one, a dated record consulted as if it were a live indicator, and a number that ends up deciding a maintenance window without anybody remembering where it came from.

We do not sell Redis licences, or anybody else's, so we can say the obvious: the answer to this is not bought, it is written. It is knowing which data and application pieces hold your business up, having them in an inventory with an owner and a version, and deciding access to each one before it is needed — the part of cybersecurity that appears in no brochure because it is not a product. What we do sell is the work of keeping that alive while the in-house team is busy shipping the product.

The question we close on is not whether you are patched. It is cheaper to answer and says more: how many different applications connect to your Redis today with the same password? If answering it means opening three repositories, you already have the answer, and it is not about Redis.

Sources and method: the flaw description, the publication date (5 May 2026), CWE-122, the two disagreeing CVSS vectors (7.7 in CVSS 4.0 with AC:H from the CNA; 8.8 in CVSS 3.1 with AC:L as the NVD primary score), CISA's SSVC record of 6 May 2026, and the list of affected packages — including valkey — and of the fifteen RHSA errata all come from the CVE-2026-25243 record at the NVD, consulted via its API on 20 October 2026. The six fixed branches and the module versions, as well as the ACL mitigation, come from the Redis security advisory of 5 May 2026 and the 8.6.3 release notes. The "Important" impact rating and the wording of Red Hat's mitigation come from its CVE page. The absence from KEV and the catalogue's single Redis entry (CVE-2022-0543, 28-03-2022) we checked by downloading CISA's KEV catalogue on 20 October 2026: version 2026.10.16, 1,748 entries. The 16–17 October exploitation — Defused decoys, same attacker five times on a timer, keyspace wiped — is taken from a secondary source, the securityonline.info article citing Defused's post; we have not verified it independently and we give it for what it is, a third-party report. We have no telemetry of our own for these attempts. What is ours here is the reading — the AC disagreement as a prediction rather than a fact, what "authenticated" means in a real installation, the unnecessary version jump the circulating advice induces — and the five checks, which are our own. Translations of quoted material are ours.