Attackers have been observed trying to exploit a flaw in the Redis RESTORE command that can allow an authenticated user to run code on the server. Security researchers at Defused reported that their Redis decoy systems recorded repeated scripted attempts on 16 and 17 October 2026, in what they described as the first public report of this flaw being attempted in the wild.

The flaw, tracked as CVE-2026-25243, carries a CVSS score of 7.7. It affects the way Redis handles data supplied to the RESTORE command, which rebuilds a key from serialised data. A specially crafted payload can trigger an invalid memory access, which Redis warns could allow arbitrary code to run in the context of the Redis server. Importantly, the attacker must already be logged in and hold permission to run RESTORE, so this is not an unauthenticated internet flaw on a correctly configured system.

Patch and lock down RESTORE access

Redis has published fixed releases, including 8.6.3, alongside patched versions in other supported lines such as 6.2.22, 7.2.14, 7.4.9, 8.2.6 and 8.4.3. Administrators running self-managed Redis should upgrade to a fixed release for their version line. Managed Redis Cloud deployments are patched automatically, according to the vendor guidance.

Where patching cannot happen immediately, access controls narrow the risk. Redis access control lists can restrict the RESTORE command to admin accounts only, and the DEBUG command should be disabled in production. Redis should never be exposed directly to the internet, and weak or shared credentials make the login requirement far less protection than it appears. In one observed honeypot run, the attacker wiped the keyspace, destroying data and its own traces, which underlines why logs and backups matter alongside the patch. The flaw had not been added to the US CISA exploited-vulnerabilities catalogue at the time of reporting.