Redis RESTORE Flaw Is Now Exploited: Patch CVE-2026-25243 and Restrict the Command
Redis RESTORE Flaw Is Now Exploited: Patch CVE-2026-25243 and Restrict the Command
The Canadian Centre for Cyber Security has updated its Redis advisory to say that CVE-2026-25243 is being exploited in the wild. The flaw affects the RESTORE command, which rebuilds a key from serialized data. An authenticated user allowed to run that command can submit a crafted payload that triggers invalid memory access and may lead to remote code execution.
This is not a reason to expose Redis to the internet while “waiting for a patch.” It is a reason to patch immediately, review ACLs, and treat any broadly reachable instance as an exposure management problem.
What is affected
Redis versions before 8.6.3 do not properly validate serialized values processed by RESTORE. The vulnerability has a CVSS 4.0 score of 7.7 and requires an authenticated principal with permission to execute the command. In deployments with weak authentication, overbroad ACLs, or an accidentally public listener, that prerequisite may be easier to satisfy than the score suggests.
Redis says the security release also addresses related memory-safety issues. Operators should use the vendor’s release and platform guidance rather than assuming that upgrading only the server binary is sufficient for managed packages or bundled distributions.
Patch and contain
Upgrade to Redis 8.6.3 or the fixed backport supplied for the Redis branch and operating-system package in use. Then restart the service and verify the running version.
If an immediate upgrade is impossible, remove RESTORE from every user that does not require it. Redis documents ACL-based command restrictions; a temporary control can reduce the attack path, but it does not replace the security update.
Also verify that:
- Redis listens only on intended private interfaces;
- firewall rules and security groups deny public access;
- authentication is enabled and default or unused accounts are disabled;
- ACLs follow least privilege and do not grant dangerous commands broadly;
- network telemetry can identify unexpected clients and command activity.
Hunt for abuse
Because exploitation has been reported, patching should be paired with incident response checks. Review Redis logs, authentication events, ACL changes, configuration changes, and network connections around the first signs of exploitation.
Look for unusual RESTORE activity, newly created users, changes to command permissions, unexpected modules, modified persistence files, and outbound connections from the Redis host. Check application credentials, session stores, queues, and any data reachable from the Redis process for follow-on access.
If Redis was internet-facing or accessible to untrusted tenants, isolate it while preserving evidence. Rotate secrets that could have been read or modified and rebuild the service from a known-good configuration when compromise cannot be ruled out.
The operational lesson
An “authenticated” command vulnerability can become an unauthenticated incident when Redis exposure, weak credentials, or permissive ACLs remove the intended trust boundary. The correct control stack is layered: patch the server, keep it off the public internet, restrict dangerous commands, and monitor for misuse.
References
FAQ
The Canadian Centre for Cyber Security has updated its Redis advisory to say that CVE-2026-25243 is being exploited in the wild. The flaw affects the RESTORE command, which rebuilds a key from serialized data. An authenticated user allowed to run that command can submit a crafted payload that triggers invalid memory access and may lead to remote code execution.