A series of vulnerabilities has been identified that affect all versions of Valkey. Below is the summary of each vulnerability:
The patches for these CVEs had been released in newer versions of valkey-server and valkey-bloom. Please consider upgrading to these versions as soon as possible:
If you cannot upgrade your Valkey deployments right now, please read on for mitigation steps for each of the reported CVEs
A malicious user can use scripting commands to inject arbitrary information into the response stream for the given client, potentially corrupting or returning tampered data to other users on the same connection.
The error-handling code in Lua scripts does not properly handle null characters when returning error responses.
This issue impacts all versions of Valkey before 9.0.2
You can mitigate this issue by using Valkey ACLs to restrict the EVAL, EVALSHA, and FCALL commands if your application doesn’t intend to use them.
For example, to prevent the user testuser1 from executing said commands:
|
1 2 |
127.0.0.1:6379> acl setuser testuser1 -eval -evalsha -fcall OK |
We can then verify that testuser1 cannot execute these commands:
|
1 2 3 4 |
127.0.0.1:6379> auth testuser1 <password> OK 127.0.0.1:6379> eval 'random command go here' 0 (error) NOPERM User testuser1 has no permissions to run the 'eval' command |
A specially crafted RESTORE command can cause Valkey to trigger an assertion, leading the server to shut down.
Valkey modules must handle errors in RDB parsing by using the VALKEYMODULE_OPTIONS_HANDLE_IO_ERRORS flag. If this flag is not set, parsing errors result in a system assertion that shuts down the server. Even though the valkey-bloom module correctly handled the parsing of invalid RDB data, it did not set the flag.
This issue impacts all versions of valkey-bloom and valkey-bundle and any custom module that uses custom data types but doesn’t declare the VALKEYMODULE_OPTIONS_HANDLE_IO_ERRORS option.
You can mitigate this issue by using Valkey ACLs to restrict the RESTORE command if your application doesn’t intend to use them.
For example, to prevent the user testuser1 from executing said command:
|
1 2 |
127.0.0.1:6379> acl setuser testuser1 -restore OK |
We can then verify that testuser1 cannot execute RESTORE:
|
1 2 3 4 5 6 7 8 9 10 |
127.0.0.1:6379> auth testuser1 <password> OK 127.0.0.1:6379> set hello world OK 127.0.0.1:6379> dump hello "x00x05worldx0bx00px0ex81xf7-6x9bK" 127.0.0.1:6379> del hello (integer) 1 127.0.0.1:6379> restore hello 0 "x00x05worldx0bx00px0ex81xf7-6x9bK" (error) NOPERM User testuser1 has no permissions to run the 'restore' command |
A malicious actor with access to the Valkey cluster bus port can send an invalid packet that may cause an out-of-bounds read, resulting in the Valkey process being terminated.
The Valkey cluster bus packet processing code does not validate that a cluster bus PING extension packet is present in the buffer before attempting to read it. Attempting to read memory outside the process’s allocated memory can crash the server.
This issue impacts all versions of Valkey before 9.0.3
We recommend that the cluster bus port never be exposed to end users and that it be protected by its own network ACLs.
A malicious actor with network access to Valkey can cause the system to abort by triggering an assertion.
When processing incoming requests, the Valkey system does not properly reset the networking state after processing an empty request. A malicious actor can then send a request that the server incorrectly identifies as breaking server-side invariants, causing the server to shut down.
This issue impacts all Valkey 9.0.x versions before 9.0.3
Your Valkey deployments should be properly isolated and configured to limit access.
