Redis RESTORE Flaw Exploited in the Wild: Patch or Block It

Honeypots caught attackers exploiting CVE-2026-25243 in Redis on 16 and 17 October 2026. The bug sits in the RESTORE command, which rebuilds a key from DUMP data. A crafted payload triggers invalid memory access that can become remote code execution for any authenticated user who can run RESTORE. Redis 8.6.3 fixes it. An ACL rule that blocks RESTORE also stops it.

The details here come from Defused honeypot observations reported 20 October 2026, the Redis security advisory published 5 May 2026, and NVD and Red Hat advisories for CVE-2026-25243.

What did the honeypots actually see?

Defused said its Redis decoys recorded repeated scripted attempts overnight and that no prior public report exists of this CVE being attempted in the wild. One attacker hit a decoy five times on a timer with the same payload. Each run ended by wiping the keyspace, which destroyed data and the attacker's own traces. That pattern suggests automated testing rather than targeted data theft, at least in the honeypot sample.

Why does an authenticated bug still matter?

RESTORE is an ordinary command. On an exposed Redis with no requirepass, any connected client can run it. On an instance with authentication, any application credential mapped to a Redis user with RESTORE permission can deliver the payload over a normal client connection. No user interaction is needed.

Wiz Research found about 330,000 Redis instances exposed to the internet, with about 60,000 not protected by any authentication at all. Those 60,000 need no credential to reach RESTORE. For the rest, the permission model is the boundary. Many teams grant +@all to the application user because it is simpler than enumerating the commands the app actually needs. That grant implicitly includes RESTORE.

I audited a staging stack last month where the app user had +@all but only needed GET, SET, and DEL. The fix was one line: ACL SETUSER appuser on >strongpass -@all +get +set +del +exists +expire. The same review is the fastest mitigation if you cannot patch today.

What does the payload actually break?

The RESTORE deserializer did not fully validate serialized values before processing them. Length and type fields inside the blob were trusted without bounds checks against the surrounding buffer. A crafted blob could make the parser read or write beyond the intended allocation.

Zeroday Cloud describes two double free paths that share the same primitive: one in legacy hash zipmap conversion where validator and converter disagree on an overlong five byte length, and one in stream loading where two consumers point at the same pending entry. Both end in the same heap corruption. A malformed DUMP payload becomes overlapping objects and then arbitrary write.

What should you patch or block right now?

I ran the checklist against our own Redis fleet this morning. The immediate steps are short and the order matters.

First, inventory every redis-server version you run, including container images and managed service versions. Every branch before 8.6.3 is affected. The fixed versions are 6.2.22, 7.2.14, 7.4.9, 8.2.6, 8.4.3, and 8.6.3. At least one advisory notes that the 8.0 line has no fixed build, so you must move off 8.0 entirely.

Second, upgrade to a fixed release. If you use a Linux distribution package, install the vendor patched build. Red Hat shipped RHSA-2026:26233 and RHSA-2026:26306 for this issue.

Third, if you cannot upgrade today, block RESTORE via ACL. Run ACL SETUSER <user> -restore for users that do not need it. This is the official NVD workaround.

Fourth, check exposure. Redis should not be on the internet. Bind to internal interfaces, require a strong password, and place the instance behind network segmentation that limits which hosts can issue commands. The honeypot data shows scripted attempts survive wiping, which means the attacker will return to the same host.

According to the Redis security advisory, the vulnerability was disclosed in May 2026 yet unpatched servers remain. According to Defused, the October honeypot hits are the first confirmed wild exploitation.

How does this compare to other Redis issues?

This is a deserialization flaw where validator and converter disagree on a corner case encoding. The lesson from too many open files ulimit debugging and connection pool exhausted after scale holds: the validation you assume exists is the one you have not measured for the specific path.

What is the verdict and what remains uncertain?

According to SecurityOnline, the honeypot hits on 16 and 17 October are the first public evidence of wild exploitation. According to Wiz, about 60,000 instances remain unauthenticated on the internet, which makes the authenticated requirement less of a barrier than it sounds.

The verdict is that patching to 8.6.3 or revoking RESTORE removes the vector. The check is not whether your app uses RESTORE. The check is whether any credential that can reach Redis can run RESTORE.

The limitations are threefold. First, CISA has not yet added this CVE to its KEV catalog, so scanners that only track KEV will miss it. Second, the honeypot sample shows repeated attempts but no confirmed data theft. Wider exploitation may look different. Third, the fix is branch specific. Running 8.0 or a distribution package that has not pulled the backport leaves you exposed even if your main app is on 8.6.3 somewhere else.

FAQ

Is my Redis exposed?

If your Redis listens on 0.0.0.0 without requirepass or with a weak shared password, assume it is reachable. The Wiz count of 60,000 unauthenticated internet exposed instances shows how common that posture still is.

Does blocking RESTORE break anything?

Most applications never issue RESTORE. They use SET, GET, DEL, EXPIRE, and streams commands. Audit your app's command usage before removing RESTORE. If your backup or migration tool uses DUMP and RESTORE, give only that specific user the permission and remove it from the default application user.

What about managed Redis?

Check your provider's patch page. Managed versions that track upstream 8.6.3 should already list this CVE as fixed. If your provider tracks 8.0, ask for a migration path to 8.6.3, since 8.0 has no fixed build.

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud

Published on debugly.dev by Rohit Bhadani | Founder of Krova Cloud