The short answer: A high-severity flaw in the Redis RESTORE command (CVE-2026-25243, CVSS 7.7) is now being exploited in the wild, according to honeypot data published on October 20, 2026. If you run a self-managed Redis server older than version 8.6.3, upgrade to 8.6.3 immediately. If you cannot patch yet, block the RESTORE command with an ACL rule, enforce strong authentication, and make sure Redis is not reachable from the internet.
The exploit requires an authenticated user with permission to run RESTORE, so it will not hit you from the outside with no credentials at all. But because so many Redis deployments run with weak, shared, or default credentials, that condition is easier to meet than it sounds. Here is what the vulnerability does, how the attacks are playing out, and what to do about it.
What the Redis RESTORE vulnerability is
RESTORE is a standard Redis command. It rebuilds a key from serialized data, usually data that was exported with the DUMP command. It is the kind of administrative utility that most teams rarely think twice about.
CVE-2026-25243 changes that. The flaw is an invalid memory access bug in how RESTORE validates the serialized payload it receives. When Redis processes a specially crafted payload, it reads or writes memory it should not touch. Redis’s own advisory warns that this can lead to a crash (a denial of service) or, more seriously, to arbitrary code running inside the redis-server process, which is remote code execution.
Two researchers found the problem independently and from different angles. Emil Lerner of Wiz Research identified a double-free condition in the RESTORE code path, while independent researcher Joseph Surin uncovered an integer overflow and an out-of-bounds read. That variety of trigger points is part of what makes the flaw hard to neutralize without the official patch.
It is part of a bigger RESTORE problem
The October attacks target CVE-2026-25243 specifically, but the same RESTORE command carries two sibling flaws in the extended Redis ecosystem:
- CVE-2026-25588 (CVSS 7.7): the same class of invalid memory access when RESTORE is used with the RedisTimeSeries module.
- CVE-2026-25589 (CVSS 7.7): the same flaw through the RedisBloom module.
All three were disclosed together in Redis’s May 2026 security advisory, along with two other flaws including a use-after-free in the unblock client flow (CVE-2026-23479). The advisory covered fixes in Redis 8.6.3 and equivalent patched releases. If your deployment uses RedisTimeSeries or RedisBloom, you need those module updates as well, not just the core server fix.
How the real-world attacks work
On October 16 and 17, 2026, the threat intelligence firm Defused reported that its Redis honeypots recorded repeated, scripted exploitation attempts against CVE-2026-25243. According to Defused, no earlier public report exists of this CVE being attempted in the wild, which means the window between disclosure (May 2026) and active exploitation (October 2026) has now closed.
The attack pattern observed in the honeypots is worth studying:
- The attacks were scripted and repeatable, not manual probing. One attacker hit the same decoy five times on a timer with the identical payload.
- Each run ended with the attacker wiping the keyspace, destroying the data and erasing its own traces in one move.
- The attack requires valid credentials plus RESTORE permission, so these were not blind internet scans. The attackers had already gotten past authentication somewhere.
This fits a familiar pattern in database and server-side attacks: weak credentials open the door, and a memory-corruption bug turns that foothold into full compromise. Similar credential-to-exploit chains have powered recent high-profile incidents, from the Tensorlake npm compromise to the GhostAction credential theft wave.
Who is at risk
According to Redis, the problem affects all Redis versions. The fixed release is 8.6.3, so anything earlier is vulnerable. Specifically at risk:
- Self-managed Redis OSS, Community Edition, and Redis Software deployments running versions before 8.6.3.
- Servers exposed to the internet or to untrusted network segments.
- Deployments with weak, shared, or default authentication, since RESTORE requires an authenticated session.
- Multi-tenant environments where a lower-privileged user might be granted RESTORE rights they do not need.
Redis Cloud customers are already protected automatically. The exposure sits with the people running their own servers, which is most of the install base worth worrying about.
How to fix it right now
Do these in order. The patch is the only complete fix; the rest buys you time.
1. Upgrade to Redis 8.6.3
This is the official remediation. Upgrade your Redis server to 8.6.3 or newer. If you run a Linux distribution package, apply your vendor’s backported patch. Do not assume the package manager build includes it; check the changelog.
2. Restrict the RESTORE command with ACLs if you cannot patch yet
Redis ACLs let you disable or rename commands for specific users. If an immediate upgrade is not possible, add an ACL rule that blocks RESTORE for every user that does not genuinely need it. Something like -@all +@connection style rules, or explicitly denying RESTORE per user, is a workable stopgap. Remember that stopgaps like this have been the difference between being exploited and staying safe in recent WordPress and server flaws too, for example the emergency ACL-style mitigations seen during the Bricksforge WordPress flaw response.
3. Lock down authentication and network exposure
- Set a strong, unique password (or better, use Redis ACL users with least-privilege roles) on every instance.
- Never expose Redis to the internet. Bind it to localhost or a private interface, and gate remote access behind a VPN or private network.
- Audit which users have the RESTORE command available and remove it where it is not needed.
4. Watch for signs of compromise
Given the observed attack pattern, look for unexpected keyspace wipes, unexplained redis-server restarts, and odd authenticated sessions in your logs. A keyspace that emptied itself overnight deserves an incident-response look, not just a shrug. If you suspect compromise, treat it like the serious incidents it resembles and rotate credentials after rebuilding from a known-good backup.
Why this one deserves attention
Redis sits behind an enormous share of web applications as a cache, session store, and queue. A memory-corruption flaw that is authenticated-only might sound contained, but the honeypot data shows attackers already have the playbook. Five months passed between disclosure and the first observed exploitation. That is roughly the grace period admins get now: long enough to patch comfortably, short enough that skipping it is reckless.
CISA has not yet added CVE-2026-25243 to its Known Exploited Vulnerabilities catalog, but that is a trailing indicator, not a forecast. The safest assumption is that any CVE with a public report of in-the-wild exploitation is on someone’s target list. It also joins a long October patch list worth catching up on, from the 31 Progress MarkLogic flaws to the month’s enterprise security updates.
Frequently asked questions
What is CVE-2026-25243?
CVE-2026-25243 is an invalid memory access vulnerability in the Redis RESTORE command. An authenticated user with RESTORE permission can send a crafted serialized payload that triggers memory corruption, potentially leading to remote code execution in the redis-server process. It is rated CVSS 7.7 (High).
Which Redis versions are affected?
All Redis versions before 8.6.3 are affected, according to Redis’s security advisory. The fixed version is 8.6.3. Redis Cloud customers are protected automatically.
Is CVE-2026-25243 being exploited in the wild?
Yes. On October 16 and 17, 2026, the threat intelligence firm Defused recorded repeated scripted exploitation attempts against its Redis honeypots. It reported that no prior public report existed of this CVE being attempted in the wild.
Can an attacker exploit it without a password?
No. Exploitation requires an authenticated session with permission to run the RESTORE command. However, many Redis deployments use weak or shared credentials, which significantly reduces the practical protection that login requirement offers.
How do I mitigate CVE-2026-25243 without upgrading?
Use Redis ACL rules to block the RESTORE command for all users that do not need it, enforce strong unique authentication, and remove any internet exposure of the Redis server. These are temporary measures; upgrading to Redis 8.6.3 is the only complete fix.