Redis RESTORE Flaw Can Corrupt Server Memory

What happened

Redis has addressed a memory corruption vulnerability in its Redis product, an in-memory data structure store. Think of it like a receiving clerk who accepts a packed box without checking whether its contents fit safely on the shelf. The affected RESTORE command accepts serialized values, and insufficient checking can allow specially prepared data to cause invalid access to server memory.

The vulnerability is tracked as CVE-2026-25243. An attacker must already be authenticated and have permission to execute RESTORE. Under those conditions, a crafted payload may lead to remote code execution, meaning the attacker could cause code to run on the Redis server.

The vendor's advisory identifies affected Redis OSS/CE releases and provides patched versions across several release branches. NVD published its entry on 2026-05-05 and records a HIGH severity rating. KISA, Korea's Internet & Security Agency, also published an advisory on 2026-10-29.

Technical details

The weakness is memory corruption, classified as CWE-122, Heap-based Buffer Overflow. The heap is an area of memory used for dynamically allocated data. A buffer overflow involves accessing memory beyond the space reserved for a piece of data, which can undermine the server's safe handling of that data.

The root cause is inadequate validation of serialized values supplied to RESTORE. Serialization packages data into a form that software can store or transfer and later reconstruct. Redis does not sufficiently check the affected input before processing it, allowing a crafted value to trigger invalid memory access. The described consequence includes possible remote code execution; that outcome is not stated as inevitable.

The attack preconditions matter: the attacker needs an authenticated Redis connection and authorization to run RESTORE. Authentication establishes who can connect, while command permissions determine what that account can do afterward. An account's ability to connect should therefore be reviewed separately from its ability to execute this command.

NVD records a CVSS 4.0 score of 7.7, rated HIGH. CVSS is a standardized way to describe vulnerability severity. The score supports prioritizing remediation, but it does not establish whether a particular Redis deployment is reachable by an attacker or whether its accounts have the required permissions.

Weakness types: Memory corruption

Who is affected

Everyday users

For everyday users, the relevant component is the Redis server behind an application or service. The update belongs with whoever operates that server. If you manage your own Redis installation, you should check its running version and arrange an update to a patched release.

The described flaw requires an authenticated account with RESTORE permission. Using an application backed by Redis does not, by itself, establish that someone can exploit the issue. The practical questions are which Redis release the service runs and who can access the affected command.

Developers

Developers should review whether application accounts need RESTORE permission. A service account may need to read and write application data without needing every Redis command. Checking those permissions helps determine whether an account meets the vulnerability's stated attack preconditions.

If your application or operational tooling uses RESTORE, include that dependency in update planning. Confirm that the Redis server supporting the application has been updated, and check that authorized workflows still function afterward. Updating application code alone does not establish that the server-side flaw has been fixed.

Server and IT admins

Server and IT administrators should inventory running Redis instances and map each to a patched release branch. The vendor lists 6.2.22 and later, 7.2.14 and later, 7.4.9 and later, 8.2.6 and later, 8.4.3 and later, and 8.6.3 and later as fixed releases in their respective branches.

Review account permissions alongside patch status. An authenticated account with RESTORE access meets the stated permission requirements for the attack, making command authorization relevant to prioritization. Also distinguish the installed Redis executable from the Redis process currently serving requests: checking a local binary alone does not confirm the running service's version.

What to do now

1. Identify the Redis servers supporting your applications and services. Record the running version for each instance so you can match it to a patched release branch.
2. Use the vendor's advisory to select the appropriate fixed release: 6.2.22 and later, 7.2.14 and later, 7.4.9 and later, 8.2.6 and later, 8.4.3 and later, or 8.6.3 and later, according to the branch you use.
3. Review which authenticated accounts can execute RESTORE. Check the vendor advisory for guidance on restricting that command through access control lists, or ACLs, which define account permissions.
4. Follow the update steps in the vendor's advisory. If you use operating system packages, confirm that the available Redis package contains the applicable fix before treating a general package upgrade as remediation.
5. After updating, check the version reported by the running Redis server and confirm that it matches an applicable patched release.
6. Confirm that applications and any authorized RESTORE workflows still operate as expected. Retain any access restrictions that remain appropriate for those accounts.

redis-server --version

redis-cli INFO server

If you can't update yet

• Check the vendor advisory for the RESTORE workaround: restrict access to the command using ACL rules. Review which accounts actually require that permission.
• Check the vendor advisory for guidance on restricting Redis access and reducing internet exposure while an update is pending. These measures supplement patching.

How to confirm the fix

• Check the version reported by the running Redis instance. Match it to the applicable patched branch listed in the vendor's advisory.
• Compare the running server's version with the installed executable's version. Resolve any mismatch before considering the update complete.
• Review effective account permissions to confirm that any intended RESTORE restrictions are in place.
• Confirm normal application behavior and any required, authorized RESTORE workflows after the update.

NVD scores and CISA KEV status

As of October 30, 2026, none of these CVEs is listed in the CISA Known Exploited Vulnerabilities catalog.

Affected products and fixed versions 6 rows

The vendor's advisory is the authority on affected and fixed versions. If a cell says “See the vendor advisory”, check it there.

Frequently asked questions

References

• Redis advisory: https://redis.io/blog/security-advisory-cve202623479-cve202625243-cve-2026-25588-cve202625589-cve-2026-23631/
• NVD: CVE-2026-25243
• CISA Known Exploited Vulnerabilities catalog
• Also reported by KISA (Korea Internet & Security Agency) on October 29, 2026: KISA advisory (Korean)

How this page is made: versions and CVE IDs come from the vendor advisory table; CVSS scores and weakness types from NVD; exploitation status only from CISA KEV. The explainer is written with AI from those facts and published only after an automated check matches every version, CVE, score and command against the sources. Commands are limited to ones in official documentation. Always follow the vendor's advisory. Read in Korean.